Pair Review: Streamlining Complex Code Reviews with Pair Programming

Last updated June 14, 2023 By davegaeddert

Reviewing complex code on GitHub can be harder than writing it. Large git diffs, detailed explanations, and too many comments can overwhelm both reviewers and authors. It can also drag out for days.

For times like this, consider using the ideas and benefits of pair programming, but specifically for code review. Which is a fancy way to say, just talk to each other face-to-face!

Some organizations embrace pair programming wholeheartedly — having two people work on the code in the first place can be used as an alternative to code review. But daily pairing is not right for everyone. Which is why we suggest the term "pair review" to better recognize when the back-and-forth, asynchronous communication isn't the right fit.

Pair review simply means jumping on a call (or sitting together in-person) to review the pull request together. You can use tools like Tuple or Zoom to share your screen and talk through the changes.

When to Request a Pair Review

Knowing when to ask for a pair review is key. If an author knows their changes are complex or might raise difficult questions, they should ask for a pair review right off the bat. Reviewers can also ask for a pair review — if they see a big git diff and don't know where to start, or the conversation gets out of hand, a pair review can help get on the same page more quickly.

Why a Pair Review Can Be Better

Pair reviews have benefits for both authors and reviewers.

For authors:

  • Scheduled Interaction: Having a set time for a review means they don't have to keep reminding reviewers.
  • Guided Explanation: The author leads the review, so they don't have to figure out how to guide the reviewer through a pull request in writing.
  • Direct Feedback: Getting feedback right away can help avoid misunderstandings and give a chance to provide explanations.

For reviewers:

  • Focused Review Time: Getting it on the calendar can turn an intimidating review into a manageable task.
  • Reduced Back-and-Forth: Fewer written comments can speed up the review process.
  • Workflow Observation: Seeing how the author works can lead to better ways of working.
  • Minimized Setup: The author leads the review, so the reviewer doesn't have to do as much setup.
  • Better Communication: Leaving critical feedback in writing can be hard. Talking directly to the person is often easier to find the right tone.

Even with these benefits, pair reviews might not always be the best choice. If the changes are small or easy to understand, a traditional review might be quicker. If the reviewers know the part of the code that's changed, a traditional review might be enough. The key is to pick the best review method for each situation.

Leveraging Git Co-Authors with PullApprove

One way that PullApprove supports pair reviews is by detecting git co-authors. When you're working through the review, it's common to make a few small changes while you're on the call together. By tagging the reviewer as a co-author of the change, PullApprove can automatically count it as an approval.

You can interactively set the co-author in GitHub Desktop or VS Code, but you can also do this in the commit message yourself with the Co-authored-by trailer.

In PullApprove, you can use the co-author value to count the applicable co-authors towards the approvals required.

Future?

Are there more ways that PullApprove could support pair reviews? Ultimately, it's a "soft" problem that people can already address with existing tools. During a pull request, someone can "manually" ask someone else to do a Zoom call and schedule a time for it.

For PullApprove we're debating whether there's a role for us to play in this process. For example, imagine an explicit "Request a review session" button that would:

  • Prompt you to pick a few times that work for you
  • Send those options to the participants
  • Find the best time for everyone
  • Send out a calendar invite
  • And maybe even upload a recording of the call and transcribe it for future reference

All of these things are possible today with existing tools, but it could be valuable to encourage and streamline the process.

If you have any suggestions or feedback, find us on Twitter @pullapprove or contact us here.

Ready for a better workflow?

PullApprove starts in a read-only mode where you can see how it would work for your company. Anyone with permission to install the GitHub App can give it a try, and you can always uninstall it if you don't like it.