Pair Programming

Writing alone and being checked later carries a cost of undoing. Hearing two days afterward that the structure was wrong means two days of work rewritten. The person raising it also finds it hard to say "start over differently" about finished code, so the choice to let it pass repeats. The later a direction gets corrected, the more expensive correcting it becomes. A comment on finished code competes with the sunk cost of having finished it.

Knowledge pooling in one person comes along with it. At Pagedeck the only person who understood the payment handling code was Theo. Payments failed during a week he was on vacation; three people opened the files, none of them knew where to look, and Theo ended up fixing it remotely after a phone call. Nothing about the code was unusually hard; the knowledge simply had one holder.

Over the same period, a newly joined engineer received the same review comment six times in two weeks. Each comment was correct and each arrived late. Pair programming moves that moment to while the code is being written. Setting the direction there rather than two days later is the whole of it. The pair, not each person in it, becomes the unit of work.

Two people take one task and one screen, with roles agreed first. Six steps.

1. Split the roles. One holds the keyboard and writes; the other writes nothing and watches direction, next steps, and missing cases. Two people looking at the same level produces argument, so dividing the altitude is the point of the split. Neither role is the senior one.
2. Pick one task, ideally something whose result can be checked within 30 minutes. Take a half-day chunk whole and attention breaks mid-way, leaving one person spectating. Small tasks also make the swap land at natural boundaries.
3. Swap roles every 25 minutes. Run a timer and hand over mechanically. Without the swap the faster typist keeps typing and the other becomes an audience, which is a state not worth two people's time.
4. The watching role doesn't call out syntax or typos — tooling catches those. It asks what happens when a value is missing, whether this name still reads in six months, whether this structure can absorb the next request. Those are the questions a review raises days later, asked while the code can still change cheaply.
5. Break every two hours. Writing while talking runs at a higher intensity than writing alone and doesn't last. Sustainable pace, holding an intensity you can keep, matters more here than almost anywhere. Two hours of pairing is not two hours of solo work in intensity.
6. Leave one line about what was learned. A judgment that stayed between two people makes a third person hit the same wall next week. One line on the pull request is usually enough.

Working apart, screen sharing alone isn't enough. Step 3 only works with a tool that lets both sides take the keyboard in turn.

Who gets paired with whom, and when they pair, sets the return.

Pairings split three ways. An experienced engineer with a new joiner makes transfer the purpose: writing gets slower and repeated review comments stop. Two experienced engineers suit work where structure has to be decided, because two opposing opinions get resolved on the spot instead of in a thread. Two new joiners is the combination to avoid — the time spent not knowing something together gets long. Rotating who pairs with whom spreads knowledge further than fixing the pairs does.

There are four moments to pair: entering an unfamiliar area, deciding a structure, chasing the cause of an incident, and touching code only one person knows. Conversely, don't pair on repetitive work, on simple changes where the decision is already made, or on reading documentation. Pairing there spends one person's time for nothing. Declining a session is as much part of the practice as holding one.

It isn't an all-day practice. Two to four hours a day with the rest worked separately is what survives in practice. It moves in step with collective ownership, the principle that anyone can change any code, and pairing is the mechanism that makes knowledge flow. It also connects to simple design, designing only what's needed now, because the structure stays within what two people can explain on the spot.

"Let's do this part together. I don't want to leave it as code only I understand."

Framed on distributing knowledge rather than on splitting work.

"That's 25 minutes. Passing the keyboard."

The handover is set by the clock rather than by anyone's judgment.

"Leave the typos and just check what happens when the value is missing."

Resetting the altitude the watching role should be at.

Theo and the new engineer paired every afternoon for two weeks. Repeated review comments stopped inside the first week. They also went into the payment handling code together during that stretch, which made it code two people understood.

In the first week they sat together from morning to evening and both were spent by Thursday. Writing while talking turned out far heavier than writing alone. The second week they cut it to two afternoon hours, and those two weeks produced better results than the first arrangement. What created the value was where they paired, not how long. Treating it as a budget to spend rather than a default to apply is what kept it running.

The most common reading is that two people on one thing halves productivity, which is how it computes if you divide output by headcount. But writing alone has time attached behind it: waiting for a review, rewriting after comments, and someone else later reading code only one person knew. The comparison has to be against that total. That said, pairing on everything genuinely is waste. Choosing where to use it is half the practice. Measuring it per pair-hour rather than per finished feature is where the arithmetic goes wrong.

Reading it as a replacement for review is the other one, since someone already watched the code being written. That's partly true and two things drop out. Two people who wrote together come to share the same assumptions, so when an assumption itself is wrong neither notices. And the reasoning behind a decision doesn't get recorded anywhere. That's why many teams still run a light check over paired work. A short written summary covers most of what the review would have caught.