Welcome to the ultimate junior web developer survival guide, part 2! 🎉

If you're new here: this guide is a series of multiple posts where I document and share some of my most valuable experiences, advice, learnings, lessons, answers to questions my past self had, mistakes I made (so that you don’t have to make them), and much more in an attempt to simplify and improve your life as a junior developer as much as I can.

This guide will touch upon topics that they don’t teach you in tutorials; I will be talking about non-technical matters that you learn on the job. The articles will be relatively short and concise so you spend less time reading and more time executing. 🙌🏻

1. Think first, build second

This is something I still struggle with a lot. Being a front end engineer, whenever I pick up a new ticket, I have the tendency to start writing code as soon as possible. I want to see changes on the screen as fast as I can. ‍
More often than not, this completely unnecessary rush leads me to get stuck easily and also having to rewrite a lot of my code. By not thinking about the desired solution first, I don’t have a full and clear overview of the existing code that is going to get affected by my changes. I’m not aware of which pieces of code I can reuse, or how to split up tasks into different, smaller chunks.

Instead of taking the above approach, go through the steps that you have to take in order to build your new feature (similar to writing pseudocode prior to solving an algorithm). Digging through the codebase and found the files that you will most likely be making changes to? Leave a comment for yourself outlining what needs to be done and in which order, and don’t write any code yet until you actually have a clear idea of the exact steps you need to take.

It very much pays off to first evaluate what has to be done first. In which order should you approach this problem? Do you have all the knowledge required in order to solve the problem at hand? Can this task or feature be split up into multiple different PRs? Having a plan then also makes it easier to discuss your approach with a colleague, and they might be able to share some helpful pointers to improve your plan. Refraining from immediately jumping onto your keyboard will save yourself a lot of time fixing the code that you wrote when you didn’t have all the necessary information.

2. “Kill your babies”

I once attended a masterclass where an industry expert shared his advice on becoming a better developer. One of his lessons was to “kill your babies”. Uhm, excuse me, what?! He then proceeded to explain that as a developer, you will often be deleting or rewriting the code you wrote (and are likely extremely proud of) and that you therefore shouldn’t get too attached to it.

This tweet by Kyle describes it beautifully:

There may be situations where you are able to hold on to your code by only slightly modifying it, but there will also be tons of cases where you are simply going to have to let go of it. No matter how much time you previously spent on it or how proud you are of it. Some code isn’t meant to stick around and that’s okay (and even though the label to this piece of advice may be a little provocative 👶🏻, it’s certainly powerful enough to make sure you never forget it).

3. Learn to step away from the problem

In those moments when you get stuck on a given problem, force yourself to step away from your computer for a brief moment. You may tell yourself something like “but I am this close to finding a solution, I am almost there! I can feel it, if I step away from it now then I will lose my train of thought and it will take some time before I can get back into my flow again.”

These are actually all the things I used to tell myself whenever I was dealing with a tough problem. The thing is that taking a break and revisiting your code with a clear mind and perspective is far more beneficial than staying in a rut. We cannot force our brains to work harder or to dig deeper. Sometimes it helps to start over again and to reevaluate what you already know and what you’re missing. Oftentimes the solution comes to you when you least expect it, along with an “I can’t believe it took me this long to arrive at this solution”-moment!

As always thanks for reading and happy coding!

If you enjoyed reading this post or if it was helpful to you, you can support me by buying me a coffee — I'd really appreciate it! 🙏