Read this if you want to know what mistakes I made, so you can decide for yourself if you want to make them too.

Someone told me earlier today to get a good job, you can’t just apply (he meant, you need to network/ have existing connections). Then I thought, he’s right: I’ve never gotten a job by applying, except the one at an Ice Rink. My first software job was when I was randomly called by a recruiter, and they pitched a job to me. I didn’t even do Computer Science, and graduated from Engineering a few months before their call. I was spending my days, weeks and months coding, learning to become a software engineer! A few weeks later, I was a Backend Software Engineer at a really cool company. Don’t worry, I didn’t get fired, but I made some mistakes and this article helps me reflect on what I should do now & beyond.

In summary

• Watching too many tutorials & not doing enough of my own project ideas
• Learning too much & not coding enough
• Irrelevant side projects and not focusing on work outside of work (maybe I should’ve chosen a job that tied well with my side projects)
• Being distracted by everything interesting (might be a good thing?)

Watching tutorials.

Problem: I didn’t know how important it is to just build your own project, instead of following tutorials. I confidently tell people now, tutorials suck my motivation. That is the best way I can put it. There is no reason to learn how to implement authentication if you don’t even have a project that needs it. Over time, I’ve noticed other people find this too.

Solution: Never do online courses or watch tutorials just because they sound interesting. If you hear a new technology is interesting or even programming is fun. Do it to see for yourself. Immediately go to the ‘Getting started section’ of the technology or programming language. Don’t watch someone else or follow along in their tutorial. Its either filled with stuff you don’t know (overwhelming) or too easy (underwhelming). The more pain you’re facing in your project, the more motivation you’ll have to watch a few videos or read articles, and thats okay. I am problem & project driven. I don’t know about you. PS: I still enjoy short videos like Fireship, but I know I don’t get nearly as much out of it compared to when I design and code programs myself.

Learning too much. Coding too little.

Problem: The codebase was overwhelming: it was a huge monolith Java application which used the publish-subscribe pattern for different components of the application to communicate. The network of these messages and communication was drawn by plugin, and it literally looked like Spaghetti 🍝. Also, there was a lot of domain specific knowledge, and I knew none of it. I also didn’t know Java that well, not like I know Javascript now ❤️. Luckily for me, there was a lot of material to read: years worth of cutting edge material, in slides & docs. So I started there, and never really finished 😅. Thinking back, there was a lot of opportunity to just code and break more things.

My fix:

• I think technical debt is an important balance in software that gets used vs one that is too slow to get developed, so I shouldn’t complain at problems if I see them, but instead try to solve them. At the same time, I am relatively new, and the responsibility for keeping the developer experience good should not be on me. So in cases like this, the most aggressive thing I can do is probably speak to others to see how we can work together to improve the developer experience.
• I can’t just decide to ‘learn faster’. Learning takes time and effort, and spending time on learning takes away time from coding. Its a balance, and I probably overdid the learning part. If I’m met with a situation like this, I will try to write more code, and spend less time understanding the architecture/ system when its not important for the task. I should spend more time on the individual components I need. Easier said that done though, because adding a feature in one component often requires you to understand a whole list of other components in the application. My first task was to decouple one component from everything else. Looking back, it might have been a more optimal learning curve to have given a task in one section of the code.

Irrelevant side projects?

Problem: I love side projects because they teach you things a lot quicker than following tutorials. You can also get a feeling for the latest tech and libraries that are being written. Often though, it did not tie in with what I did in my software engineering job, and so it wasn’t being augmented by my efforts outside of work. Because of this, I often thought to myself, the developer experience of so-and-so language was much better than the one we have here, and it sometimes got frustrating. Till now, Java has dissapointed me: there are way too many annotations, its slow & I found it generally tiring to work with. I feel like the learning curve for other languages are more interesting. However, I see Java still being used by one or two startups probably because of their employees’ past-experience, although I don’t see it very often at all.

My fix: In the future, I will find a role that makes me work on a technology I already know or like. When I first got that job, I didn’t know many technologies, so I didn’t even think about this. Focusing just on the technology the company had would have limited my understanding of computer science, especially as a ‘self-taught/ non-computer-science graduate’. Now, I’ve spent some time in Python, C++ and Javascript (with React/ React Native), I’ve gotten a better sense of the ecosystems. But as I learn more, I realize its less about the programming language, but more about the problem you’re solving. I’m still looking for companies that are solving interesting problems, like the environmental crisis, human crises and other societal problems. However, I am careful not to work on old technologies. Personally, I more inclined to get better at making apps individually than to practice cracking the coding interview.

Being distracted

Problem: So many things interest me: the CI/CD pipeline, the security vulnerabilities, and any of the applications running alongside the one I work on. I argue that spending time on these other applications give me context, and help me understand my application better.

Solution: This ‘problem’ only existed because I was relatively new: its a very interesting new world I’ve entered, and its natural to want to absorb all of it. There’s a benefit to understanding more things, but focus is also important. As Xun Zi said, “The person attempting to travel two roads at once will get nowhere.” Over time, my productivity would increase as the puzzle pieces together.