On Pair Programming

Nina Siessegger · article · 2026-06-01 source ↗ Reader 🖥️

Pair & Mob Programming Psychological Safety Pull Requests & Async Code Review Trunk-Based & Continuous Delivery

Pair programming should be the team's sensible default for production code because the live, four-eyes, two-modes-of-thinking collaboration produces continuous code review, knowledge spread, and team-flow benefits that asynchronous pull-request reviews cannot match — and pull requests are best reserved as the exception for the cases when someone must change production code without a pair.

practical · mixed — Practical: argues for what teams should do (pair by default, treat PRs as exceptions). Mixed form: largely expository (taxonomy of styles, benefits, challenges) but argumentative in part 4 ('To pair or not to pair') and part 5 ('But really, why bother?'), where the authors defend pairing against the natural alternative of asynchronous code review.

Structure

Part	Role
Part 1 — How to pair (styles, time management, rotations, setup, remote)	Definitional / how-to scaffolding; establishes that 'pairing' is a family of practices, not one thing
Part 2 — Benefits (knowledge sharing, reflection, focus, code review on-the-go, two modes, collective ownership, WIP limits, onboarding)	Evidence / value enumeration
Part 3 — Challenges (exhaustion, intensity, meetings, skill mismatch, power dynamics, unknowns, vulnerability, convincing managers)	Steelman / cost accounting
Part 4 — To pair or not to pair? (boring tasks, junior confidence, code review vs. pairing)	Decision rule / argumentative core for the syntopical question
Part 5 — But really, why bother? (diversity, friction, psychological safety)	Reframing / second-order justification

Key terms

Pair programming Pair & Mob Programming
Two people writing code together on one machine, including not just typing but planning, discussing approaches, clarifying ideas, and arriving at solutions jointly
Pair Development Pair & Mob Programming
A mindset (not a technique) that the pair is jointly responsible for the entire lifecycle of a user story — understanding, solutioning, planning, research, documentation — not only the lines of code
Driver / Navigator Pair & Mob Programming
Two complementary cognitive roles in a pair: driver is tactical (line-of-code focus, at the keyboard), navigator is strategic (big-picture, watching for obstacles, parking ideas)
Strong-Style Pairing Pair & Mob Programming
Llewellyn Falco's rule: 'For an idea to go from your head into the computer it MUST go through someone else's hands.' Experienced person navigates, novice drives, with the driver 'comfortable with incomplete understanding' until after the session
Pair Rotations Pair & Mob Programming
Cycling one half of a pair off a story while an 'anchor' continues; the mechanism by which pairing scales beyond local knowledge sharing to collective code ownership
Collective Code Ownership Pair & Mob Programming
An XP property: 'The code base is owned by the entire team and anyone may make changes anywhere'; pairing+rotations is the mechanism that produces it
Code review on-the-go Pull Requests & Async Code Review
Continuous, live, in-the-moment review of code as it is written by the pair, with refactoring folded into the same loop — as distinct from asynchronous after-the-fact PR review
Trunk-based development Trunk-Based & Continuous Delivery
Continuous Integration in its original sense: merge into main daily, branches/forks under a day, fewer than three active branches; cited via 2017 State of DevOps Report
Sensible default
A team-level convention: pair unless there is a specific, discussed reason not to; the inverse of treating pairing as the rare or special practice
Code Review (the PR kind) Pull Requests & Async Code Review
An after-the-fact, asynchronous review of completed work by someone other than the author; characterized by sloppy/superficial dynamics, sunk-cost fallacy, context-switch cost, and bottleneck risk

Propositions

explicitcorroboratedPair programming should be the team's sensible default; PRs and async code reviews should be the exception, not the rule.conf: high
supports ←Why your team doesn't need to use pull requests · p8 — Morris already lists pairing as a review alternative that avoids PR's delay cost; the later, pairing-focused article builds the fuller case for pairing as the default.
extends ←Remote pair programming: Tips, tools, and how to measure · p1 — This 2020 piece's narrow definitional claim (pairing requires synchronous, same-codebase work; async sharing doesn't count) is the tooling-level precursor to the later, stronger normative claim that pairing — not async PR review — should be a team's sensible default.
explicitAsynchronous code review is not an adequate substitute for pair programming, because the dynamics around it (mutual deferral, sunk-cost reluctance, reviewer-as-bottleneck, context switching) systematically produce sloppy or superficial reviews.conf: high
explicitcorroboratedPair programming and trunk-based continuous integration are complementary practices: with trunk-based development, delayed PR reviews are even less effective because the code already merged.conf: high
supports ←Pair Programming Fixed Our Pull Request Bottlenecks · p5 — Concrete case of pairing-plus-trunk-based-integration making delayed PR review not just redundant but actively in the way, matching the claim that pairing and trunk-based CI are complementary and PR review is weaker once code already merges.
extends ←Post-Commit Reviews != Post-Deployment Reviews · p4 — Sridharan's 'developer focus' case for post-commit review and the pairing article's case for continuous-pairing-plus-trunk-based-development both argue that batching or eliminating a discrete pre-merge review gate is what frees developer attention -- this article supplies the velocity-cost mechanism (CI + review turnaround latency) that the pairing article's argument assumes but doesn't quantify.
explicitcorroboratedPairing functions as continuous, live code review ('code review on-the-go'), catching errors and improving design as code is written rather than after.conf: high
supports ←What happens when the coding becomes the least interesting part of the work · p4 — Both describe pairing (human or agent) as live, continuous reasoning-exposure that catches errors and sharpens design as the work happens, not after.
explicitPairing combines two distinct cognitive modes (tactical/driver and strategic/navigator) that one person cannot easily hold simultaneously, and this combination raises code quality in a way solo work plus async review cannot replicate.conf: high
explicitPairing plus pair rotations is the mechanism that produces collective code ownership; PRs are a weaker substitute mechanism.conf: high
explicitPairing should not be done dogmatically or for 8 hours a day; ~6 hours/day with exceptions for boring tasks, solo learning time, and junior-confidence development is the realistic shape of the default.conf: high
explicitWhen a team must exempt work from pairing, they should still monitor pull request lifetimes carefully to preserve continuous integration.conf: high
explicitPairing's value cannot be settled by quantitative productivity studies; it must be tried in your environment because software outcomes (analysis, design, testing, quality) exceed what those studies can measure.conf: high
explicitcorroboratedThe valuable output of pairing is not only the code, but a set of team skills (feedback, vulnerability, communication, psychological safety) that themselves predict team performance.conf: high
supports ←5 Things High-Performing Teams Do Differently · p1 — Both hold that relational/social capacities predict team performance: the pairing piece argues team skills (feedback, vulnerability, communication, psychological safety) predict performance; HBR supplies survey evidence that connection-building behaviors distinguish high-performing teams.
explicitFriction in collaboration is a feature, not a bug; the discomfort of pairing is correlated with better team performance, not worse.conf: high
implicitProduction code, by default, should not be written alone.conf: high
implicitCode quality is primarily produced at the moment of writing, not at the moment of review.conf: high
implicitThe cost of pairing (two people on one task) is offset by quality, flow, knowledge-spread, and onboarding benefits the team would otherwise pay for separately (and worse).conf: high
implicitSpeed of code generation is not the binding constraint on team output; shared understanding and integrated change are.conf: medium
explicitTrust and psychological safety inside the pair are prerequisites for the pair's quality output.conf: high
explicitRote/boilerplate work may be a smell of bad design, not a justification for solo coding.conf: high

Arguments

Async code review (PRs) is not a sufficient replacement for pair programming. strength: high

Explicit premises:

Coder and reviewer mutually defer responsibility (coder leaves things for review; reviewer trusts the coder), producing superficial reviews.
Sunk-cost fallacy makes reviewers reluctant to require rework on completed code.
Frequent reviews disrupt team flow via context switching.
Reviewers become bottlenecks for integration/deployment, adding time pressure that degrades review quality.
Under trunk-based development, code merges before the review can meaningfully intervene.

Implicit premises:

The quality function of review is best performed at the moment of writing, not after.
The social and emotional dynamics of asynchronous review are not fixable by tooling or process discipline alone.
There is no third practice (e.g. AI-assisted review) that closes the gap left by async PR review.

Inferences:

Teams that adopt both trunk-based development AND PR-as-default are operating two inconsistent regimes: the CI ideal is fast merge, but PR review wants a gate before merge.
Teams that already pair effectively gain little from also adding a PR step on top of pair-produced code.

Pair programming should be the sensible default rather than the exception. strength: high

Explicit premises:

Pairing produces continuous code review, two cognitive modes combined, knowledge spread, collective ownership, focus, and WIP control simultaneously.
The natural alternative (solo + async review) systematically underperforms on review quality and ownership.
The costs of pairing (exhaustion, intensity, power dynamics) are manageable with known practices (breaks, rotations, feedback culture).

Implicit premises:

Defaults shape behavior more strongly than recommendations; making pairing default and PRs exceptional is a different team than the inverse, even with identical individual decisions.
Team-level outcomes (flow, ownership, onboarding) matter more than individual-developer line throughput.

Inferences:

A 'pair by default, PR for exceptions' policy is the operationally correct middle path — neither dogmatic pairing nor PR-as-default.
AI-accelerated solo coding does not change this calculus unless it can replace the live-collaboration benefits (review on-the-go, two modes, knowledge spread, ownership) — code-generation speed alone does not.

Friction in pairing is not a reason to abandon it; it is a signal that the team is doing the work that produces high performance. strength: medium

Explicit premises:

Diverse teams feel less comfortable and perform better (HBR).
The fluency heuristic biases us toward what feels easy, but easy is bad for performance.
Teams that work through pairing friction develop feedback, communication, vulnerability, and psychological-safety skills.

Implicit premises:

Skills built through pairing transfer to other team activities (planning, decision-making, conflict resolution).
A team's long-run capability is built by deliberately accepting short-run friction.

Inferences:

Practices chosen for their comfort (solo + PR) may be self-undermining at the team-capability level even if they look efficient at the individual level.

Pairing should be the default but not absolute (pair by default, with discussed exceptions). strength: high

Explicit premises:

Some boring/boilerplate tasks may not require pairing.
Junior developers need some unobserved problem-solving time to build confidence.
People need solo time to learn, read, dig in.
8-hour pairing is unsustainable; 6 hours is the realistic ceiling.

Implicit premises:

Exceptions, when explicitly discussed, are themselves a form of team alignment — not a failure of the default.
The category of legitimate exception is finite and recognizable; teams can tell the difference between a real exception and a relapse to solo-by-default.

Inferences:

PRs have a residual but bounded role: covering the exception cases, with strict short-lifetime discipline.
AI coding assistants might count as a 'partner' for some boring/boilerplate tasks where the live human-pair benefits are weakest — but the author does not address this directly.

Narratives

The ENIAC women, including Jean Bartik, paired from the very beginning of programming — before the word 'program' was even in use, with no role models or books telling them how.
→ Pairing is the natural state of programming, not a later innovation imposed on a solo-default discipline. Frames the article so that 'solo + review' is the thing requiring justification, not pairing.
Kent Beck's XP epigraph: 'Write all production programs with two people sitting at one machine.'
→ Establishes the strong-form claim the article will partially soften (into 'sensible default') without abandoning.
The teams that 'rely too much on each other' in code review — coder defers little improvements thinking the reviewer will catch them, while the reviewer trusts the coder and skims.
→ Implicit support for the proposition that async review is dynamics-bound to be superficial, not because reviewers are lazy but because the structure invites the failure.
Pia Nilsson's team at Spotify worked through pairing friction with feedback culture, non-violent communication, psychological safety, humility, and purpose.
→ Existence proof that pairing friction is workable, not a structural blocker; supports the 'why bother' rebuttal in part 5.
The 2017 State of DevOps Report finding that trunk-based development with daily merges, sub-day branches, and <3 active branches correlates with higher software delivery performance.
→ Empirical anchor for the trunk-based-and-pairing-go-together argument; quietly implies that long-lived PRs are a delivery-performance liability.
The strong-style pairing rule ('for an idea to go from your head into the computer it MUST go through someone else's hands').
→ Knowledge transfer happens through the act of writing together, not through after-the-fact reading — implicit support for live-pair-over-PR for onboarding and skill spread.

Questions addressed

✅ Can pair programming and async code review (PRs) coexist, and how?
Yes — pair by default, use PRs for the exception cases (someone must change production code without a pair), and monitor PR lifetime so CI is preserved.
✅ Is pair programming worth the apparent doubling of cost?
Quantitative ROI cannot be settled cleanly; the question must be tried locally. The benefits (quality, flow, ownership, onboarding, team skills) are claimed to outweigh the headcount math.
✅ What practical shape does 'pair by default' take?
Styles (driver/navigator, ping-pong, strong-style, pair development), pomodoro time-boxing, ~6h max/day, regular rotations with an anchor, explicit setup, remote tooling.
✅ How should a team handle pairing's interpersonal challenges (vulnerability, power dynamics, skill mismatch)?
Feedback culture, anti-bias training, naming hierarchies, regular 1:1s, role-modeling vulnerability from people with authority.
⭕ Are pull requests strictly necessary in a pair-by-default + trunk-based team?
Not directly answered. The article carves out a 'PRs for the exception' role but never asks whether even that residual role could be eliminated (e.g. by a pair-rotation discipline that covers the exception case too).
⭕ How does AI-accelerated code generation change the pair-vs-PR calculus?
Not addressed (article predates the current AI wave). The author's framework — live two-modes thinking, code review on-the-go, knowledge spread — would have to be re-evaluated against an AI 'partner' that supplies tactical generation but not navigation, ownership, or team skills.

Gaps

incompleteThe 'exception' category for PRs is asserted but not characterized. What counts as 'someone has to change production code without pairing'? Hotfixes? Solo time-zone hours on a distributed team? Documentation-only changes? Without criteria, 'PR for exceptions' can drift back into 'PR by default with a rationale attached.'
Read next: Look for engineering blogs on trunk-based-development discipline (e.g. Hammant, DORA reports) and post-PR workflows; also Beck on what XP teams actually do for solo edge cases.
incompleteNo engagement with AI-accelerated code generation. The author's load-bearing claim — that the navigator's strategic mode is what one person cannot supply alone — is exactly the claim AI assistants put in play. An AI can act as a tactical driver to a human navigator (Strong-Style inversion), or as a tireless reviewer. The article cannot help with whether this changes the default.
Read next: Read Anthropic/Cursor/Aider research on AI-pair patterns; Beck's recent writing on AI and XP practices; thoughtful critiques of solo-with-AI productivity claims.
incompleteThe argument that async review is structurally sloppy (deferral, sunk-cost, bottlenecks) does not address modern PR cultures that explicitly try to fix these (pre-PR design docs, RFC-then-PR splits, small-PR norms, mob/ensemble review, async + sync hybrid). The critique may apply unevenly across PR cultures.
Read next: Material on healthy PR cultures (Gergely Orosz, Will Larson on tech excellence, GitLab handbook); also ensemble/mob programming literature as a third option between pair and PR.
closed byMob programming: From avant-garde experimentation to established practice — This paper is exactly the 'ensemble/mob programming literature as a third option between pair and PR' that the gap calls for: it documents, via systematic review plus interviews, how a mobbing team's continuous whole-team presence replaces discrete async PR review entirely, with its own tradeoffs (ambiguous productivity, uneven participation) rather than inheriting PR review's specific pathologies.
incompletePair rotations are treated as the mechanism for collective ownership, but the article admits opinions diverge on frequency and concedes costs (context switch, lost tacit knowledge). It does not give a decision procedure, so 'pair + rotate' as a substitute for PR-mediated cross-team review remains under-specified.
Read next: Mob programming literature (Llewellyn Falco, Woody Zuill); engineering org studies on knowledge silo formation.
incompleteAsynchronous/distributed-team pairing is treated as a tooling problem (screen share, low-latency). The harder organizational question — can pair-by-default work across time zones at all, or does that environment structurally demand PR-by-default — is not engaged.
Read next: GitLab/Automattic/Basecamp on fully-async engineering; recent material on remote-first XP.
incompleteThe economics rebuttal ('we are wary of attempts to scientifically prove pairing effectiveness') is rhetorically convenient. It immunizes the practice from quantitative challenge without offering an alternative evaluation criterion beyond 'try it.' For the syntopical question, this matters: managers comparing pair-by-default vs. PR-by-default + AI need some way to choose.
Read next: DORA / SPACE / DX framework material on developer productivity measurement; serious cost-of-quality literature.

On Pair Programming

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents