Skip to main content
Test Double company logo
Services
Services Overview
Holistic software investment consulting
Software Delivery
Accelerate quality software development
Product Management
Launch modern product orgs
Legacy Modernization
Renovate legacy software systems
DevOps
Scale infrastructure smoothly
Upgrade Rails
Update Rails versions seamlessly
Technical Recruitment
Build tech & product teams
Technical Assessments
Uncover root causes & improvements
Case Studies
Solutions
Accelerate Quality Software
Software Delivery, DevOps, & Product Delivery
Maximize Software Investments
Product Performance, Product Scaling, & Technical Assessments
Future-Proof Innovative Software
Legacy Modernization, Product Transformation, Upgrade Rails, Technical Recruitment
About
About
What's a test double?
Approach
Meeting you where you are
Founder's Story
The origin of our mission
Culture
Culture & Careers
Double Agents decoded
Great Causes
Great code for great causes
EDI
Equity, diversity & inclusion
Insights
All Insights
Hot takes and tips for all things software
Leadership
Bold opinions and insights for tech leaders
Developer
Essential coding tutorials and tools
Product Manager
Practical advice for real-world challenges
Say Hello
Test Double logo
Menu
Services
BackGrid of dots icon
Services Overview
Holistic software investment consulting
Software Delivery
Accelerate quality software development
Product Management
Launch modern product orgs
Legacy Modernization
Renovate legacy software systems
Cycle icon
DevOps
Scale infrastructure smoothly
Upgrade Rails
Update Rails versions seamlessly
Technical Recruitment
Build tech & product teams
Technical Assessments
Uncover root causes & improvements
Case Studies
Solutions
Solutions
Accelerate Quality Software
Software Delivery, DevOps, & Product Delivery
Maximize Software Investments
Product Performance, Product Scaling, & Technical Assessments
Future-Proof Innovative Software
Legacy Modernization, Product Transformation, Upgrade Rails, Technical Recruitment
About
About
About
What's a test double?
Approach
Meeting you where you are
Founder's Story
The origin of our mission
Culture
Culture
Culture & Careers
Double Agents decoded
Great Causes
Great code for great causes
EDI
Equity, diversity & inclusion
Insights
Insights
All Insights
Hot takes and tips for all things software
Leadership
Bold opinions and insights for tech leaders
Developer
Essential coding tutorials and tools
Product Manager
Practical advice for real-world challenges
Say hello
Developers
Developers
Developers
Software tooling & tips

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

PR reviews don't have to be painful. Discover practical, evidence-based approaches that turn code reviews into team-building opportunities while maintaining quality and reducing development friction.
Robert Komaromi
|
August 11, 2025
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

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.

‍

Related Insights

🔗
What happens when code reviews aren’t mandatory? An experiment
🔗
Should code reviews be mandatory? A look at non-blocking reviews
🔗
How effective pull request reviews transform your team
🔗
GitHub shortcut commands that’ll speed up your code reviews

Explore our insights

See all insights
Developers
Developers
Developers
C# and .NET tools and libraries for the modern developer

C# has a reputation for being used in legacy projects and is not often talked about related to startups or other new business ventures. This article aims to break a few of the myths about .NET and C# and discuss how it has evolved to be a great fit for almost any kind of software.

by
Patrick Coakley
Leadership
Leadership
Leadership
Turning observability into a team strength without a big overhaul

By addressing observability pain points one at a time, we built systems and practices that support rapid troubleshooting and collaboration.

by
Gabriel Côté-Carrier
Developers
Developers
Developers
Build with HTMX: Simplify development with a return to fundamentals

Modern web development embraced complexity with frameworks like React, but at what cost? HTMX is a lightweight, progressively enhanced alternative, embraces web fundamentals, and reduces dependency overhead. Through a side-by-side comparison of identical applications built with React and HTMX, this screencast and blog explores the benefits of a hypermedia-first approach and when it might be the right choice for your projects.

by
Dave Mosher
Letter art spelling out NEAT

Join the conversation

Technology is a means to an end: answers to very human questions. That’s why we created a community for developers and product managers.

Explore the community
Test Double Executive Leadership Team

Learn about our team

Like what we have to say about building great software and great teams?

Get to know us
Test Double company logo
Improving the way the world builds software.
What we do
Services OverviewSoftware DeliveryProduct ManagementLegacy ModernizationDevOpsUpgrade RailsTechnical RecruitmentTechnical Assessments
Who WE ARE
About UsCulture & CareersGreat CausesEDIOur TeamContact UsNews & AwardsN.E.A.T.
Resources
Case StudiesAll InsightsLeadership InsightsDeveloper InsightsProduct InsightsPairing & Office Hours
NEWSLETTER
Sign up hear about our latest innovations.
Your email has been added!
Oops! Something went wrong while submitting the form.
Standard Ruby badge
614.349.4279hello@testdouble.com
Privacy Policy
© 2020 Test Double. All Rights Reserved.