Remote pair programming: a practical guide

Pair programming in a room works partly because of things nobody planned: you can see where the other person is looking, you can point at the screen, and you can tell from their posture that they have stopped following. Remove all three and pairing does not become slightly worse — it fails in specific, predictable ways.

Remote pairing is worth doing anyway. It just needs technique that the in-person version never required.

The three failure modes

The passenger. One person drives for forty minutes while the other silently stops paying attention. In a room this is visible within a minute. Over a video call, a quiet participant looks identical to an engaged one, and by the time it is discovered the session has been a solo effort with an audience.

The dictation loop. The navigator spots something and has to describe it in words: “no, the line above — no, the other one — the closing bracket on line 42”. What would be a fingertip on a monitor becomes fifteen seconds of coordinates. It happens constantly and it is exhausting.

The frozen driver. Typing while several people watch is stressful, and stress makes people slower and more error-prone, which makes them more self-conscious. Some engineers who are perfectly fluent alone become halting under observation.

Everything below is aimed at one of those three.

Fix the mechanics first

Both people must be able to type. This is the single highest-leverage change, and it is why a shared editor beats a screen share. A screen share makes one person a broadcaster and the other a spectator, structurally — the passenger problem is built into the tool. In a shared document the navigator can fix a typo, drop in a URL, sketch an alternative below the current code, or leave a comment with a question, without asking permission or interrupting.

Both people need to see each other’s cursor. Presence is the remote substitute for pointing, and it is a better substitute than it sounds: watching where someone’s cursor rests tells you what they are reading, which restores a channel that a screen share deletes entirely.

Voice, always. Video, optional. Audio latency is the thing that kills conversation — anything much over 150ms makes people talk over each other and then both stop. Video costs bandwidth that audio needs and contributes far less; many pairs are better off with cameras off.

Nobody should be installing anything at the start. If setup takes ten minutes, pairing sessions quietly stop happening. Being able to send a URL and have both people editing five seconds later is what makes it a habit rather than an event.

Pick a style, and say which one

Driver–navigator

The classic. One person types, the other thinks ahead — considering edge cases, watching for mistakes, keeping the goal in view.

The rule that makes it work remotely: swap every fifteen minutes, on a timer. Not “when it feels natural”, because it never feels natural — the driver is mid-thought and the navigator is comfortable. Fifteen minutes is short enough that the navigator cannot drift off, since they know they are about to take over.

Best for: unfamiliar territory, where two people thinking about the same problem at different altitudes genuinely helps.

Ping-pong

Tied to tests. A writes a failing test; B makes it pass and writes the next failing test; A makes that pass. And so on.

The structure enforces the swapping, which removes the discipline problem entirely, and it produces tests as a side effect rather than as a chore afterwards. The handoff points are unambiguous, which matters remotely where “your turn” otherwise needs negotiating.

Best for: well-understood problems with clear inputs and outputs.

Strong-style

The rule: for an idea to get from your head into the computer, it must go through someone else’s hands. The person with the idea navigates and is not allowed to type; the other person types and is not allowed to implement their own ideas.

It feels artificial for about twenty minutes and is then extremely effective, particularly with an experience gap. It makes the expert articulate everything instead of silently doing it, and it keeps the newcomer’s hands on the keyboard so they are learning by doing rather than watching.

Best for: onboarding, and knowledge transfer generally.

Running the session

Agree the goal in one sentence before starting. “Get the import endpoint returning validated data.” Pairing without a stated objective drifts, and drift is much harder to notice remotely than in a room.

Ninety minutes is the ceiling. Remote pairing is more tiring than in-person pairing — the concentration required to stay synchronised over audio is real. Two focused ninety-minute sessions beat one four-hour marathon by a wide margin, and the second half of a long session is usually wasted.

Break every 45 minutes, on a timer. Five minutes, cameras and mics off. Nobody takes a break voluntarily, because it feels like stopping when the other person is willing to continue, so it has to be scheduled.

Narrate before you act, not after. “I’m going to pull this into a function” takes two seconds and lets the other person object before the change exists. Silence followed by a large edit appearing forces them to reverse-engineer your intent from the diff.

Say when you are lost, immediately. The cost of admitting it grows every minute you wait, and the value of the session collapses the moment one person stops following. Making this normal — by doing it yourself, early, when you are the more experienced one — is most of what creates the safety for the other person to do it.

Use the document for more than code. A scratch area at the bottom for open questions, alternatives, and things to come back to keeps them out of the conversation, where they would derail it, and out of memory, where they would be lost.

When not to pair

Pairing is not a superior default mode. It is a tool with a cost — two people’s time — and it is the wrong choice more often than its advocates admit.

Skip it for: mechanical work where one person will simply be watching a rename happen; exploratory research where thinking needs to be slow and undirected; anything requiring long stretches of reading; and any pairing of people who genuinely dislike working this way, since the productivity loss from resentment exceeds any collaboration benefit.

Pair for: unfamiliar code, tricky bugs, decisions with consequences, onboarding, and anything where two people’s knowledge is genuinely additive.

The related question — whether this change wants a pairing session or a conversation over the diff afterwards — is worth asking explicitly, and synchronous review covers the middle ground between pairing on everything and reviewing everything asynchronously.