Code reviews are a great practise to find mistakes, potential bugs and other issues overlooked by the code author. Reviewing improves the overall code quality, but it is also a great way to share knowledge and information. Junior developers' commits should certainly be reviewed by more senior developers, but juniors should also be the reviewers. Here's why.

In every project there are things that need familiarization when a developer (junior or not) joins the team. These can include for instance code and project organization, testing, build, deployment and the general way of working in the project. Especially in large projects, understanding the existing architecture and design decisions as well as the rationale behind these decisions can be a major challenge for a new developer.

Both the technical aspects and the way of working can usually be found from the project documentation. Nevertheless, implementing new features or fixing bugs in an unfamiliar code base is still challenging. What would be a better way to learn than following the example of more experienced developers in the same project?

What would be a better way to learn than following the example of more experienced developers in the same project?

Having young developer go through commits of experienced developers by reviewing is a great learning experience for the reviewer. Not only does it give a great reference for design and architectural decisions as well as coding and style practices, but it also shows how to apply these in the actual project in which the developer is working on. For the reviewee, it does not hurt to have an extra set of eyes looking at the code even though the reviewer is not so experienced. In fact, someone who is not so familiar with the project most likely looks at it from a fresh perspective.

A lot of the benefits from this kind of review goes to the junior developer. However, there are also benefits for the project. Obviously the developer can familiarize quicker, but the reviews also give a wider view to the project than what would be directly necessary for the task at hand. Chances are that the now new developer will at some point maintain the project, so having a wider perspective from the get go is invaluable.

So far the discussion has been solely technical. Yet, the review practices can also have a social effect. When a new developer is asked to review commits of already established members, it shows that they are accepted as a member of the team and their input and opinions are valued. As always, successful review practices require healthy working environment. Everyone should be able to both give and receive feedback without taking the comments personally. To reinforce this atmosphere it is good to have everyone from juniors to seniors to be both reviewers and reviewees.

These same practices can also be applied across teams and across people with different competences. Why not have embedded developers review some GUI code or backend developers some front-end changes. Just because something is beyond someones' main competence area, does not mean they would be unable to spot mistakes or give feedback (of course some more subtle mistakes that relate to a specific library or language would still need reviewer with strong competence in that area).

So let's make the most of code reviews and have everyone from juniors to seniors take part.