Pair Programming

Pair programming is two people, one problem, one keyboard (or one shared editor). It looks inefficient from the outside. Two salaries on one ticket! The evidence and my experience say otherwise.

What you get

• Fewer defects. The classic study (Cockburn and Williams, 2000) found pairs took roughly 15% more development time and produced roughly 15% fewer defects. Defects are expensive, so that’s a good trade.
• No knowledge silos. Two people understand every change, so the team doesn’t depend on one person.
• Faster onboarding. Nothing transfers context like building something together.
• Better communication. Pairing forces you to explain your thinking, which often exposes the flaw in it.
• Review built in. A pair can replace a separate code review, if the team agrees it can and both are comfortable with the change.

Styles

Style	How it works	Best for
Ping-pong	One writes a failing test, the other makes it pass, then they swap	TDD; keeping both people engaged
Driver/navigator	The driver types; the navigator thinks strategically, reviews and spots problems; swap often	Complex design work, expert–novice pairs
Strong-style	“For an idea to go from your head into the computer, it must go through someone else’s hands.” The navigator holds the ideas, the driver types	Teaching. The expert has to explain
Unstructured	Ad hoc collaboration	Peers of similar skill. It’s the most common style and the easiest to do badly

Mob or ensemble programming scales the idea to the whole team, rotating the driver every few minutes. It’s great for gnarly bugs and for agreeing conventions.

Anti-patterns

The keyboard hog. The silent navigator. Pairing all day without breaks (it’s exhausting; swap on a timer and stop for real breaks). Pairing on trivial work that doesn’t need two brains.

In practice

Early in my career I introduced regular pairing and structured pull-request reviews to a team, alongside weekly developer sessions to share what we’d learnt. Pairing was the most effective piece by far: it spread knowledge of a large codebase quicker than any document. As a lead, I pair on the first few tickets with anyone new. It’s the fastest way to hand over context, and the fastest way to learn what’s confusing about our codebase. Related: Knowledge Transfer Before Moving On.