Pair Programming

Purpose

Pair Programming produces higher-quality code, spreads knowledge, and reduces bus-factor risk by having two people collaborate on every line of code. The navigator catches mistakes in real time, and both developers leave the session with shared context.

At a glance

How to run

1. Pick the task (2 min) — Agree on the work item to tackle.
2. Choose initial roles (1 min) — Driver types, navigator reviews and thinks ahead.
3. Code together (25 min) — Driver writes code. Navigator watches for bugs, suggests design improvements, and keeps the big picture in mind.
4. Switch roles (2 min) — Swap every 25–30 minutes (Pomodoro style) or after completing a logical unit.
5. Repeat (25 min) — Continue the cycle.
6. Debrief (5 min) — What did we learn? Any follow-up tasks?

Materials needed

• One workstation with the codebase
• Two monitors or a large shared screen
• Remote pairing tool (Tuple, VS Code Live Share, or screen share)
• Timer for role switching

Pitfalls & common mistakes

• Navigator disengages — If the navigator is checking email, they are not navigating. Stay focused.
• Driver ignores navigator — The driver must incorporate navigator input; this is not solo coding with an audience.
• Pairing all day every day — Pairing is intense. Alternate with solo work to avoid fatigue.
• Skill imbalance treated as a problem — Pairing a senior with a junior is a feature, not a bug — it accelerates learning.

Inclusion & accessibility

• Use an IDE with adjustable font size and high-contrast themes.
• For remote pairing, ensure low latency and good audio quality.
• Respect different working styles: some people need quiet processing time.

Variations

• Ping-pong pairing — One writes a failing test, the other makes it pass, then writes the next test.
• Strong-style pairing — For an idea to enter the computer, it must go through someone else's hands.
• Promiscuous pairing — Switch pairs every 90 minutes to spread knowledge across the team.

When NOT to use this

• For trivial tasks that one person can do in 5 minutes.
• If both developers are new to the codebase and the domain — pair with someone who knows the code.
• If one person strongly resists — forced pairing is counterproductive.

Source & further reading

• Beck, K. (2000). *Extreme Programming Explained*. Addison-Wesley.
• Williams, L. & Kessler, R. (2002). *Pair Programming Illuminated*. Addison-Wesley.