Pair Programming: A Perspective

Peter Clowes June 12, 2019

In line with Trineo’s “high-impact, low-drama” philosophy of work, we seek to always emphasize the pragmatic over the dogmatic. In the developer community at large, opinions around pair-programming tend to skew dogmatic. At Trineo we approach pair-programming first and foremost as a tool. As a tool, it can be used well, poorly, or not at all. Pair programming done poorly can easily lead to developer frustration and burnout, dysfunctional team dynamics, and decreased productivity. However, done properly and in the right circumstances, pair-programming can have a massive, positive impact on a development team.

Why Pair?

There are many benefits to pair programming and most of them are well understood by this audience. Here is a short list of benefits that is by no means exhaustive.

  • Emphasizes the team over the individual
  • Destroys knowledge silos through pair rotation
  • Empowers junior devs and humbles seniors
  • Is more productive, creating better code faster with fewer bugs
  • Is leaner from a process perspective as code review is built in (some teams I have been part of didn’t use branches while pairing)
  • Builds trust and team chemistry, limits defensiveness and promotes constructive criticism as every mistake in the code is “shared”
  • Limits interruptions; people don’t check email, Slack, Facebook while pairing
  • People interrupt people who are pairing far less
  • Stories don’t get orphaned by PTO, sick days etc. as two people always have full context
  • Builds communication skills, helps quieter voices to be heard

How to Pair

In order to capture the benefits of pair-programming while avoiding its potential pitfalls, Trineo has collected a set of guidelines. These are by no means rigid and are definitely “breakable” when the situation warrants it. Here is how we think pairing is done best:

  • Pairing is not watching someone else type. Regardless of the style of pair-programming being used, both parties should be fully engaged and understand what is going on. The short-term slowdown required to make sure everyone is on the same page is made up by efficiency gains over the long-term.

  • Approach pairing like a practice. Just deciding to pair one day is unlikely to go well. You must approach it with intentionality. Pairing is a skill: the more you practice and study it, the better at it you will be.

  • Pairing should not be physically uncomfortable. Ideally there should be two keyboards, two mice, and two monitors side by side either at a large desk or two small desks. Nobody should be leaning over, craning their necks, or sitting uncomfortably close to someone else in order to pair.

  • While pairing, the computer does not “belong” to anyone. Notifications and Slack should be turned off or signed into a joint account (eg. peter+bob on Slack etc). This may include standardization of tooling, editor, keyboard shortcuts, etc. as the productivity of the team is more important than the preferences of the individual.

  • Breaks and interruptions should be shared. If half of a pair is called into a meeting or takes a break, the other half does not leave them behind. Within reason they should work on another task such as administrative work.

  • The pairing dynamic should always be equal if not inverted. If two equally skilled developers are pairing, the driving should be shared 50/50. If a senior and a junior developer are pairing, then at minimum the junior is typing half of the time. However, the relationship can “invert” meaning the junior does most of the typing and the senior serves as the “sage” or “guide”.

  • Pair rotation or cessation should typically only occur either at the end of the day or the end of the story. Git commits should be done as a pair. If the story crosses multiple days, one of the pairs “stays sticky” meaning they do not leave the story until it is done even if other pairs rotate in. All responsibility is shared, even if pairing is stopped halfway through a story.

When to Pair

Just as important as how to pair is when to pair. There are many successful organizations that pair-program full-time and there are arguable many more equally successful organizations who do not pair at all. At Trineo we have found there are certain times when pair-programming is the tool we reach for and other times when we leave it in the proverbial toolbox. Trineo finds pairing most helpful when we are:

  • Leveling up junior engineers by having them learn directly from seniors
  • Acclimating a new teammate to the code base as well as the culture, standard, and preferences of the team
  • Demonstrating and introducing a new pattern to the team
  • Working on a particularly thorny, complex, or poorly understood area of a codebase (it is especially helpful when refactoring old code where context is missing)
  • Working on business critical features where an uncaught edge case could be disastrous for the organization

When Not to Pair

However there are times where we have found pair-programming less helpful:

  • The most important time not to pair is when someone does not want to pair and the situation does not necessitate it. An unenthusiastic pair is a recipe for misery. However, if a developer never wants to pair, it is worth exploring the reason why and whether they had a bad experience.

  • Having the same two people pairing consistently can build camaraderie and communication, but a main benefit of pairing is to experience multiple perspectives and to share lessons learned throughout the team. Two people who always pair can hinder this education.

  • Pair programming on trivial features is a waste of developer time. Using a full pair on a trivial bug or style change is overkill. However, often simple bugs can turn out to be quite complex. When they do, a developer needs the self-discipline to bring in a pair instead of spinning their wheels.

  • On the other end of the spectrum, pairing when neither person knows where to start typically ends in a fight for the keyboard as each person wants to try out ideas and explore. In this situation it is generally best to break apart, research, read documentation, and then come back together to check understanding and decide on architecture.

There is so much more to say about pair programming, and I could go into detail about each of these points. My hope is that this post may serve as a good starting point to a conversation about whether and how to pair at your organization.

Peter Clowes

Peter Clowes