That’s the short story of not prioritising code reviews. At the core of this is the belief that a task at the In Review stage on your Jira board is a finished task. What I am trying to illustrate, is that a task In Review is actually a task still In Progress. There are often easy ways to speed up the time to get 👍 or constructive feedback on pull requests — so why accept the challenges that come with long-lived pull requests. The longer your PR stays open, the more likely you are to take on additional work, leading to delayed value to customers and decreased productivity due to frequent context switching. At this point you might ask “How do I change that?”.

Figure out your Baseline

The first step to improving the speed of your review process is to figure out how your team is doing at the moment. Start by measuring the time code spends in specific phases of the review process.

⏰ Here at Panaseer we started by looking at the following two:

Time from when a PR was raised to when someone took responsibility for the review and assigned themselves Time from someone assigning themselves to the actual review being added

There were a bunch of other things we could have measured, like the end to end lifetime of a pull request, but we found that for our team those two were the ones where we could make the biggest gains initially.

Once you have the metrics and you know what your baseline is, it’s time to start experimenting to improve the team’s review performance.

The Pull Request Checklist

Once you’ve started measuring review performance, it’s time to look at the process. Below is our checklist for making sure our PRs are not a burden to review.

№1: Automate Away!

If I had to comment every few lines on formatting and code style — I’d procrastinate getting the review in as well! Style and formatting are some of the easiest things to standardise through automation. On the Frontend Engineering team here at Panaseer, we make heavy use of eslint and Prettier. With that in place, there shouldn’t be any need to comment on formatting or style in code reviews.

The other area we automated, focussed on reminding the team of unassigned PRs and assigned ones that are still missing reviews. It’s easy to lose track of pull requests you are assigned to — having something in place that reminds you, helps get reviews in quicker. We’ve been busy, working on some Github and Slack integrations — keep your eyes peeled as we’ll be open sourcing them later this year.

№2: Take Responsibility

A pull request that doesn’t have anyone assigned to it, won’t get a quick review. Unless specifically communicated no one will plan the review into their day and take care of it. Making sure that once a PR is raised — it’s clear who is responsible for reviewing the code, is vital for reducing the PR lifetime and getting it merged in a non-disruptive way.

№3: The Pull Request Size

Keep them small! Break your features into multiple smaller pull request as opposed to dropping two thousand lines of code on your team members. Thorough reviews take a lot of mental energy! Maintaining that level of concentration for several thousand lines is impossible. You might say, actually going through two thousand lines of your code reads beautifully and is like a poem in Javascript, but believe me even the most well-written code hits that limit during a review. We try to keep our pull requests below a thousand lines, ideally well below that.

№4: Don’t Surprise

The code you pack into a pull request is not meant to surprise. For bigger features that involved multiple components and sometimes complex component interactions, use co-design session for the architecture of the feature or pair programming. That way your reviewer is already familiar with the code and the bar to getting a good & timely review in is lower.

№5: Give Up All the Information

Have you ever reviewed a pull request and even though you knew about the architecture of the feature, it took you some time to remember why this feature was being built in the first place? To avoid for your reviewer having to find the related ticket and relevant information manually, standardise the information you provide with pull requests. We started using Github Pull Request Templates and they’ve been helping a lot! Using templates, we can ensure that every pull request clearly states the context of the task, the actual changes, any new patterns that were introduced, what kinds of testing was added and a link to the ticket. I wouldn’t want to review a PR without it anymore! We open sourced our PR templates — if you need a starting point for yours take a look here.

Take Action on Your Team!

The best way to address this problem is to establish a baseline and start experimenting! I hope reading this you got an idea of where to start — some initial ideas to set you on the right path.

👋 Let us know what’s worked for your team! We’d love to increase the number of items on the checklist. You can reach me on Twitter at @BorriesAnton.