The ultimate junior developer survival guide (5 Part Series)
Welcome to the ultimate junior web developer survival guide! 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. 🙌🏻
Ready? Let's go!
Asking for help can be hard. And once you succeed reaching out, asking the right questions is even harder. It’s key to prepare your questions and sketch the situation as clearly as possible to outsiders.
For example: What is the context you’re working from? What are you trying to achieve? What solutions did you try and what was the outcome of it? On top of that, be specific with your questions. Rather than bluntly asking your colleague or peer “Why does this code not work?”, try something like “I’m trying to render the data from my API call here and have tried out solutions X and Y. I suspect the problem lies in this part of the code, could you explain why this approach does not solve problem Z here?”.
Gordon Zhu has written an excellent piece on asking great questions in which he shares a thorough outline of steps to take to get better at requesting and receiving help. I found this article very helpful and I encourage you to check it out too.
As developers, we are learning new things every single day. With so much new information non-stop coming our way, we shouldn’t always be relying on our memory to retain all of it. Do your future self a huge favor and take notes (even if no one else around you is doing it)!
If you work through a bug or problem where you got stuck or faced some difficulty, recap and document the solution. Our brains are solving so many problems on a daily basis and we very easily forget certain solutions, even if they made sense the first time we encountered them (I know I’m not the only one). Had to Google or StackOverflow something and feel like it may come in handy again later? Jot it down. This doesn’t have to be some official or formal documentation for others to read. It doesn’t matter if you take notes digitally or with paper and pen.
Documenting your solutions and learnings does not only serve as a future reference guide, but it’s also a great way to keep a log of things you learned along the way (and therefore indirectly tracking your progress so you can see how far you've come!). You will thank yourself later. 🎉
When I started my first internship/developer job, I found it very helpful to block time to discuss certain engineering topics and concepts with a more experienced colleague. This can be just 30-60 minutes where you sit down together to improve your own understanding of something.
You might be thinking now: “Shouldn’t I educate myself and study the topic on my own first, rather than asking my colleagues to be my tutor?”. Bear in mind that this is not a lecture where you just sit back and absorb theory. You are creating an opportunity to improve your knowledge and understanding (and let’s face it, thereby also increasing your value to the company). This then also allows you to see how certain theoretical concepts are applied in practice in the company’s codebase. On top of that, don’t forget that you’re also testing your colleague’s understanding of certain topics and helping them improve their communication skills. 😉
This is it for part 1, stay tuned for part 2! If there are any topics you are curious to read or learn more about, leave a comment or send me a message and I will try my best to cover it!