Pair Programming

Pair programming puts two developers on one task at one screen. One person, the driver, has the keyboard and writes the code. The other, the navigator, reads continuously, thinks ahead about design and edge cases, and catches problems while they are still cheap. The roles swap often — every few minutes to every half hour — so both people stay engaged and both understand everything that was written.

The obvious objection is cost: two salaries producing one stream of code. The honest answer is that pairing is not free and is not for everything. It pays for itself where defects are expensive, where design decisions are hard to reverse, or where knowledge is dangerously concentrated in one head. It is a poor fit for mechanical work either person could do half-asleep.

Roles Done Well

A good driver narrates: says what they are about to do before doing it, so the navigator reviews intent, not just keystrokes. A good navigator stays at a higher altitude than the current line — tracking the failing test, the edge case the code does not handle yet, the name that will confuse the next reader — and writes small notes instead of interrupting mid-thought. A navigator who only watches silently, or who dictates every keystroke, has left the role.

Rotation is what keeps pairing from decaying into one person working while another watches. Swap on a timer, on each passing test, or at natural boundaries. In ping-pong pairing the rotation is built in: one person writes a failing test, the other writes the code that passes it and then writes the next failing test.

<?php

declare(strict_types=1);

function pingPongStep(int $step): string
{
    $phase = $step % 2 === 0 ? 'writes a failing test' : 'makes it pass, writes the next failing test';
    $person = $step % 2 === 0 ? 'A' : 'B';

    return 'Developer ' . $person . ' ' . $phase;
}

foreach ([0, 1, 2, 3] as $step) {
    echo pingPongStep($step) . PHP_EOL;
}

// Prints:
// Developer A writes a failing test
// Developer B makes it pass, writes the next failing test
// Developer A writes a failing test
// Developer B makes it pass, writes the next failing test

When Pairing Pays

Pair on the work where a second brain changes the outcome: gnarly bugs, security-sensitive code, unfamiliar parts of the codebase, and design decisions that will be expensive to revisit. Pair when onboarding — a new developer paired with someone who knows the system learns the codebase, the conventions, and the reasons behind them faster than any document can teach. Do not force pairing on trivial changes, and do not let a pairing schedule override sustainable pace: pairing well is intense, and a full day of it without breaks degrades both people.

Remote pairing works with any screen-sharing setup, and IDE-level tools give both people a live cursor. The mechanics matter less than the discipline: one task, spoken intent, frequent rotation.

Failure Modes

The common failures are human, not technical. A dominant driver who never yields the keyboard turns the session into a demonstration. A distracted navigator turns it into solo work with an audience. Skipping breaks turns it into exhaustion. Pairing a strong ego with a quiet junior without ground rules teaches the junior to stay quiet. Name the roles, rotate on a rule rather than on mood, and end sessions with a two-minute note of what was decided — that note is what the rest of the team reviews and what future maintainers find.

Pairing complements review rather than replacing it wholesale: a pair-written change was continuously reviewed while being written, which many teams accept in place of a separate review pass for that change, but the Code Review As A Skill lesson still applies to everything written solo.

What To Check

Before moving on, make sure you can:

• describe the driver and navigator roles and what each contributes
• explain why and how pairs rotate, including ping-pong pairing
• name the kinds of work where pairing pays and where it does not
• list the common failure modes: keyboard hogging, silent navigation, no breaks, no ground rules
• explain how pairing relates to code review

What You Should Be Able To Do

After this lesson, you should be able to run a productive pairing session: pick a task worth pairing on, keep both roles active, rotate on a rule, and leave behind a short record of the decisions the pair made.