Two people working at one computer, on one task, at the same time. The most-debated practice in software engineering — variously promoted as the way to build the best teams and dismissed as half the productivity at the same cost. Both views miss what pairing actually does.
The honest assessment: pair programming is sometimes valuable, sometimes wasteful, depending on context. The question is not whether to pair always or never, but when. This page is about that.
Working as a pair changes the work in three ways:
What pairing does not do:
Pairing produces real value in specific circumstances:
Problems where the right approach is not obvious. Two people can explore alternatives, catch mistakes earlier, and produce a better answer than one person working alone followed by code review.
Bringing a new team member up to speed on a complex codebase. The new person learns the conventions, tooling, mental model. The experienced person discovers gaps in their own understanding by being asked to explain.
When two engineers from different specialties work together, both learn. A backend engineer pairing on frontend work, or vice versa, gains real exposure faster than reading documentation.
Security-sensitive code, infrastructure changes with high blast radius, payment systems. The "two engineers signed off in real time" creates a record and reduces single-mistake risk.
Pairing is one of the most effective ways to establish shared conventions. New patterns get adopted faster when senior engineers regularly work alongside everyone.
Pairing is wasteful in specific situations:
Trivial bug fixes, simple feature additions, work that does not require deep thought. Two people on this is a literal waste; the work could be split into two parallel pieces.
A senior engineer pairing for hours on something a junior could do alone is bad pacing. The junior should do the work alone; the senior reviews. Pairing here would be expensive mentoring.
The exception: pairing across skill levels for learning purposes is genuinely valuable. The cost is real but the return is in the junior's growth. Frame it as mentoring, not as production work.
Pairing requires real trust and willingness to think out loud. If the team culture punishes mistakes or the engineers are uncomfortable being seen "not knowing," pairing fails. The first investment is cultural; pairing as a forced practice on a team that doesn't trust each other is worse than not pairing.
Multi-hour pairing sessions exhaust both engineers. Productive pairing has built-in breaks; a "we'll pair all day" plan is usually unsustainable.
One person types ("driver"), the other thinks at a higher level ("navigator"). The navigator suggests direction; the driver translates to code. Roles switch periodically (typically every 15–30 minutes).
This is the classical model. It works for most pairing situations.
One person writes a failing test; the other writes the code to make it pass; the first refactors; switch. Forces frequent role exchange and produces test-first code by structure.
The driver does only what the navigator dictates. Forces verbal communication; particularly useful for onboarding (the new person drives, the experienced person navigates, every action goes through verbal description).
Useful in specific contexts; usually too rigid for ongoing work.
Three or more people on one task. The intensity multiplies. Generally only worth it for genuinely difficult or critical work.
Remote pairing is structurally different from in-person:
Remote pairing works but takes more deliberate effort than in-person.
Before pairing, agree on:
Skipping this leads to drift.
Every 50 minutes is reasonable. The 50-10 cadence (50 work, 10 break) is sustainable; ad-hoc unstructured breaks aren't.
If pairing on a problem is not working, separate. Each person tries alone for a while. Reconvene when one or both has progress.
Pairing constantly produces shallower thinking than solo work in some areas. Don't pair on everything.