Review Buddies: Pair Programming for the Rest of Us

Looking for a way to increase developer productivity and improve your code review process? Try Review Buddies.

Review Buddies is a development workflow based on pair programming. Like pair programming, Review Buddies involves two developers working together. However, instead of two devs working on one ticket, they’re working on two tickets.

Isn’t that just the normal way things are done, one dev for one task?

I’m glad you asked! Let me explain, but first, a little background.

What Is Pair Programming?

Before diving deep into Review Buddies, let’s review what it’s based on: pair programming.

Pair programming is where two devs work on one task. One dev drives, the other thinks, and both discuss. Drivers switch after a while, and typically the more junior dev or whoever has the least experience with the current task will drive first. Pairs also change periodically, whether that’s weekly or at the beginning of each sprint.

Pair programming has several advantages over the typical 1:1 dev/task workflow, a few of which are:

• Application knowledge is disseminated among more developers.
• Two heads are better than one—Working through sticky problems is easier.
• Increased consistency in the codebase.
• The time required for code review is essentially zero. Some teams don’t even bother with PRs and instead commit straight to develop/master/main.

However, pair programming also comes with downsides. It has the appearance of cutting team output in half since two devs are working on every task. Even though this isn’t really accurate, as tasks can usually be finished much faster than when a single dev is working on them), it can still appear as a loss in output and can be a hard sell to stakeholders as a result.

So how do you achieve the benefits of pair programming without sacrificing perceived output? That’s where Review Buddies comes in.

How Is Review Buddies Different from Pair Programming?

The key difference between Review Buddies and pair programming is having two devs work as a unit on two tasks, each taking the lead (driving) on separate tasks and reconvening later to discuss and review.

Rather than taking turns driving, each dev “drives” on their own task. Then they take turns discussing and reviewing each other's tasks.

Review Buddy Workflow

Okay, cool, so what does this look like in practice? Let’s walk through a Review Buddy workflow:

1. Pick a task and discuss: Get together with your buddy (Slack huddle or something, nothing too formal) and talk over your task, subtasking as necessary, as well as your buddy’s task. Depending on the task, this may or may not always be required, but you should at least send your buddy a link to the task you’re working on so they can review it at their leisure.

2. Setup PRs to share code progress: Create a branch from develop (or whatever your target branch is) and immediately open a Draft PR back into your target branch. Send a link to the PR to your review buddy. Your buddy will do the same and send you a link to their PR.

3. Code, push, review, repeat:

   1. Do your development work like usual, pushing up to your remote branch periodically (this should automatically update the PR as well)

   2. Review your buddy’s progress in their PR at regular intervals and leave feedback as necessary (personally, I like to do this review every day at 4 PM). Your buddy will do the same whenever it’s convenient for them. It may be beneficial to do this over an informal call sometimes for sticky problems or if something isn’t clear.

4. Profit: When you and your buddy agree everything is done and ready for merging, guess what? The PR has already been reviewed! Take off the Draft label, approve, and merge!

And every sprint or so, generate new dev pairs with a pair programming team generator like Random Team Generator.

Benefits of Review Buddies

This gets many of the benefits of pair programming, such as:

• Having someone to bounce ideas off of
• Reducing the time required for code review after completing development
• Spreading application knowledge around the team in a natural way. 

It perhaps doesn’t do these to the same extent as pair programming, but it does so significantly more than the standard dev workflow and without the perceived loss of output.

Review Buddies can be beneficial for any size project team. However, larger teams, 6+ developers, will likely benefit even more since it can cut down on inapplicable cross-talk and distractions that become more of an issue as teams grow. Also, smaller teams are already going to function in a manner somewhat similar to Review Buddies anyway, just by virtue of being smaller.

Downsides of Review Buddies

If you’re coming from a more typical 1:1 dev/task workflow, then it can take some adjustment.

• It’s easy to forget to open an PR right away
• And it’s easy to forget to send a story link to your buddy

Also, like most things, it doesn’t always fit cleanly into the real world

• If you have someone out on vacation for more than a few days, you may need to have them on a team of 3 rather than two.
• If you’re burning through a bunch of 1-2 point stories, the whole process can add unnecessary overhead. Of course, in these cases, an abbreviated process can be used as needed, or even better, discuss tasks as a batch.
• Having 3+ people on a “review team” starts to lose efficiency. For best results, try to keep it to two devs when possible.

What About Larger Review Groups?

Just in my own observation, I’ve noticed on several teams I’ve been on in the past that there seems to be a counterintuitive, inverse relationship between team size and review speed. Intuitively, it would seem like the more people you send your PR to, the more likely there will be someone with some free time to review it. However, this doesn’t seem to be the case.

Many times, the more people on a team, the longer it seems to take to get a PR reviewed. There are likely several reasons why this happens, possibly lack of confidence in reviewing the PR, or just that nobody really has “free time”, and many people aren’t wanting to be taken out of “the zone” and could be relying on someone else to review the latest PR.

Usually, the task of reviewing PRs ends up falling on the 1-2 people who are most proactive about doing reviews, then they end up doing all the reviews in addition to their own tasks. If only 1-2 devs are reviewing code for a large team, this can potentially take up a sizable portion of their workweek just reviewing code, which is less than ideal for a number of reasons.

However, when you send a PR directly to someone and ask them to review it, I’ve noticed that many times they review it either right away or pretty shortly afterward, thus eliminating multiple problems with the review process all at once. Review Buddies bakes this concept into its workflow from the ground up.

But if you increase the number of devs from a pair to a group, then you eventually start running into the same problem again, where it starts to take longer and longer for a review. From just my own observation, this seems to start happening at around 4-5 devs in a review “group”.

I suspect teams of 3+ are possible but would likely need to be based on mob programming principles rather than pair programming. I’ve been putting together a proposal in that vein for my team to try, and might have a “Review Mob” workflow later on if we can make it work, so stay tuned!

Conclusion

Review Buddies is pair programming for the rest of us. Review Buddies has many of pair programming’s benefits without the perceived drawback of reduced output. 

It has made my team’s planning and review processes much more consistent, we like it, and I think your team will too! Mileage may vary, but I think it’s worth trying for a sprint.

Do you have thoughts about Review Buddies?

We’d love to hear them! Join our Community Discord to talk tech with the Bitovi Community 🥚