Introduction: Who Benefits From Code Review?

Code review is probably one of the most well-researched software development practices. There’s strong evidence that the code review process has a positive impact on software quality. And pretty much everyone agrees that having another pair of eyes on your code is a great way to level up as a developer.

Anecdotally, however, I haven’t seen much discussion around the benefits of being a code reviewer. I find this curious because I attribute a good part of my growth in recent years to doing a ton of code reviews. So I thought I’d share the top three ways in which reviewing code has made me a better engineer.

1. ”Nanoblogging”

Teaching others is one of the best ways to learn. You may have heard the advice: to get a solid grasp on a subject, write a blog post about it.

Well, oftentimes writing code review comments is akin to blogging. Commenting on a non-trivial issue you’ve noticed in a pull request can involve finding articles to support your points and double-checking your own understanding of the problem at hand. The comment itself becomes a short article, and even though your audience is small, all the benefits of teaching kick in. I would call this process ”microblogging” but that term is already taken. ”Nanoblogging” perhaps? 😄

2. ”I Know Kung Fu!”

In The Matrix, Neo (Keanu Reeves) instantaneously becomes a martial arts master after a machine dumps data directly into his brain. The data essentially simulates thousands of hours of training, so Neo is able to master kung fu without actually stepping into the dojo. Something similar happens when you review code.

The amount of coding situations you’ll find yourself in over the course of your developer career is finite. All those situations and the ways in which you respond to them ultimately form your experience. Reviewing someone else’s code expands that set—your exposure is no longer limited by the tasks you work on yourself. Code review gives you the opportunity to put yourself in the author’s shoes and ask yourself, ”How would I implement this? Could I improve on this solution?” In doing so, you’re simulating in your mind a situation you may not have encountered otherwise.

Granted, it’s not quite the same as actually working on a task and writing code on your own, and your thinking is biased by seeing one possible solution. But if you work through enough of these simulations, I’m sure you’ll start to reap the benefits. I can’t promise that you’ll learn any martial arts that way, though.

3. Expanding Reputation

In organizations with more than a couple of engineers it’s not realistic for a single person to review every change being made to the codebase. If there is more than one team, you usually end up reviewing code your immediate team is responsible for. Naturally, providing valuable feedback in a tactful manner helps you gain recognition within your team.

As I got more senior, I’ve been able to step this up a notch. I follow a few repos other teams work on. Then whenever I have some downtime, I skim the PR notifications from those repos and see whether I could be of help to the folks there. The time I can dedicate is limited, so I can usually respond to just a few of those notifications at a time and I need to be picking them strategically. This process almost deserves a post of its own, but here I’ll list a few rules of thumb I apply when choosing which notifications to open and comment on:

• If the author is struggling with something, is the problem small enough that I can help them without needing a ton of context I may be missing?
• Say I noticed a problematic part in the PR. Is it likely that the author’s teammates may miss it? In case the author has a question that I can answer, is it likely to be left unanswered if I don’t chime in?
• Do I have enough time to leave an informative and considerate comment?

If the answer to all of these questions is ”yes”, I usually go in and leave a comment. Examples of issues I often help with include tricky JavaScript/TypeScript questions, tooling issues (Babel/Webpack/Jest/etc.), and npm gotchas.

This approach is not without caveats and I wouldn’t blindly recommend it to everyone. I strive to make sure that my coworkers are okay with receiving unsolicited feedback on their PRs, and that the time of both parties in these interactions is used effectively—hence the rules of thumb above. But so far the outcome has been overwhelmingly positive: by helping out many of my peers, I’ve been able to build reputation and relationships beyond my own team. If you decide to try this out, let me know how it goes!

Conclusion

There’s more to love about reviewing code but I feel like these three aspects are the most shareworthy. I hope this has been helpful and I’m curious what everyone’s experiences are with being a code reviewer!