Every code has its audience

My humble opinion on who should be included in your code review

An educated guess that from time to time, you’ve encountered the question of who should be involved in code reviews. Well, my colleagues and I found ourselves dealing with it, and the arguments about what’s the proper way, go in various directions; Hence I’ve decided to get to the bottom of this critical subject and write my views.

One clarification before you’ll continue reading, I assumed that the readers agree with code reviews necessity as part of software development, while writing the following lines (examples supporting this fact — #1, #2 and #3).

Now that’s being said. I’ll try to illustrate my experience and beliefs about being a code reviewer.

Title or Seniority? It depends

I want to talk about the elephant in the room or, in other words — the fundamental concern when choosing who should perform a code review. Whether she should have a specific title (tech lead, architect, etc.) or seniority (which sometimes points on the title too).

In my perspective, one of the primary objectives of code reviews is knowledge sharing (others are better communication, find potential issues, improvements, and more). It implies that for choosing a suitable person, one should be capable of sharing insights about it. Hence, the audience should be tuned (one or more participants, depending on the scope).

An example is when a less experienced engineer (as defined by his employer) with broad knowledge on a specific development language, reviewing a more experienced engineer (titled as Senior). Only for a reason the code being developed is written in that particular language.

Beyond the tech-stack experience, the domain has to be considered too. Take, for instance, a developer with 15 years of experience but with 1 or 2 years in the industry’s domain, can find herself receiving feedback on her code by a less experienced engineer with only five years, all in the same industry. Just for the fact he has vital domain knowledge.

So less experienced out?

I believe that everyone in the team should be involved on both sides of code reviews. I can’t tell you how many times I’ve had to explain a piece of code to someone and suddenly come up with a much better way of doing it by the end of the explanation.

If a “Junior” programmer cannot understand a senior’s code, then that in itself is a good measure of the code. In that case, maybe pair programming should be suggested in the future (and better testing 🤔), to bridge the gap. Anyhow, yes, there are times which only a few understand the code, but hopefully, those are exceptions. Imagine what happens when an issue is being raised on that specific piece of code, and the people who understand it are not available.

To overcome this concern, making sure less experienced team members are participating in code reviews as much as possible. It is crucial for their career development and for the whole team’s success. In such a way, they’ll be able to learn the code review process, the codebase and even an opportunity to ask questions and understand what is expected from them in not only code reviews, but in the code that they’ll produce. A fact which turns any code review an excellent learning opportunity.

A word of caution, though; the audience should be limited to allow proper reviews. Also, keep in your mind that there’s a risk with reviews being bogged down with non-issues, based on the developer’s learning curve — so patience should be embraced and open-mindedness for this approach.

Overall

A code review side effect is twofold; it helps everyone understand the code base, thus shares the knowledge and forming collective ownership. It creates the opportunity for less experienced developers to learn new and/or better techniques from more experienced developers.

Furthermore, a byproduct of this procedure is that the seniors refine their understanding, which ensures everyone can follow the code and having more eyes that can catch mistakes. Oh, and eventually, the team grows into a more experienced one.