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

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 struggled with a lot when I started my first job. As a front end engineer, whenever I picked up a new ticket, I wanted to start writing code and see the changes reflected on my screen as soon as possible.
However, more often than not, this completely unnecessary rush lead me to getting stuck easily and also having to rewrite a lot of my code. By not thinking about the desired solution and code structure first, several things would happen. Some examples:

• I wrote new code, even though existing code could have been re-used
• I would end up with one big pull request, which could have been split into smaller ones (making it easier to review for others)
• I created dependencies and blockers for myself
• I didn’t have a clear overview of which UI interactions and parts of the codebase would get affected because of the new code that I wrote

Instead of immediately making changes in your code editor, take a step back to see what you're going to be working with, and to see what code you're going to have to write. Take a digital stroll through the codebase and leave comments for yourself in the files that are relevant to the feature you are building. Once you have all the information you need as well as a rough idea of the steps you will need to take, you will find that development will go a lot smoother.

If you're unsure whether you're setting up the right approach, you can also use those previously-mentioned comments to discuss your ideas with a colleague and to receive feedback.

2. “Kill your babies”

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

This tweet by Kyle describes it beautifully:

Kyle Shevlin

@kyleshevlin

A skill worth developing as a software developer is the maturity to handle deleting/undoing your work without letting it affect you personally. Requirements change often, and you will throwaway work just as often to meet those changes. That's not a judgment of you or your work.

20:58 PM - 02 Oct 2019

There may be situations where you are able to hold onto your code by tweaking it, but there will also be plenty of cases where you're simply going to have to let go of it. It doesn't matter how much time you spent writing 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. Step away from the problem

In those moments when you feel 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, I will lose my train of thought and it will take some time before I can get back into my flow again.”

Sound familiar? I used to tell myself this every single time I got stuck trying to debug my code. However, taking a break and revisiting your code with a clear mind and perspective is far more beneficial than staying in a rut. It often 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 spotted this sooner”-moment!

As always, thanks for reading and happy coding! 💚