Pair Programming can be productive, useful, and churn out better code than a lone developer. Some organizations, such as Pivotal, do everything in pairs. There are also strong opinions in the other direction. Over the next month, I’ll be publishing a series of posts on the subject because it can help developers write better code when used correctly.

Before we get into the finer points of when and how it should be used, I’ll take a stab at redefining Pair Programming with a new analogy.

The definition of Pair Programming is as follows: Two developers working together at one workstation to achieve a specific goal. Traditionally, the person who is actively typing is called the Driver, and the person who is observing and reviewing is called the Navigator.

An alternative Analogy

The Driver/Navigator analogy, taken from the world of rallying, implies that the driver is taking cues and reacting to what the navigator is saying. This isn’t true when the Driver is more experienced with the code in question. For that reason, I prefer calling the two roles the Lead and the Wingman (yes, I’m a big Top Gun fan).

Most definitions of pair programming will mention that the person not coding has some cue cards to direct and structure the work. In most cases, it’s sufficient to simply have a few notes jotted down either on screen or on paper with the details of the task being worked on.

And just like with fighter pilots, the Lead and Wingman roles should be switched often to ensure that both developers have equal time flying towards the solution.

Pairing situations should arise organically and not be forced upon the team or developers. While there are some teams that live and breath pairing, it’s much more common to see pairing only in specific scenarios. I’ll detail those scenarios in my next post in the Pair Programming Series.

Disagreements over Pair Programming’s usefulness

Pairing enthusiasts regularly say that the code written while pairing is of higher quality than that by a lone developer. It may certainly help to improve the code but it’s hard to generalize and say that all pairing code is superior. For example, a team that has an effective code review process in place will also deliver high quality code. Is one approach or the other better? They are different but equally as good.

Another common argument against pairing is that it reduces a person’s ability to concentrate and focus on a problem. This can certainly be true. Everyone has different routines, peak hours, idiosyncrasies, and ways of working that make it awkward to ask another developer to spend the day working with you.

So how useful is pairing? It depends on who you ask. In the next article of the series, we’ll look at the reasons why it should produce better code. But one thing is already clear: pairing is intense, draining and not for everyone.