PR reviews are underrated

I feel like pull request reviews are such an underrated part of the software development process. I think many developers consider them a bit of an extra chore, something that adds little value and just distracts them from their more important work. I've even worked in organisations where we didn't do PRs at all, just shipped code directly to production, and seen the consequences of that.

PRs are the primary way developers discuss, collaborate and learn from each other. They're something you need to get right if you're a team of more than one or two people and you want to get stuff done.

I've personally always enjoyed doing PR reviews and commenting on other people's work, and have actively made it a priority in my work. In this post, I'll try to go through how you can take PR reviews from feeling like a chore to being something that you actually look forward to doing!

But it takes me out of "the flow"

One of the most common complaints I hear when it comes to PR reviews is that it never feels like a good time to stop what you're doing and switch to reviewing something (often) unrelated. I get it!

One of my key realisations over the past few years is that "the flow" is a bit of a myth. If you're relying on some magical, uninterruptible flow state to get your work done, you're setting yourself up for failure. The reality is that you're going to be interrupted, and you're going to have to figure out how to get your work done even when you're constantly switching contexts.

I think the key thing to embrace is to split your work into smaller chunks. And I mean a lot smaller! If you're working on a feature that takes you a week to complete, you should aim to split it into smaller chunks of work that take at most an hour or two to complete. This means that every day, you're probably looking at putting out one or two PRs for others to review.

With this kind of approach, you're forced to plan your work ahead of time. You can't just jump into work and see where it takes you; you need to have a clear idea of what's a realistic scope to get done in a day, before you begin. This is a good thing: it means you're less likely to get stuck in random rabbit holes, and will ultimately find yourself being a LOT more productive.

Once you're in this kind of workflow, where every hour or two you're able to reach a "checkpoint" in your progress towards a bigger objective, you'll find you suddenly have multiple opportunities during the day to switch to reviewing someone else's code without losing focus on your own work.

But I don't have anything to comment on

It's not really the act of commenting that's the most important part of PR reviews. I'd say it's the act of going through the PR, and just thinking about the code. Here's some of the things I'm thinking when reviewing someone's PR:

• Is this code easy to understand? If not, why not?
• Would I have done this somehow differently? If so, how?
• Is there some kind of edge case that hasn't been considered?
• Is there some other work that is affected by this PR that the author might have not considered?
• Is the PR even solving the right problem?

Sometimes these thoughts lead to comments, sometimes they don't. But the act of reading the code and thinking about it has already made you a better developer.

And sometimes you'll read the entire PR and not find anything that would be worthwhile to comment on. And that's great - the one comment you can then leave is some kudos to the author for doing great work.

In the vast majority of cases though, there's always something to comment on. If you're often struggling to find things to say, you're probably not putting enough mental energy into the PR review process. There's an endless amount of angles you can take to reviewing someone else's work. As you do more of it, you'll get better at it, and you'll find it easier and easier to skim through the unimportant parts quickly, focus in on the important parts, and find things to comment on that help the author improve their work in a meaningful way.

But I don't have time for this

Reviewing PRs takes time, but not as much as you might think. If you feel like you don't have time for proper PR reviews, you're failing to realise that it's a core part of your job as a software developer. It would be like saying that you don't have time to write tests, or to write documentation, or to build features to the end.

For me, the key idea is to make PR reviews feel like a zero-time activity. What does this mean? It means that you should learn to multi-thread your work. Aim to find a way to review PRs while you're personally waiting for something else to happen. For example:

• You're waiting for a build to finish... review a PR!
• You're waiting for a meeting to start... review a PR!
• You just submitted a PR yourself... review someone else's PR while you're waiting!

If you stop and think about it, there's an endless amount of 15-minute gaps in your day where you could be reviewing someone else's work.

But the PRs are so large and complex

If a culture has been born where PRs are often very large and complex, it's going to be a real struggle to get people to review them, and to get any useful comments.

It's not your shortcoming if you're struggling to review a PR with 5000 lines changed which touches 30 different files. This is a failure of the author or the team to break down their work into smaller, more manageable chunks.

As a team, you need to work together to break this cycle. Everyone needs to make it a priority to make their own work as easy to review as possible. Going back to the first part of this post, everyone should be submitting at least one PR a day, and they should be small and focused.

As a rule of thumb; a good PR is something you can understand and review in under 10 minutes. If not, the PR is usually too big.

When you come across such a PR, don't just accept it as it is. Tell the author that it's hard to review, and ask them to split it up into smaller chunks. Eventually, everyone will realise that the way to get their work merged the fastest is to put in a bit of extra effort to make it easy for others to review.

Wrapping up

The highest-performing teams I've been a part of have always been the ones where PR reviews are considered a top priority. In these kinds of teams, the first review for a PR often comes in under an hour - and it's usually an approval because the PR was polished, small and focused to begin with. A good PR review culture is the difference between teams that are shipping changes to production every day, and teams that are struggling to get anything done.