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! 🙏
Top comments (13)
Really good retrospectives. It’s valuable advice for engineers at all stages!
Fun fact to share 🤪
I appreciate great engineers. Sometimes I think we should give more credits to self-sufficient engineers ;)
Thank you!
Sounds like a tricky co-worker to deal with, hats off to you for working with engineers like that. :-) I can't imagine how hard it must be.
aha :) yes, jokes aside, we all have areas to improve. great tips in the post!
The last one is always hard for me.
I think that when you feel you are about to solve the problem you have been working on for a few hours, you have already missed a better solution.
It's like if the right solution is in a path you didn't take and that's already behind you. The only way to get there is starting over with all the new knowledge you acquired that will allow you to see the path this time.
Totally agree, thanks for sharing your refreshing take on this!
This doesn't have to be a bad thing. I do this a lot myself, and often don't even mean for it to be the final code. Writing code can be a really good way of exploring a problem because you can test solutions easily and see what works.
The key is to not get too attached to any particular solution; if something doesn't work, start the next iteration.
Section 2 is always hard no matter what field you are in. The more time dedicated to solving a problem the harder it is to let go... much like a dog
I'm proud of my self for being capable of killing anyone's child, even my own. Agh that came out wrong.
Back to the topic, 3rd point is hard for me. Sometimes I spend to much time on solving a problem and fail miserably. Then next day, boom, I solve it in under a hour. Sometimes hitting a 10 minute walk around office can do wonders.
So relatable. I still struggle with it, too. This week I had to make some CSS changes and after literally spending an entire day on it, I still wasn't getting the desired results. I knew for a fact there had to be a better way to implement it. The next day, I took a step back and suddenly had my "Eureka!"-moment, facepalming in disbelief that it took me so many hours to achieve a very simple solution haha!
Great tips!
Thanks for reading!
As a junior developer myself I have problem with all three. Grate article!
Same here, I guess writing them down and sharing them with the community is a way to hold myself accountable and to remind myself not to get stuck on these things :-) Glad you liked it!