Pair programming reliably draws the same handful of objections. Most of them sound obvious and turn out to be wrong, or at least far weaker than they first appear. Let me take them head-on, then get practical.

Myth: "Two people on one job is bad economics"#

This is the objection everyone leads with. If one developer costs X, two on the same task cost 2X for the same output — obviously wasteful.

Except the output is not the same. Studies of pairing going back to early work at Hill Air Force Base and the University of Utah found that the quality and speed gains largely offset the apparent doubling of cost. Pairs produce fewer defects, and defects are the expensive part — every bug that does not reach production is rework you do not pay for later, when it is far more costly to find and fix. Once you account for reduced defects and rework, the naive "2X for 1X" math falls apart.

Myth: "I'll never get to work alone"#

The fear here is losing all autonomy and quiet focus. But look honestly at how knowledge work already happens: most of it is collaborative. Reviews, design discussions, debugging sessions, planning — very few of us truly work solo for long stretches as it is. Pairing formalizes and front-loads collaboration that was already happening in slower, more fragmented ways. And no reasonable team pairs on literally everything; there is still room to go heads-down when the work calls for it.

Myth: "Pairing only works between people of similar skill"#

The assumption is that a senior paired with a junior is just the senior doing the work while the junior watches. In practice, mismatched levels still benefit both people. The junior gets knowledge transfer at a pace no documentation matches. The senior gets fresh questions — the newcomer asks "why does it work this way?" and exposes assumptions the expert stopped seeing years ago. The right mental model is complementary strengths, not identical ones. A pair who know different things cover more ground together than two clones would.

High-stakes work already pairs by default#

It is worth noting how many high-stakes professions pair without anyone calling it inefficient. Surgeons operate in teams. Airline pilots fly with a first officer. Important sales meetings rarely go in one-on-one when the deal is large. The pattern is consistent: when the cost of a mistake is high, a second set of eyes is not a luxury, it is standard practice. Software that matters deserves the same treatment.

Practical guidance#

A few things I have learned about making pairing actually work:

• Use driver and navigator roles. One person has hands on the keyboard handling the immediate tactics; the other watches the bigger picture, catches mistakes, and thinks a step ahead. Swap regularly so both stay engaged.
• Let the team decide when and how to pair. Pairing imposed from above breeds resentment. Pairing the team chooses to use, on the work where it pays off, sticks.
• Skip it on trivial maintenance. It is usually not worth pairing on rote, low-risk changes. Save it for the work where design quality and knowledge sharing matter.

The deeper payoff: dissolving single points of human failure#

The biggest reason I advocate pairing is not any single task — it is what it does to a team over time. Pairing spreads knowledge as a side effect of doing the work, which dissolves the "indispensable person" risk. A single point of human failure — the one engineer who alone understands a critical system — is a liability, not an asset, however reassuring it feels in the moment. When that person is out sick, on vacation, or gone, the team should not grind to a halt.

Pairing connects directly to collective ownership and to growing T-shaped engineers — people with deep skill in one area and working competence across many. Rotate pairs and that breadth develops naturally. If you want to see where this fits in a wider practice, it is one of the core Extreme Programming practices, and it reinforces nearly all the others.