The junior developer survival 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. 🙌🏻

Whew, you’ve successfully made it to part 5 of this series! Today I’ll be shedding light on some things that I truly wanted (or needed) to hear when I first started writing code professionally, and it’s something that I was worried about the most as a newbie: navigating a company’s existing codebase. It can take a while before you familiarise yourself with a codebase and I’ll be sharing some tips below on how to feel more comfortable going about it as a junior dev. 👇🏻

1. Practice reading code

When you’re learning how to code and following some tutorials here and there, the focus is often placed on writing code. What I personally didn’t realise at that time is that in reality, you will be spending far more time reading code than actually writing it.

Once you are given access to a codebase and start working on tasks, take some time every once in a while to step back and not think about writing code. Now I’m not saying that you should spend hours simply sitting and reading hundreds of lines of code in an attempt to understand it. Instead, whenever you will be touching certain parts of the codebase, don’t be afraid to look into the code that (in)directly surrounds the feature you’re trying to build. If something doesn’t make sense after a glance or two and a developer has not left any helpful comments, feel free to poke a colleague and ask them about the purpose of the code. Although this may not directly contribute to the feature you’re trying to build, it can be helpful to identify and understand similar code patterns next time you take a digital stroll around the codebase.

2. Don’t be afraid to modify existing code

To be honest with you, I used to feel very reluctant about making a lot of changes to the codebase. I felt like everything was already there for a reason, it was working properly on production, and I tried to change as little as possible whenever I was busy building new features. I always tried to add as few lines of code as possible. After almost a year of working with my company’s codebase, I sort of got the hang of both deleting code, refactoring code and also adding a lot of code.

The approach I like to take is to focus on getting your code to work first and to not worry about how much you may be polluting the codebase or how messy your implementation is. Some developers may disagree with this approach, but I found that it works for me to first aim to get the functionality down and then take some time later to finetune and tidy up the code.

3. Use code reviews as your learning playground

This is my favorite tip of the week. Pull requests and code reviews are the ultimate place to learn, to expand your knowledge, and to have fruitful discussions about code. When used properly, there can be far more to it than simply sharing your code changes and hoping that your colleagues and peers will approve your pull request.

For starters, try to review your own pull requests. Recap the flow and the changes you made, and ask yourself if all of this makes sense. Can you justify your changes, or explain why you made certain decisions? Are there more suitable approaches you can take to build a feature or fix a bug? Are there other ways to refactor code that will make it more maintainable in the long run?

Bear in mind the playground is not confined to just the pull requests that you yourself create. There is just as much to learn in the pull requests that are being created by your colleagues. Challenge them, ask questions. If you’re reading their code changes and you’re not entirely sure what’s happening, this may be a sign that perhaps the logic is not as clean and structured as it could be. Just because you’re a junior developer, does not mean that you can’t have any valuable input on changes made by senior developers! Be bold and seek explanations. Observe the different ways of problem solving and learn from them.

Another great way to learn from the pull requests of others is by first asking yourself how you would solve the task at hand prior to reviewing your colleague’s PR. There’s no need to think of all the exact details here, but try to grasp the bigger picture. Ask yourself what changes are necessary—you can jot them down or form some clear ideas in your mind. Then, start reviewing the pull request and check what things you missed or which alternative problem-solving methods there are. It may sound like a tedious process but you can definitely learn a lot while you’re at it!