Why you should always involve junior developers in code review

If you’re an engineering manager or lead, you know that code reviews are an important part of the software development lifecycle (SDLC). Most people think that code reviews are for finding bugs and, while they are great for that, they’re also essential in ensuring that code was written in a maintainable way. Code review is also essential for uncovering edge cases and helping to spread knowledge about architecture, implementation and code standards.

I’ve seen a lot of debate around whether junior developers should be reviewing other developer’s code with strong opinions on both sides. What benefit could there be to a junior developer doing code review for a senior (or principle) engineer? I can tell you that both my company and I benefited tremendously from having me do code reviews when I joined as a new graduate 5 years ago. While that might not seem intuitive at first, give the following some thought:

Spreading Knowledge

Junior developers can learn a lot from chatting with members of the team who have more experience, but there’s nothing quite like looking through a senior developer’s code and seeing how they approached an issue. Over time, more experienced developers have seen what works and what doesn’t work when it comes to coding. Junior developers will learn a lot by reading through the changes made by a more senior developer even if they don’t leave a large number of comments on a code review. By doing code reviews, junior developers will have a better sense of common pitfalls, where to go look for patterns to follow as they do their own implementation and even who to talk to about the implementation (based on who wrote that code or left comments).

I’d personally recommend starting junior developers off with reviewing bug fixes or small changes to get them comfortable with reviewing other people’s code (remember that this could easily be their first time giving constructive criticism to other engineers). After they get more comfortable doing this and understand more about how things should be done, it’s time to move on to reviewing full features/stories.

When the junior developer starts reviewing full features/stories, they will be able to see how an entire flow is tied together. For example, just some of the things they could learn about by reviewing bigger changes:

• How is the project structured and organized?
• How does the UI call down to the backend?
• How do we handle input validation of the fields being passed down?
• At what point do we save information to the database?

Code Quality and Standards

One of the biggest changes going from working on college projects to developing code professionally is the huge jump in code quality and standards. In college, the focus tends to be on getting things to work without thinking too much about the quality of the code. In a professional environment this simply won’t work.

Every company has (or at least should have) their own coding standards and it makes the entire team’s life easier if everyone is aware of these standards. It could be argued that someone could learn this by looking through the code themselves but at the same time, this is hard to do if you’re working on a large codebase. In my opinion, it’s much easier to learn how code should be structured by seeing coding standards being followed in a code review.

On another note, make sure that these standards are documented somewhere rather than stuck in people’s heads. If it’s not documented code reviews will end up in one person’s opinion against another. Google's Java coding standards are a good example to follow if you haven't got any coding standards documented yet or want to improve what you currently have.

Coding is a Team Effort

Whether someone is a junior developer or a senior developer, it’s important to make everyone aware that their input is valued. Think about it from the junior’s perspective – which one of these would make you feel more valued?

• Your code is being reviewed but you’re not allowed to review other people’s code.
• Your code is being reviewed but you’re also reviewing other people’s code.

Giving people more responsibility benefits both the company and the person since it helps them to grow. It really is a win-win situation.

Not only that, but juniors tend to do code reviews differently from more experienced developers (and not in a bad way either!). Junior developers tend to go through the changes that were made line by line to help them fully understand what’s going on, and this can often spot a lot of issues from code not following coding standards to the dreaded off by one error. While a junior might not have a great deal of input on the overall architecture, their input is still highly valuable and engineering managers and leads should do everything in their power to empower the entire team, not just those with years of experience.

Keeping Code Maintainable / Readable

One of the reasons why code reviews are done in the first place is to make sure that code is maintainable. Maintainable code should be able to be understood by all developers on the team, not just those with a lot of experience behind them. It can be quite risky if only a small part of the team understands certain parts of the code because of the way it was developed, especially if the team is relatively small.

While there might not be any plans for the junior developer to work on a certain part of the code in the short to medium term, at some point in the future they may be the one working on it so having a wider perspective can only be a good thing. In an ideal world, the developer reviewing the code should be able to not only understand the reasoning behind the changes made, but they should also be able to modify it without spending hours or days trying to figure out why it was implemented in the way that it was.

Senior developers should leverage the fact that new employees (especially junior developers) lack the context they have built up over the years. Reviews from junior developers can help push senior developers to think about problems differently, provide better justification for their decisions and ultimate push them to refine and simplify their implementation to the point that “even a new grad could understand it”. Ultimately, this process yields higher quality and more maintainable code for everyone.

If your company doesn’t currently have junior developers doing code reviews, we hope that the points above make you reconsider that decision! It’s a big decision to make but it’s worth considering giving people more responsibility. Feel free to let us know what you think, on Twitter or in the comments below!

‍