Curated by: Sergio A. Martínez

When you are trying to bring a new application to life, code reviews are an essential part of the development process. They help ensure the quality of the code, identify potential problems and bugs early enough to squash them and provide the perfect opportunity to get feedback from your peers. This is a source of insight and helpful criticism that can help a developer grow.


After all, in big collaborative projects such as software development, no part of the process is made in isolation; receiving advice is an important part of every good team, cultivating a better collaborative environment, and establishing a sense of trust and camaraderie among the team. Code reviews, for example, are one of the most important steps in this process, but how they should be conducted, and by whom, are questions to keep in mind when trying to guarantee the quality of any product. 

Naturally, this task tends to fall on the shoulders of the more experienced developers of a team, as seniors should know what they are doing and what to look for, but is their input the only valid one? Or should junior developers be allowed to do code reviews for their more experienced teammates? What benefits can a team have by giving the least experienced members such a responsibility?

We want to make the case that allowing junior developers to review the code written by a senior collaborator not only helps them grow their skills, but it’s a procedure essential to ensure quality in the codebase. Any team that doesn’t employ this strategy might be missing a great opportunity there, but what’s the reasoning behind it?

“You can’t win against someone who makes a bet for fun”

The Expert Blindspot, or why you should let junior develop

In professional poker, winning against amateurs is not exactly guaranteed. Of course, luck is involved, but the technique is important too. Knowing how to read the tells of your opponent, having a good idea of which cards are currently in play, and learning to push your bets at the most strategic moments are part of the toolset of any professional player. And all this can be disrupted rather easily by an amateur with less experience at the game because they are harder to estimate and bluff.

This interesting irony was noted by movie critic Gene Siskel, an experienced player when he lost against his equally famous partner Roger Ebert at a bachelor party: “You can’t win against someone who makes a bet for fun”. In other words, professional player has very specific expectations if they are going against another pro, and their decisions come from a place of knowledge and experience where possibilities tend to be more studied and controlled. So, if you are an experienced developer reviewing the code written by another experienced developer, what exactly do you expect to see? Is that different from reviewing the code written by a junior programmer? Of course, the answer is yes. This phenomenon is called “the expert blind spot”:

The experts will have difficulty to understand why the beginners don’t understand. For them, the concept feels obvious. The learners, on the other side, won’t be able to ask the good questions either, since they’re not aware of what they don’t know. How to ask good questions if you have no idea what kind of answer you want?

Although the expert blind spot is usually used in the context of teaching, the difficulties a veteran might have to pass along his knowledge in the context of code reviews are similar to our earlier poker example. A senior reviewing the code of a senior tends to have certain expectations about it, which is both a benefit and a risk: certain things might be taken as “obvious” and not be considered until it’s too late.  

After all, anyone who has ever worked on a complex project knows the frustration of feeling where something might be wrong but can’t quite see it. That’s why it’s always a good idea to take a look at it with fresh eyes. In that sense, junior developers can bring a lot to the table when it comes to code reviews, free from all assumptions and rigid pathways that might trip up even the best programmers.

A good way to conduct a code review

The Expert Blindspot, or why you should let junior 2

However, that is not to say that junior developers should bear the entire responsibility of code reviews; guidance and backup are still needed to ensure they are properly conducted during the sprint. In the words of Carlos Estrada, a Lead Developer Application at Scio:

It’s generally a good idea to have a junior dev participate in code reviews, it’s useful for them to see what changes a senior does, and learn to find and track changes, but they cannot be the ones to approve the review. There have been a few internal projects I supervised where mostly juniors were involved, and when the time was short, the juniors had to do it themselves, learning from the comments I have left on earlier reviews.”

In short, junior developers are the backbone of any software development team. They may not have as much experience as their senior colleagues, but they can make up for it with a desire to learn and master the craft, which makes them a perfect addition to a thorough code review: 

  1. As already said, by conducting code reviews, junior developers can see for themselves how code written by a veteran looks; which good practices are implemented, proper comment discipline, and readability, which can help them become better programmers. 
  2. A junior reviewing code can spot mistakes that a veteran might otherwise overlook due to the expert blind spot; a fresh perspective, free of all the expectations and assumptions a senior can unconsciously have, can sometimes obtain a better insight of the code.  

However, not all code review processes are created equal, and for one to be effective, it should follow a few simple steps that ensure the resulting review is useful. Many veteran developers may know these steps by heart, but to a junior starting to learn the value of these exercises, the following procedure is always recommended: 

  • First, developers should submit their code for review early and often.

    This allows for more frequent feedback and helps to prevent errors from becoming entrenched in the codebase. 

  • Second, all reviewers should have a common understanding of the project’s goals.

    This helps to ensure that everyone is on the same page when it comes to evaluating the code. 

  • Finally, reviewers should focus on providing constructive feedback.

    By indicating what works well and what could be improved, reviewers can help developers produce better code with fewer errors. 

So, to recap, code reviews are an important part of the software development process, and juniors can learn a lot from participating in them. However, they need guidance from seniors to make sure that the code is correct and meets the standards that these projects strive for. And the final approval always must come from a senior member of the team, keeping an eye on the process, and making sure everyone can learn from it. After all, experience builds on the chance to bring new perspectives and let them teach new things.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!