Code Reviews 🔍
Strategies, tools, and guides to make faster and better code reviews.
Shipping fast and often is the #1 element shared by top performing engineering teams. Elite teams release multiple times a day, and it takes less than one hour to go from code committed to code successfully running in production.
This idea was made popular in 2018 by the Accelerate book — a thorough research study that convincingly linked good business results to good DevOps metrics.
I also wrote about it in the past:
Three years after Accelerate, this is even more true. As highlighted in the recent State of DevOps report, by Google, the share of "elite teams" jumped from 7% in 2018, to 26% in 2021.
How is this related to code reviews? 👇
🔍 Code Reviews
Code review is the process of having one developer (or more) to review another developer's code before release.
Code reviews have two main goals:
Improve quality — of code before being released
Share knowledge — across the team
These are both crucial goals. Better quality translates into less failures and less maintenance down the line. Sharing knowledge makes teams more resilient and engineers grow faster.
This has been proven time after time, but still, in this need for speed, reviews are one of the biggest offenders.
When you think about it, we may work hard to shave 5 to 10 minutes off our deploy pipeline, and then add hours of delay as the code is stuck in review.
For this reason, the whole process is still somewhat controversial, with many proposals to make it better.
These proposals are not necessarily at odds with the two main goals. I am a strong proponent of good code reviews, but I also believe the standard PR process is wildly inefficient.
This article is about how we can optimize reviews and PRs to be as fast as possible, without compromising on quality and knowledge sharing.
It includes:
🗺️ Tactics — practical advice on how to improve your code review process.
📋 Guidelines — how elite companies like Google, Yelp, and GitLab do code reviews.
🔨 Tools — to help you make faster and better reviews.
📚 Readings — the best articles I know about the topic.
Let’s go 👇
🗺️ Tactics
Here are seven actionable tactics you can use to do good reviews, faster. As you will see, they are more about the process than the review itself.
1) Keep them small
Doing small PRs is one of the best ways to have a short turnaround.
How small? In my experience, if you break down work properly, 90% of the time you can issue PRs that are less than 200 lines of code.
You can go even further: at Google, 90% of code changes are <24 lines of code.
Small PRs improve both speed and quality:
Speed — reviewers need to block a smaller time to review it, so they are more likely to be able to do it sooner.
Quality — fewer lines of code means the change is easier to understand, which leads to better reviews.
2) Do them as soon as possible
Even if you want code reviews to be asynchronous, you should be adamant about doing them as soon as possible.
When the code is stuck for hours (or days!), the author needs to switch to something else while they wait for it — and when the review is ready, they need to context switch again to make changes or fix bugs.
This leads to cascading delays that ultimately have a strong impact on your velocity.
Here are two ways you can help your team have a quick review turnaround:
🚨 Set notifications — simple notifications go a long way. Tools like LinearB or Botany can notify developers when a review is required on their side. We made an experiment with Pull Panda (now retired 😢) years ago and it halved our review time.
🎯 Set goals — analytics tools like Waydev and LinearB help you discover how long it takes for your team to review code. Use them to assess your current situation, set improvement goals, and discuss them in retros.
3) Automate parts of the review
Make the reviewer do less work by automating part of their job. A few ways: