DEV Community

Pauline
Pauline

Posted on • Updated on

💫 Writing code | The ultimate junior developer survival guide

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)

Collapse
 
tuwang profile image
TuWang

Really good retrospectives. It’s valuable advice for engineers at all stages!

Fun fact to share 🤪

  • I have had a new hire co-worker who was absolutely unable to do 1), but constantly doing 2) and 3).
  • He is not able to think independently before taking an action (so asking for help, nonstop) but is constantly trying to kill everyone’s baby, with a strong desire: “oh man I want to walk away from problem task ASAP”.

I appreciate great engineers. Sometimes I think we should give more credits to self-sufficient engineers ;)

Collapse
 
httpspauline profile image
Pauline

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.

Collapse
 
tuwang profile image
TuWang

aha :) yes, jokes aside, we all have areas to improve. great tips in the post!

Collapse
 
orballo profile image
Eduardo Campaña

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.

Collapse
 
httpspauline profile image
Pauline

Totally agree, thanks for sharing your refreshing take on this!

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

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. ‍

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.

Collapse
 
schnipdip profile image
schnipdip

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

Collapse
 
ripaz profile image
Ripaz

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.

Collapse
 
httpspauline profile image
Pauline

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!

Collapse
 
ebnbatran profile image
Ebrahim Batran

Great tips!

Collapse
 
httpspauline profile image
Pauline

Thanks for reading!

Collapse
 
jasiek194 profile image
Jan Król

As a junior developer myself I have problem with all three. Grate article!

Collapse
 
httpspauline profile image
Pauline

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!