Why I actually enjoy PR reviews (and you should, too)

Introduction

Evaluating code changes before merging or accepting them is a process that comes in many shapes and sizes and is called by many names: code review (CR), PR (pull request) review, MR (merge request) review, peer review, etc. I do a lot of work within GitHub, and so I’ve become accustomed to using the term PR review, and it’s the term I’ll stick to in this article.

People often complain about the PR review process, saying it’s not the most fun part of their job, and it is often viewed as a necessary evil. Well, I’m here to tell you that it doesn’t have to be that way! PR reviews can be fun, educational, and engaging if done right and viewed through the right lens.

Why pull requests are great

Developers will put in considerable effort to write up a quality feature or bug fix, and then think “Urgh, now I just need someone to approve it.” They then proceed to slap together a PR and wait for an approval. It’s like spending hours baking a beautiful cake, and then ruining the presentation by quickly smearing the frosting on with your hands.

PR reviews are so much more than a begrudging final step to get your code into production. Treat PRs as a way to really show off the great work you’ve done, and to help build up the rest of the team.

PRs help keep everyone in the loop on product updates and changes. If you’re working on a codebase, it’s difficult to keep track of who’s working on what. What did James say in standup yesterday? Where’s that Slack announcement Ted made about what was shipped? With PRs, code changes are presented in an easy to search and filter view on GitHub’s pull requests page. When a pull request is created and subsequently merged (or closed), it’s a valuable signal about the state of the project, and a great tool to communicate progress.

PR reviews also present an opportunity to discuss technical details and disseminate technical knowledge. It’s a great way to incrementally level up the team. Don’t view it as a rubber-stamping process, but view it as a way to learn from the code that was written.

Now, you might be thinking, “I already know why PRs are useful, but as a PR reviewer, they are still frustrating.” And I’ll dig into that next!

How not to treat PR reviews

There are a few pitfalls when it comes to PR reviews that you should avoid:

1. Don’t gatekeep PRs. 

Don’t treat PR reviews as a way to gatekeep or to impose your personal views onto the team. What are considered blockers should be established in some sort of “ready to merge” document or based on clear acceptance criteria, not made up on the spot.

And code-wide style and architecture changes require a team discussion and dedicated effort, not a passing judgement as a PR comment. Focusing on learning will make reviews easier and more pleasant for everyone.

2. Avoid shifting blame.

As a PR author, this is not your opportunity to shift the quality or outcome burden onto reviewers. Listen to reviewers, consider their opinions and point of view, but do not treat it as a process to hand off the baton.

3. Too many PR rules create friction. 

This feeds into the above point—rules are generally there to shift responsibility, and they introduce unnecessary friction into the review process.

Examples of rules that disincentivize PR reviews include:

• Dictating that PRs can only be reviewed at specific times
• Only if certain CI/CD pipelines run and pass
• Specific people need to review specific parts of the PR

Making PR reviews easier

1. Create PR templates.

The less you have to think about the process and boilerplate, the more fun it gets, and the easier it is for you to simply plug in what you already know: What your PR is introducing and why. This also makes PR reviews easier as the consistency introduced by PR templates will reduce the cognitive shock of dealing with a dizzying variety of PR descriptions and outlines.

2. Add videos and/or screenshots to PR descriptions.

A picture is worth a thousand words, and a video is worth… a million words! Visual aids make it so much easier to understand what a PR is changing, and avoids you having to read through a detailed description that will tire you out before even getting to the code.

3. Break down large PRs.

This should ideally be done at the start of a development cycle, during planning. This not only helps with understanding and estimating the work, but it’s easier to put together and review smaller PRs vs. larger ones. This doesn’t mean you should create a massive change, then arbitrarily break it down just so the diff is some arbitrarily small number. Each PR should still deliver value on its own; PRs should be stacked in a logical way, and build off one another. Don’t overwhelm your team with a sudden 10 part PR.

4. Use tooling to attach preview deployments to PRs for easier testing.

Playing with software is fun, and a great way to verify your understanding of the code without having to ask questions about it or go through the process of pulling down the code and running it locally.

5. Pair on reviews.

Pair programming doesn’t have to stop at the PR. As the author, it’s sometimes much easier to walk someone through your changes, and is a great way to build rapport and trust with your team.

6. Don’t make reviews mandatory.

This is something we’ve blogged about before. If you have integration tests that must pass before a PR can be merged, a QA environment, a practised process of rolling back or disabling code that causes issues, and trust in your team, then there’s no reason to indefinitely block PRs on review. 

Instead, set a reasonable timeframe to allow for review before merging, and don’t be afraid to continue discussion on already-merged PRs. If there aren’t critical issues with the original PR, things can always be cleaned up in a follow-up PR.

Reviewing pull requests is a valuable skill

In the age of LLMs and agentic coding tools, code reviews aren’t just a process limited to PRs. When working with tools like Cursor or Claude Code, you’ll often be tasked with reviewing the LLM’s output at key points. So, creating a healthy process with reviews will be a valuable skill that can carry over from GitHub PRs to working with agentic tools.

Closing thoughts

These aren’t hard-and-fast rules that will magically make PR reviews enjoyable, but they’re lessons I’ve picked up over years of working with many different teams. They’ve consistently helped make the review process more collaborative, engaging, and effective.

If you’re feeling burned out or frustrated by reviews, it might be worth stepping back and questioning some of the assumptions you and your team hold. Small mindset shifts—and a few practical tweaks—can go a long way in making PR reviews something to look forward to, not avoid.

‍