Pair Programming

Pair programming is a software development technique where two programmers work together at the same computer to solve a coding problem — the driver writes the code, while the navigator reviews and guides in real time, together designing, writing, testing, and debugging.

Benefits

• Greater collaboration and communication — leads to better shared understanding of the code and catches errors earlier than either person working alone would.
• Knowledge sharing — helps less experienced team members learn from more experienced colleagues in the moment, rather than only through delayed, asynchronous code review.
• Higher code quality — two sets of eyes reviewing in real time tends to produce better-designed, more maintainable code, and can reduce time spent on later bug-fixing and testing.

Implementation approaches

• Co-located — one computer, two keyboards and monitors, with programmers sitting side by side and switching roles regularly (the regular role-switching matters — a pair where one person always drives loses much of the benefit).
• Remote — programmers work together from different locations using video conferencing and remote desktop/screen-sharing tools, achieving much of the same real-time collaboration benefit without co-location.

When pairing adds the most value

Particularly valuable for complex or unfamiliar problems, onboarding a new team member, or tackling a piece of code where a mistake would be costly — the real-time review catches issues an asynchronous after-the-fact code review would only catch later, at higher cost to fix.

Relationship to test-driven development

Pair programming and Test Driven Development are commonly practiced together, particularly in Extreme Programming (XP): the navigator can focus on the next test to write while the driver implements, keeping the red/green/refactor cycle disciplined with a second person actively checking each step rather than one person potentially skipping a step under time pressure.

Common pitfalls

• One person always driving, the other passively watching — loses the collaborative benefit; regular, deliberate role-switching is what keeps both people actively engaged.
• Pairing on every task regardless of actual need — pairing has real overhead; not every task benefits enough to justify two people's time, and forcing it universally can slow a team down without proportionate benefit.
• Poor remote setup — inadequate screen-sharing, audio, or latency in a remote pairing session undermines the real-time collaboration the technique depends on.
• Mismatched pairing without adjusting approach — pairing a very senior and very junior developer works differently (more mentorship- oriented) than pairing two similarly-experienced developers; treating every pairing the same misses this.

Learn more

• Test Driven Development for the closely related practice pair programming often accompanies.
• Agile Coaching for helping a team decide when and how to adopt pairing.