DEV Community: chloe

to specialise or not to specialise?

chloe — Mon, 08 Jul 2024 11:17:47 +0000

As a self-taught developer currently working in IT with multiple interests in tech such as web- and application-development, machine-learning and IoT, I've run in a recent hurdle of whether or not I should specialise.

A little more information: I've been in the tech industry for a little over a year which can be considered a junior developer (please correct me if I'm mistaken), and the programming languages that I'm most familiar with include JavaScript and Go. My academic qualifications are unrelated to engineering or computer science although I am in process of getting an AWS foundational certificate. I am also currently based in Singapore if it's of any relevance.

If you're a seasoned developer, please give me some advice on whether I should pick a field or niche in tech to specialise in, and if so, which field(s) have a slightly lower than average barrier of entry.

writing my first mentoring plan

chloe — Tue, 02 Jul 2024 14:02:58 +0000

I've recently got into a career mentoring program with my local JuniorDev community which runs for 2 months with check-ins every 2 weeks. Being a mentee, I thought it would be helpful for both my mentors and I to list what I want to learn from them and what I want to achieve at the end of the program.

1. Embodying the right mindset

As an IT engineer who have worked on developing and maintaining several systems for my organization, I frequently come across the questions of "How will this help us more than hurt us?" and "Should we do this just because we can?" which returns us to the drawing board of whether a certain implementation would cause more problems than the ones it will be solving.

I've realised that I tend to lose focus and clarity of the problem at hand since distractions are everywhere nowadays. I want to build a mindset that focuses on solving one problem and delivering a solution fast, followed by reiteration practices to make it better and better.

2. Interview and Workforce preparations

Throwing interview prep into the mix, I do lack quite a lot of knowledge about workflows such as scrum or agile, Kanban boards, etc even though I have been working with a few workflows on Jira project boards. I've read that good CI/CD practices are just as important as practicing LeetCode since working with other developers makes up most of the job.

3. Make a decision on the work I want to do / specialise in

As I am someone with plenty of interests, I'm hoping to get some advice on the field of software to be involved in. I'm going to list several of my current interests in tech here based on their priorities:

Writing programs with GO
Web-app and application development
tinkering with IoT devices, Raspberry Pi, ESP32, etc.

Tech stacks I'm most familiar with:

JavaScript
React
GO

I am intending to specialize in application development as the entry for jobs in the field are slightly more open for Junior positions whereas a certain specialization surround my interests such as backend development would require higher levels of experience that I currently don't have. Let me know what you think about this in the comments and if you have any idea what I should try specializing in!

I will be starting the mentorship program in a weeks' time, and I hope to be updating my progress here as well. If you have any advice on mentorships for me, please let me know in the comments as well :)

does documenting your progress actually work?

chloe — Mon, 24 Jun 2024 12:12:40 +0000

Lots of developers that I've met and read about highly recommend keeping a Dev Journal. Stand-ups and check-ins in professional development and engineering teams happen daily to keep track of their progress. There's also a devjournal tag within this Dev.to community with lots of focused posts on their learning.

But for someone like me, a self-taught dabbler, I've tried millions of different journals including Apple Notes, Notion, and my most recent obsession, Obsidian. Even though Obsidian does have a UI and workflow that I am easily accustomed to, its daily notes intuition just doesn't really cut it for me. I'm someone who hates looking at blank pages. It's uninspiring and incredibly dangerous, because that's where the options are limitless and at the same time they're nowhere.

So I've built a few templates for my daily notes to track my progress, but I still find them pretty underwhelming since I have to click through all of them to read what I did the past week or month. This kept me from continuing the consistency of writing everyday, let alone the fact that I took time out of my day to do this, that led up to a bunch of lost notes with no actual context of progress or reflective insights.

Relative to this, it's easier for me to look through photos, i.e. a gallery style visual board to see what I was doing the the past week or month. I've tried writing in this style within an Obsidian note with the simplest formats: The month it is, the day of the month and what I'm working on, all within the same page, so I can scroll to the top when I'm at the end of the month to see how much I've progressed.

This of course isn't the best solution but it's somehow working at the moment. I've initially thought of starting an Instagram or Twitter account dedicated to post short videos of my progress, however I'm terrified of how I instantly get distracted once the focus shifts to gathering a social media following instead of my learning.

Share with me some of the progress-tracking tools you've used! Should I start an Instagram account or just keep going with my Obsidian page workflow? Do you face the same troubles as I do? Let me know what you think and do drop me a follow too!

when should you quit working on an idea?

chloe — Fri, 21 Jun 2024 12:05:38 +0000

Millions of business ideas, SaaS, and startup ideas fail everyday. As a business graduate myself, I’ve learnt something quite important about recognizing the potentials of an idea before the costs to prove its worth overwhelms its true value.

Every idea sparks from a pain point and surrounds it to act as a painkiller. But what frequently happens is that we fall so in love with our ideas that we forget the problems they’re supposed to be solving. And just like bugs or inefficiencies in our programs, our obsession with these ideas often manifests and turns into wasted time and dollars.

Making up the problem

The #1 trap I fell into when I started my first hackathon project was exaggerating the problem. It was simple. The initial problem was that Slack workspace owners had to remove inactive or unused channels manually and one at a time. Since this is an incredibly time-consuming process for companies with huge workspaces, say 1000-1500 users, a Slack Bot can be built to 1. monitor all channels within a workspace, 2. set a threshold of inactivity, and 3. archive channels that have been inactive over the threshold.

So I started building the Bot with these 3 main features in mind. A few hours later, I thought, "What if the bot could automatically send messages to admins about channel activity, and flag any messages that contain data prone to insecurity or any anomalies like harsh language / vulgarities?" Now you may think that I'm only thinking these because I was done building the initial 3 main features, but I wasn't even halfway through the first.

Now I've got about another 6 features I want my bot to have. It's the following week with about 3 hours left before the due time and only 1 feature package passed release checks. I had to present my idea with a beautiful slide deck only to spectacularly fail at showing a working demo.

Now I know what you're thinking, if I worked with another developer or a team I’d probably be able to get them to build all the features within the time frame. Yes, that's exactly what I thought as well, until one of the lecturers hit me with this:

"Imagine you're a potential user of this bot. You're on Slack and you've got about 200 channels that are inactive and you want to archive them. Since Slack has no built in functionality to do this in bulk, you go to Google to search for a solution and you land on this bot.

You click on the webpage link, read the documentation on how to use it, and get overwhelmed with a whole bunch of features you don't need. What do you do then?"

Which was a really good point because as a user, I would simply tab back to Google and search for a better solution. I wouldn't have even given my slack bot a second thought or even another 20 seconds to look through. Yes it's brutal, but it’s true, because if I wouldn’t pick my own bot, I’ll assume that not many people would either.

Having gone through all of that, I just spend a half day on each idea I had from then on. Build one feature and get it to ship, as fast as possible. Extra features are like the sides of fast food meals. They might look really appetizing, but a whole lot of them would rack up in prices and make you too full for your burger which is the hero.

There's always someone doing it better

Now even though I gave up on the idea post-hackathon, I was still itching from the epic fail. So I Googled "archive slack channels automatically" and a whole bunch of well-built, simplistic, easy to implement solutions appeared. One of which was Channitor, which solved the problem immediately within 2-3 clicks of being added to a Slack workspace.

Of course there are hundreds of solutions to the same problem. Someone's always doing it better and someone's always got the better approach. But what really humbled me was that there is no one-shoe-fits-all approach. Every single thing has its own specific purpose, just like how a Mustang is to be driven with style, and a Toyota is to be driven with comfort. You wouldn't drive a Toyota to a drag race and you definitely wouldn't try to fit an entire family in a Mustang.

The lesson truly learnt here is that no matter what we're doing, building, or creating, there's always someone doing it better. But what really helps propel us is the things that make what we build different from the others. A product isn’t just the features it represents, it’s the feeling that people get when owning it. I've understood this very clearly from the music industry since it is as highly competitive as tech or maybe even more. Someone's always got a better voice, a better guitar hook, a better beat. But what sets me apart is what my art truly means and how I tell my stories through them.

What I’ve learnt from quitting early

Yes, just like nicotine and alcohol, it’s better and easier to quit early, and while the risks are invisible. A bad idea will never seem like one at the start. It might even seem like the best idea ever. But don’t fret, failures are never the end and there’s always a step up to a better application and an award-winning idea. Here’s what I’ve learnt mostly from my spectacular failures:

Clarity is key - be able to define the problem statement clearly, and if possible in one short sentence
Do proper research - talk to people who potentially have the problem you’re trying to solve and get their insights on how they’ve looked for solutions, what solutions they’ve landed on, what works for them and what doesn’t
Don’t fall prey to Shiny object syndrome - focus on the main feature instead of getting distracted with a million other potential features. Most of these probably wouldn’t even make a difference until your idea blows up anyway
Treat feedback like food - listen to your potential users! They’re the ones who are going to be relying on what you’re building anyway. How would you feel if the waiter taking your order gets it wrong twice or even thrice?

end

Well if you’ve made it this far into this read, please leave a comment and let me know what you think! As this is my second post do share some thoughts on my writing as well, remember I take feedback like it’s food :)

my unconventional journey into tech

chloe — Thu, 20 Jun 2024 16:29:30 +0000

Where it started

I’ve hopped from a diploma in Music and Audio Technology to a college degree in Business Management, then landing a job in IT engineering most recently. I’ve read about many self-taught individuals getting into the software industry over the past few years and I’ve started on this journey halfway through completing my business degree. It’s surreal to think how far I’ve come and still have the privilege to have a hand in the things I love like music.

My past 5 years:

2019 - Got a diploma and worked as a freelance audio engineer

2020 - Got into Uni because Covid killed my freelance work

2021 - Took a coding elective and started learning about the programming world

2022 - Absorbed like a sponge from dev meetups, communities and learned about programming ecosystems

2023 - Landed an IT internship that led to a huge upgrade to full-time

However, I’m still incredibly new to the tech industry especially only being in it professionally for less than a year. It’s sometimes overwhelming to think about the stacks and stacks of tools and techniques to learn, but the satisfaction of fixing the smallest bug and finally printing “hello world” to the console is so worth it. Maybe it’s me and my addiction to dopamine and doing things that make me feel good or maybe tech itself just seems way too promising.

Looking ahead

I’m still really far from the things I want to achieve and breaking them down into an ideal world and unrealistic 5-year plan, this is pretty much what it looks like:

2025 - Land a job in a startup doing either fullstack development / software engineering

2026 - Do such a good job that job upgrades are in order

2027 - Build a SaaS and get at least 500 customers

2028 - Scale the SaaS and build a team

2029 - Become a software rockstar or willfully unemployed

My ingenious plan to make it work

What I’ve learnt with my short time being in tech is that the ability to learn is more important than anything. The ability to absorb like a sponge and apply everything in a completely different situation regardless of how difficult it may seem. Everything has a pattern and some form of consistency, and one iteration to improve a program even by a little bit is more valuable than building multiple projects. Quality over quantity.

I’ve learnt from my years in the music industry that quality comes from experience too, good habits, and a ton of muscle memory. So for the rest of this year I’m going to try and build these habits one day at a time!

With a webdev starting point in NodeJS, I’ve recently picked up Go and any advice on mastering the high-level language itself is welcome!

Let me know how your journey into tech was, and if it was as random and abrupt as mine! :)