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
Communication & teams

How effective pull request reviews transform your team

Steve Jackson
Sam Jones
|
October 26, 2020
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Most software teams we work with have already adopted a pull request review process. The act of reviewing code seems simple, but it’s often time consuming. A deliberate approach is needed for a team to realize the impact of investing their time in pull request reviews.

A good review process fosters leadership, knowledge sharing, collaboration, and more humane communication practices.

Growing leaders

When we’re joining a team, we can often see the structure of influence by analyzing their pull request review habits. The opinions of leaders are sought after, and their direction defines the technical solutions a team develops. However, leadership is actually shown by all members on a team in a healthy review process.

Leadership is demonstrated by authors in the way they request reviews and by who they are bringing into the conversations. On healthy teams, reviewers are deliberately chosen for reasons like:

  • Rachel, you understand ActiveRecord deeply, can you check these scopes to see if they can be improved?
  • Hung, I think this will help with that incident we worked on Thursday. Is there anything else we could add?
  • Justin, this is an example of how we want to test our GQL components. Does this translate easily to what you’ve been working on?

Each of these examples shows the author requesting a review for the purpose of growth and improvement, not just delivering a bit of code. Good leaders are able to prioritize the humans involved, using pull requests as a medium for communication and collaboration.

Knowledge++

When reviewing code, our primary responsibility is to the author and their growth as developer.

Spending time on code reviews is a large investment, and focusing on just the code limits a reviewer’s impact to a single change. Often, taking the time to teach pays off in a way that writing the same comment over and over will not. We’ve also found the best way to teach is through pair programming, and asking to discuss a component of a pull request is a great way to build relationships and encourage the practice.

I have a question about a decision in this PR. Can we pair?

Additionally, large organizations often struggle with onboarding and education. Reviews are a great place to teach and explain the context for shared conventions. When we take the time to explain coding patterns to a new developer it benefits the entire team. A reviewer with this mindset is advancing shared understanding, not just enforcing rules.

Leaders understand that good feedback processes improve the health of a team. Pull request reviews give team members an opportunity to practice giving humane, constructive feedback. We’ve found that we can increase the stickiness of code review feedback when it’s framed as a progressive challenge. Call out things done well and reinforce the notion that everyone is on a journey, and you’re only seeing one stop along the way. We don’t just present our idea of the best solution, we help an author improve theirs.

Progressive mindset

A pull request is a moment in time, and code is malleable. Things don’t have to be perfect right away. It’s more important to empower a team to evolve a solution over time, and grow their abilities to do so. We want to avoid aggressively gate-keeping and withholding approvals.

Ideally reviewers should be extending trust to authors, giving them room to interpret feedback, and allowing them the final decision. This can be difficult for reviewers who feel more responsibility to the application than their peers. It’s hard to stop your contribution at graciously informing the author of the potential effects to quality when they have alternative viewpoints. One useful technique is to categorize your feedback so that it is clear to the author what is critical, and what falls under the category of a non-blocking “nitpick”.

On a large team, it may even be helpful to culturalize this practice with some fun emojis 💚.

Most importantly, though, we try to remain gracious. We remember that just because we see something we’d do differently, we don’t need to request that it be changed.

As Neal Lindsay says:

Sometimes a grain of sand in your shoe isn’t a big enough problem to take off the entire shoe.

Deliberate participation

When we review pull requests, there are many kinds of feedback that we can give. It can be useful to make multiple passes through the review. With each pass, imagine yourself wearing a different hat, using this alternative viewpoint to focus your attention.

There are so many hats you can wear, here’s a list with some of our favorites to get you started.

  • 👷 Safety hat: Will merging this code break anything?
  • 🧑‍🏫 Teacher’s hat: Are there opportunities to share alternative designs, established customs, or to promote consistency?
  • 🥳 Party hat: Can I celebrate the author in this PR?
  • 👨‍🎨 Critic’s hat: Should I comment on subjective things like names, aesthetics, architectural design?
  • 🗣 Conversationalist’s hat: Is there a conversation that should be documented publicly for the team?
  • 👩‍⚖️ Decider’s hat: Do I need to push back on a suggestion or make a decision about the approach being taken?
  • 🔎 Inspector’s hat: Will future maintainers enjoy occupying this area of the codebase?
  • 🧑‍🔬 Scientist’s hat: Are there any performance hypotheses that should be tested before releasing this code?

Active listening

More important than what you will say, is how you will listen to the author. In conversation, active listening is the practice of listening to understand rather than to respond. Growing this skill is vital to increasing your influence, but it can be difficult to practice in a high-bandwidth conversation. Luckily, active listening makes for better reviews. The asynchronous, text based, nature of a pull request gives you more time to understand, and carefully consider your response.

The 3 levels of listening provide a framework for thinking about your listening habits.

  • Internal Listening: Performing a review with the intention of showcasing your abilities and knowledge. Enforcing with the goal of protecting the codebase.
  • Focused Listening: Asking questions to understand the decisions made by an author through code review. Guiding the author to a better solution based on a common goal.
  • Global Listening: Investing time during a review to meet the author where they are and using the review to promote collaboration on the team. Balancing the needs of the codebase with the growth of the author and others on the team.

Intention vs impact

We’ve written before about the importance of understanding the impact in how you communicate in tech.

Interactions in a pull request can change our relationships with team members. All participants must be conscious of the impact they have when delivering feedback. Feedback that elicits the author’s intention is going to be more useful. Enabling growth is tricky to get right and requires some practice. However, it will develop empathy on a team.

When asking questions in a pull request, try to understand the author. Let yourself be genuinely curious rather than make assumptions. Ask questions that support the evolution of the author. Let go of attachment to the sanctity of the codebase.

At Test Double, we like to define success by the growth of the teams we work with, as opposed to the presentation of our own knowledge. We believe team members should take pride in the code they deliver, and that they do their best given the constraints they face. We honor their effort and understand that communicating through text, especially with unfamiliar teammates, can alter a relationship with the humans we work with.

Related Insights

🔗
How to run effective retrospectives for agile teams
🔗
A guide to effective software consulting

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
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.

by
Robert Komaromi
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.