DEV Community

loading...

🌙 Navigating the codebase | The ultimate junior web developer survival guide

httpspauline profile image Pauline ・4 min read

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!

Discussion (7)

pic
Editor guide
Collapse
jackharner profile image
Jack Harner 🚀

focus on getting your code to work first

Perfection prevents progress. Can't improve your code if you don't get it working in the first place. Programming itself is an iterative process and it's fine to "fix it in post". Definitely don't want to get buried in technical debt though.

Collapse
eddyvinck profile image
Eddy Vinck

If I had to write perfectly clean code while getting it to work, I would never get anything done.

Also, if the requirements change while you're working on a feature, all the "perfect" code you wrote might not be useful anymore.

Collapse
jamiepo profile image
Jamie

Wow that’s something I’m working on I want everything to be perfect and that’s not realistic all the time.

Collapse
rockykev profile image
Rocky Kev • Edited

Even teams forget this at times. My team was trying to duplicate a chunk of functions that worked on another project, using the overly optimized code we wrote for it.

After a few days of failed attempts, someone said. "Screw this. Let's just hardcode it." Just to get something to work.

Once we got something to just "work", then we slowly moved to making it as tight as the code we were trying to duplicate.

It's a excellent reminder... No matter how many years of experience.

Collapse
attkinsonjakob profile image
Jakob Attkinson • Edited
I sort of got the hang of both deleting code, refactoring code and also adding a lot of code.

At work, we all agreed that before we change or remove code from another dev that is still with the company we should ask for a confirmation.

This works really well both because we are a small team and there is a lot of undocumented code and decision made without leaving a trail. Some snippets look like "magic" and therefore changing something might have an unintended effect. This unwritten rule assumes somehow that solid logic had some reasoning behind it, but lack of documentation makes it hard to follow or understand.

Worth to mention that I am talking only about changes that touch on logic and algorithms, not about small fixes and refactoring.

Collapse
downey profile image
Tim Downey

One other technique, if your colleagues are up for it, is to pair program! Especially Driver/Navigator style. A skilled and patient Navigator can make a new codebase less intimidating and provide for a really fast feedback loop.

Collapse
sarajoha23 profile image
Sara Carvajal

This series is awesome 😊 thanks for the great tips! I'll definitely keep them on my reading list so I can come back to the articles later.