Why I Still Say “No” to Pair Programming… and a Possible Alternative

Pair Programming, when two software developers work side-by-side on a coding task, is said to reduce the impact of the inevitable mistakes that occur during coding, by detecting them much sooner.

It is claimed to be at least as effective as two people working separately, when you take that earlier detection of mistakes and the avoidance of the much greater cost of fixing them later into account.

It is also said to be a great way to spread knowledge and experience within a team of developers.

Despite agreeing with much of the above, I’ll say it early: I’m still not a fan of pair programming. In-fact, I refuse to do it now, partly out of strong preference and partly out of necessity (I value my sanity).

I’m hoping this article explains why I still refuse to do it, and suggests an alternative that might be as effective in some scenarios and for certain developers like me: “Periodic Pairing”

Despite what certain studies say, it’s my experience that Pair Programming isn’t a one-size-fits-all solution to the problem of efficiency. Lots of measures, Pair Programming among them, might lead to higher productivity in development teams. But if they anger, annoy, depress, stress or otherwise deplete the engagement of developers who don’t handle them well… surely that’s a net negative, not a win?

Measuring efficiency at a project level is useless if you’ve lost some of your developers — or disengaged them — along the way.

I should probably also say that I’m a huge fan of spreading knowledge, of learning, of code reviews and of sitting with one or more people talking through ideas and code… and frequently being corrected in what I / they have coded… but not actually as I am writing the code.

It’s my experience that three particular factors aren’t handled well by pair programming: The prevalence of introverts (roughly 33% of the workforce), the need for “deep work” (without which, certain classes of project would never be delivered), and encouraging diversity of approach / ideas.

Let’s look at those in a little more depth…

INTROVERTS: WE’RE EVERYWHERE!

Laugh if you will, call it too “touchy-feely” an issue if you must, but introverts are everywhere.

If research is to be believed, we make up approximately 33% of the population, and… we make really great software engineers and leaders.

(If you’re unfamiliar with this topic, I highly recommend Susan Cain’s book “Quiet: The Power of Introverts in a World That Can’t Stop Talking”)

Introverts and extroverts often bring different kinds of strengths to a project, so fully-utilising a developer population — which is what we obviously want to do if we’re looking at performance and efficiency — needs us to play to both kinds of personality.

Nature builds diversity into populations precisely because it is a strength. We should utilise it.

We handle human interaction in different ways: Introverts thrive in quieter more thoughtful environments punctuated with interaction. Extroverts thrive on human interaction. No one is 100% one or the other; even true introverts like periods of interaction, and folks in one group can act (for short periods) like their counterparts, though it will drain them much more quickly and they can’t do it for too long.

Working non-stop with another developer simply doesn’t work for introverts. Too much “face time” drains us quicker than extroverts. I’d wager you don’t get 8 hours out of us; more like 2 and then we’re like zombies. I certainly couldn’t code alongside someone else for more than an hour or so per day.

Pair Programming, as for a lot of things in our society and culture, plays to the needs of extroverts, because they happen to be the vocal majority, but it can be downright destructive for introverts.

Inconvenient though you may consider all this, if we are truly concerned with developer efficiency and the efficient sharing of knowledge and experience, we should not ignore the harsh realities of Pair Programming for different personality types.

DEEP WORK: WHY IT MATTERS

Much of the work we do as developers is “deep work” (see Cal Newport’s book on the topic). You need solitude, for a continuous period of time, to go deep enough to have certain insights; to even see and work with certain classes of solution.

You don’t go deep with another person sat right next to you.

To use the diving analogy: You are forever surfacing to interact, then trying to go deep again… you waste much of your time surfacing and returning.

Some might say this doesn’t count as a “context switch”, as you are both working on the same task. But deep thought on a task is a very different activity from describing where you’re at in your thinking to another person. One interrupts the other. They aren’t equivalent.

The end result, when paired continually, is that you just don’t go as deep, don’t have certain insights, and don’t consider certain classes of solution: Often some very simple, elegant and efficient solutions.

Deep work isn’t just overly-complex or redundant work: For many classes of project it is essential.

Simplicity is hard. The “obvious” can sometimes require significant deep thought before it becomes so.

For certain kinds of programming tasks, Pair Programming may work well. Building a UI within a framework often means you’re following certain patterns and filling in the use case specifics. But coming up with a whole new algorithm to tackle a problem… that needs deeper, more continuous thought.

If we’re getting Agile about this… some say the deeper work should have been exposed at the story level, and perhaps identified during grooming. I’d say that there is much deep work left on the table long after the externally-visible product-focussed aspects of a story are ready to work on… and there should be, if developers are truly here to add value in translating stories into working tech. If all developers are doing is “coding up” pre-thought-out complexity, then that’s a different dumbed-down kind of development from the one I’m familiar with.

But maybe I’m too old-school in this regard, or I work on a different kind of project.

Personally, I certainly wouldn’t have written a JavaScript UI framework via pair programming. I don’t think the ideas would have gone deep enough to go beyond a somewhat circular discussion. It took a certain amount of solo discovery to figure out the landscape and then some very deep thought to build it, even the detailed aspects of it, over a number of weeks. I know I wouldn’t have got that done with another person sat there. I would literally have had to send them away for my own (and perhaps their own) sanity!

DIVERSITY OF APPROACH

Finally, it’s been my experience that there is a tendency with Pair Programming only to go for approaches that both parties understand up-front. There is a lower likelihood of “ok, show me”, of briefly trying something only one (the active coder, most likely) understands. But often, it takes the other (observer) in the pair to see a portion of a suggested approach in code, before they see the benefit. It often isn’t apparent from a verbal discussion.

So I’d assert that discussing your approach entirely as-you-go can have downsides. It’s the two-person equivalent of design by committee, with the same resulting loss of diversity in approach, if there isn’t an agreement that disagreement should be entertained for brief periods while one person demonstrates a possible approach more fully.

ALTERNATIVES TO PAIR PROGRAMMING

I certainly agree that early and regular discussions about what you’re doing as you code can be helpful in reducing mistakes and finding them early. It is also a great way to spread knowledge and experience.

I think Pair Programming may have been a good first proposal for these issues, and an option we should still consider, but it has so many downsides for certain tasks and personality types that I think we need some alternatives… some more tools in our toolbox.

More traditional code reviews after a task is already completed (whether coded as a pair or alone) are still required, but they can be very late at detecting certain classes of programming mistake. The reviewer also has to immerse themselves in the task, and a lack of time or focus to truly do that can lead them to miss things.

I’d say that having a coding partner for a task could still be a good idea, but perhaps the contract could be different: Maybe they sit with you for a walk-through of the code at certain key points in the task, which you both agree at the start. For example, when you’ve written the tests that define the use case (if you’re doing good TDD), then when you’ve suggested a skeletal outline for solving the main problem, then as you finish each piece of it, and then at the end. Additionally, if you get stuck and value the interaction… bring them over then.

Crucially, you shouldn’t feel blocked by the partner’s unavailability as you reach a checkpoint. You should continue, but ensure you sync up within the next few hours… after which you should probably say you’re blocked.

This “Periodic Pairing” might get the best out of pairing and solitude, support deep work where it is needed, and play to a range of personalities, working styles and contributions.

Is it time we finally stopped seeing Pair Programming as a one-size-fits-all solution to developer productivity and knowledge sharing, and added some alternatives to our toolbox?