Pair Programming — Cheat Sheet

Tags: pair-programming, agile, extreme-programming, collaboration, code-review, tdd

Level: intermediate

TL;DR: Two engineers collaborate on one problem, alternating driver and navigator roles to improve code quality, share context, and eliminate async PR bottlenecks.

Key concepts

Driver writes code, manages typing, and focuses on tactical syntax and local implementation details.

Navigator reviews code in real time, thinks strategically, anticipates edge cases, and checks architectural alignment.

Regular role switching every 20-30 minutes prevents cognitive fatigue and maintains active participation.

Ping-Pong pairing couples test-driven development: one person writes a failing test, the other implements code to pass it.

Strong-Style pairing requires that every idea in code must go from the navigator's head through the driver's hands.

Continuous code review happens synchronously, reducing PR turnaround time and batch size.

Knowledge sharing mitigates single points of failure and spreads codebase context across the engineering team.

Pairing requires deliberate communication, verbalizing thoughts, and agreeing on problem scope before writing implementation code.

Typical questions and ready answers

Q: How do you handle disagreements on technical design while pairing?R: I pause typing, clarify trade-offs, and align on project constraints. If opinions diverge without clear data, we implement the simplest approach first or run a time-boxed spike.

Q: Doesn't pair programming cut engineering velocity in half?R: No, studies show code quality rises while defect rates drop significantly. Real-time review and immediate design validation save hours of async rework and debugging downstream.

Q: When is pair programming most effective versus solo work?R: It excels in complex domain logic, critical refactors, and onboarding. For routine configuration, trivial CRUD, or exploratory research spikes, solo work with async review is often better.

Pitfalls and common mistakes

Navigator disengaging and checking email or phone instead of actively reviewing and strategizing.

Driver monologue or steamrolling without verbalizing thought process or allowing navigator input.

Fatigue from marathon sessions without scheduled breaks or role swaps every 20 to 30 minutes.

Applying pair programming indiscriminately to repetitive, low-risk, or trivial boilerplates.

Power imbalance when pairing a senior with a junior, turning the session into dictation or passive observation.

Snippets and commands

# Git commit attribution for paired commits
git commit -m "Refactor order processing pipeline

Co-authored-by: Alex Smith <alex@example.com>"

TypeScript

// Ping-pong pairing flow:
// Step 1: Partner A writes failing test
describe("calculateDiscount", () => {
  it("applies 10% discount for premium tier", () => {
    expect(calculateDiscount(100, "premium")).toBe(90);
  });
});

// Step 2: Partner B implements minimum passing code and refactors
export function calculateDiscount(amount: number, tier: string): number {
  return tier === "premium" ? amount * 0.9 : amount;
}
// Step 3: Partner B writes the next failing test, hands keyboard to Partner A

To review

[x] Driver and Navigator core division of labor

[x] Git co-author commit trailer syntax

[ ] Ping-Pong TDD rhythm execution in live technical interviews

[ ] Shared terminal multiplexing and remote pair tooling shortcuts

References

Extreme Programming Explained (Kent Beck)

On Pair Programming (Martin Fowler)

Pair Programming Illuminated (Laurie Williams, Robert Kessler)