Tinkerer

Code and Climate Change. Blog about software development in ClimateTech RSS Icon


4 Ways To Make Your Pull Requests Faster To Review

It can be frustrating to wait for someone to review your pull request.
While everyone is interested in pull requests getting reviewed as fast as possible, reviewing code takes time.
Here’s 4 ways to make your pull request as easy to read, and as fast to review as possible.

1. Keep It Short

Pull Requests that are shorter, are much faster to review.

The shorter your pull request is - the better:

2. Split Your Changes Up

To keep pull requests short, you’ll often need to split the work you’re doing up into multiple pull requests.
While working, you might spot something that needs to be refactored, or a rename of a field that will touch many files.

Don’t make the changes directly in your branch1 - instead:

  1. Branch out from main again and do the refactoring
  2. Create a PR with the refactoring into main
  3. Continue work on your original branch

Instead of having one PR that touches many files, you’ll have two isolated PR’s. Each which does only one thing.

3 Write A Good Description

The reviewer has to understand what was changed in the PR and why. The easier you make this - the faster the review.

You should add a clear description that tells the reviewers what changes the PR contains and the purpose of them - sort of like an introduction to the code.
This description can also help future-you. When you’re looking at that code in six months, good commit messages and pull request descriptions are invaluable.

If anything needs to be manually tested by the reviewer to ensure that it works, make sure to also include a short description on how the reviewer can test this. In complex cases, it might also be beneficial to describe what result the reviewer should expect from running it.

4. Leave Comments For The Reviewer

It’s okay to write comments in the PR for the reviewer.
These comments can be used to proactively describe file moves or other things, you might expect the reviewer to ask questions about.
Note that these comments are different from comments you’d normally leave in the code. They’re codes that might not be relevant in six months, but which are relevant when the reviewer is looking at the code now. Examples could be:


Doing all of these things might seem like extra work, but most times the 10 minutes you spend on creating a good, reviewable PR, are saved in terms of less back and forth with questions and discussions between you and the reviewer

  1. Definitely do make the changes though. Boy Scout Rule and all. 

  2. Depending on the issue, this might actually be worth having as a code comment. 

Did you enjoy this post? Please share it!