Intro
I’ve been researching ways to speed up PR reviews since I review a lot of them as a tech lead. This post discusses what I discovered that has helped me do that.
To be clear, I’m not implying that you should be rushing your PR reviews. As a developer, it’s one of your most important duties. When you review a pull request that comes with a significant impact on your codebase, you should take your time to ensure that the code is well-written and covers all edge cases. This post simply talks about how you can speed up the process intelligently.
Let’s get started!
Start reviewing right away
Start your PR reviews as soon as you can. It might seem counterintuitive at first, but starting your PR reviews soon has a lot of benefits, including that your PR reviews will ultimately take less time.
Minimizes context switching
Developers typically spend five to ten minutes self-reviewing the PR they submit, and their minds are still focused on it. When you begin reviewing, commenting, and engaging with the developer right away, they will respond quickly and answer your questions better because the problem is still fresh in their minds.
Instead, If you wait a couple of hours before reviewing the PR, the developer will most likely start working on a different task. Switching back to the PR context takes time, so it will take them longer to understand and respond to your comments.
When you regularly review PRs soon after receiving them, it will also encourage other developers on your team to write smaller PRs. Seeing that smaller PRs don’t take as long to review will start a continuous cycle of smaller PRs and faster shipping to production.
It might slow you down at first
Initially, reviewing PRs quickly could slow you down a bit but that’s okay since you’re boosting the productivity of your team as a whole. Consider making it a point to mention during your standups that you’ve spent time reviewing PRs if it starts taking up a lot of your time.
With all that said, postponing reviewing PRs right away is fine if you’re in the middle of an active coding session and are in the “zone”. When you switch contexts frequently, you hurt your productivity and the productivity of your team. So it’s okay to wait until you’ve achieved a good stopping point in your own work.
Ask questions
I used to take pride in figuring out things without asking for any help. However, if you want to speed up your review process, ask clarifying questions more often. It takes a lot of effort to understand other people’s code, and asking for clarification isn’t shameful.
The other developer will also see asking questions as a normal part of working on your team, which improves team communication and collaboration.
Start with the large parts
First, try to figure out the code that affects the design of your application in a significant way. Look at the changes in data models, classes, and high-level abstractions that are important. This will help you understand the smaller changes and generally speed up your code review.
If you see that something big is incorrect, send comments immediately and do not wait to review the whole thing. You can even pause any further review and ask to address these issues first.
Another tip I found helpful was to read the acceptance tests first. It helps you understand what the code is supposed to do and see the edge cases.
Try not to be overly rigid
Again, this does not mean that you should sacrifice the quality of your code. It just means that spending hours on small details might not be the most productive use of your time. Keep in mind the law of diminishing returns .
Approve now, fix later
There are times when it’s okay to approve a PR, even though you are also leaving some comments unresolved:
- You are confident that the developer will address your remaining comments.
- The remaining changes are minor, and the PR would still be acceptable if they weren’t resolved.
This practice is particularly handy if your team is spread across several time zones. This will help all of you conserve time with back and forth conversations.
You don’t always need to test manually
If you have confidence in the developer’s competence, you may not need to test their code manually. For example, you can ask if they have dealt with a particular edge case or ask them to record a screencast for you. I like to use Loom for quickly recording demos when submitting PRs if it’s easier to explain things that way.
As a general rule: If a pull request contributes to the overall quality of your application and provides new functionality, you should lean toward approving it.
Use better tools
Before working on any task that requires a lot of mental effort, I like to spend some time making sure I’m using the best tools for the job first.
In my research, I found some tools that allowed me to review pull requests at a faster pace and with greater understanding.
Codestream
Codestream is a VSCode extension that allows you to review PRs right from your editor. Unlike the web Git interface that only shows line diffs, Codestream lets you view the whole file in your editor, so you’ll get a better picture of how PR changes affect your app.
Codestream also minimizes context switching since you don’t have to switch between your editor and the web interface for reviewing PRs.
Better pull requests
Better pull request is a small Chrome extension that adds the file tree feature to the web interface of Github PR reviews. Reviewing pull requests with a file tree reduces the mental toll required to navigate through the changes.
I’m sure there are other great tools out there, so do your own research and get creative!
Conclusion
Many people view reviewing PRs as an easy activity. In reality, it is just as challenging as writing code; you often end up solving the same problems in your head as the code you are reviewing.
Hopefully, this post gave you some actionable tips on how you can start reviewing PRs faster.
If you’d like to get more web development, React and TypeScript tips consider
following me on Twitter,
where I share things as I learn them.
Happy coding!
