Three Ways To Develop, #2: Pair Programming

Programming with a pair is preferred by most agile development teams. It’s undeniable that pairing improves code quality, promotes learning, and improves team morale. Having a pair should help you feel empowered, supported, and confident in the code you produce together. But that doesn’t mean that pairing all day, every day is an effective approach.

In this three-part series, I’m exploring different ways to work on software development with and without your teammates. Hopefully, this will help you find a better balance when building your code.

  1. Working Solo
  2. Pair Programming
  3. The Swarm

Optimal Responsibilities

Pairing is such an effective use of developer time because it allows the pair to share responsibilities. The driver focuses on the now — the code they’re writing, upcoming tests, how existing functions might be used, etc. It’s a very active, focused role. The navigator, meanwhile, pays attention to the driver — catching spelling errors, doing real-time code review, and thinking about the long-term impact of the new code.

The real power of pairing comes from the pair comfortably and easily switching between these roles throughout the pairing session, allowing each person time in the driver’s seat and as navigator. By leveraging this power, both developers come away with confidence that the code they’ve written not only meets the requirements but is the best that they could do.

Wandering Focus

However, pairing isn’t always necessary. When a pair works on a problem that doesn’t require both developers’ full attention, they can easily get distracted. This lack of engagement immediately breaks the power of pairing. Not only are they missing responsibilities, but if one pair starts disengaging while the other remains focused, it can lead to tension or a lack of trust between the pair. That, in turn, could lead to even less effective pairing down the road.

Personally, I’ve found that the best way to avoid this situation is to allow developers on your team to decide when to pair up or work solo. This empowers the team, and it gives each person the space to make optimal decisions based on their circumstance.

Fatigue Is Real

The pairing process requires trust, engagement, and communication. All of that can be exhausting — especially when it all must be done remotely. I think anyone who’s fortunate enough to be able to work from home during this pandemic knows about “Zoom Fatigue.”  Spending all day on virtual calls requires a kind of attention we’re not used to offering for whole workdays.

Pairing suffers from Zoom Fatigue just as much, if not more, than other forms of virtual engagement. Even if your story benefits from pairing, if you’re too exhausted from being on calls all day, you won’t be an effective pair.

In this situation, try to find alternative work that gives you a break from the call to recover. Maybe take an hour off the call to do some solo investigating, or take some time for code review.


Pair programming can leverage developers’ experience and help them write better code. But it’s not a universal solution, and it needs to be balanced to accommodate the developers’ fatigue.

But what about when two isn’t enough? In the next and final part of this series, we’ll look into when even a pair needs backup.

Three Ways to Develop

  1. Working Solo
  2. Pair Programming
  3. The Swarm