The one code review method to rule them all

November 14, 2021

One thing most of us can agree on, and for once the data seems to support us, is that code review is good for us.

What we can’t seem to agree on is how to do code reviews. There seem to be two basic camps these days; those who prefer either:

  • Peer Programming
  • Pull Requests

So which is the one true way?

There are some pretty strong arguments in favor of peer programming. This is by no means an exhaustive list:

  • Real-time knowledge and context sharing
  • Excellent mentoring opportunity when you pair a more senior dev with a less senior one
  • No lag, waiting for code review in the PR model

Those sounds pretty compelling. So what are the arguments for pull requests? Also not an exhaustive list:

  • They don’t require a synchronized schedule
  • Avoids the potential problem of the code being reviewed by a peer who is “too close” to see the flaws
  • Easily allows for more sets of eyes, when appropriate, which can be beneficial for mentoring

So both methods appear to have some benefits, and some drawbacks. So which method should you use?

The one true code review method is…

drum roll, please

the method that optimizes for what your team and situation most needs!

If fast throughput is the most important thing on your team, and you have enough engineers working concurrently, and you don’t care that your code may suffer by not being reviewed by someone who’s hasn’t been staring at the code for 8 hours, then using peer programming in lieu of pull requests is probably the right choice.

On the other hand, if your team often works asynchronously, or you value extra eyes on some of your code for the sake of either mentoring or code improvement, or you aren’t (yet?) comfortable with pair programming, then maybe pull requests are the best bet.

Of course, you can also do both. I once worked on a team that agreed that every line of code should be reviewed before merge, but that if the code was written during a pair programming session, that counted, and the PR could be merged immediately.

TL;DR; Find a method that works for you, and don’t let anyone guilt you into thinking your way is “wrong”, if it works.


Related Content

Better code review

How can we encourage less superficial code reviews?

When is a pull request too big?

Smaller pull requests are faster to write and easier to review. Here are 4 tests to see if your PR might be too big.

Responding to “No code reviews by default”

Every team is different, but one thing is the same: all want to build the best product in the shortest time. There are different ways to achieve this.