Remote pairing has a bad reputation earned mostly by bad sessions: three hours on a call, one person driving the whole time, the other watching a laggy screen share and drifting into Slack. Done well it’s the fastest way to transfer context that exists — better than documentation, better than review. The difference comes down to a few mechanics that in-person pairing gets for free and remote pairing has to arrange deliberately.

Decide Why You’re Pairing

Sessions go wrong when the two people want different things from it. Name the mode in the first sentence.

• Knowledge transfer — one person knows the system, the other doesn’t. The person who doesn’t know should be driving, most of the time.
• Hard problem — both stuck, two heads genuinely better. Swap freely, think out loud.
• Risky change — a migration, a payment path, a deletion. Four eyes on it as it happens rather than after.
• Onboarding — the new person drives, the experienced one narrates the map.

The one that isn’t a mode: “let’s pair” as a substitute for either person having thought about the problem first. Fifteen minutes of solo reading beforehand makes an hour of pairing worth double.

Swap the Keyboard on a Timer

The single biggest failure of remote pairing is one person driving for the whole session, which turns the other into an audience.

Twenty-five minutes, then swap. Use an actual timer — good intentions don’t survive an interesting problem.

Ping-pong pairing enforces it structurally and works especially well with TDD:

1. A writes a failing test
2. B makes it pass
3. B writes the next failing test
4. A makes it pass

Nobody can coast, and the handoffs are natural rather than interruptions.

For a genuinely lopsided knowledge gap, invert the default: the person who knows less drives the whole time. It feels slower and it isn’t — the expert talking while the novice types produces retention that watching never does. If the expert drives, the novice learns that the expert is fast.

Get the Tooling Out of the Way

Screen sharing is the lowest common denominator and the worst option. The passenger can’t fix a typo, can’t look at a different file, and is reading a compressed video of text.

Better, roughly in order:

Collaborative editing — VS Code Live Share, JetBrains Code With Me, or a shared Zed session. Both people have a cursor, both can edit, and the passenger can navigate independently to check something without hijacking the view. Live Share also shares a terminal and forwards localhost, so the passenger can hit the running app.

tmux over SSH — two people attached to the same session on one machine. Nearly zero latency because you’re shipping keystrokes rather than pixels, and it works on a bad connection where video does not. Best when one person’s environment is the one that matters.

# Host
tmux new -s pair

# Guest, over SSH
tmux attach -t pair

# Guest with an independent view of the same windows
tmux new-session -t pair -s guest-view

Screen share — the fallback. If you must, share a single window rather than the desktop, bump your font size well past comfortable, and use a high-contrast theme. Whatever looks readable to you is too small for someone on a compressed stream.

Whatever you pick, set it up before the session starts. Ten minutes of “can you see my screen now” is ten minutes of the session gone and both people already slightly annoyed.

Keep the Audio On

Video is optional and often worth dropping — it costs bandwidth that the shared editor needs, and after the first few minutes nobody is looking at the faces anyway.

Audio is not optional, and it should be continuous. Pairing works because of the running commentary: “I’m going to check whether that association is loaded”, “wait, go back”. Muting between sentences kills that, and so does push-to-talk.

Two things that matter more than they sound:

• Wear headphones. Speaker echo makes both people unconsciously wait for silence before speaking, which suppresses exactly the overlapping commentary you want.
• Say what you’re doing while you do it. Silent driving is the remote equivalent of turning your back. Thirty seconds of quiet typing leaves the passenger with no idea whether to interrupt.

Rules for the Passenger

The navigator role is harder remotely and it’s where most sessions leak value.

Do:

• Think one step ahead — what’s the next test, what did we forget, does this handle nil
• Look things up while the driver types, and say what you find
• Notice the drift: “we came here to fix the timeout, we’re now three files deep in the serializer”
• Ask when you don’t follow. Immediately. It’s the whole point.

Don’t:

• Dictate keystrokes. “Line 47, change map to filter_map” is the driver as a typist.
• Correct typos in real time. They’ll see it. Let them.
• Go quiet for ten minutes. If you need to think, say “give me a minute, I’m reading.”

The useful level of instruction is intent, not mechanics: “I think we should extract that into a method” — then let the driver decide where and what to call it.

Timebox It

Pairing is intense in a way solo work isn’t. Two hours is a long session; four is a bad idea and produces worse code in the second half than either person would have written alone.

A shape that works:

• 50 minutes on, 10 off. The break is not optional, and it’s when the good ideas arrive.
• Two hours maximum in one block.
• Stop at a green test. Ending mid-refactor means whoever picks it up — including future you — starts by reconstructing what was in your head.

Say the end time at the start. Open-ended sessions drift, and the person who wanted to stop an hour ago won’t say so.

Pro-Tip: Set up git co-author attribution before the session, not after. Co-authored-by: Name <email> on the last line of the commit message gives both people credit in GitHub’s UI and in git log, and it takes one line — but nobody remembers at commit time, so build it into a script: git pair alice sets a template, and every commit that session carries both names. This matters more than it sounds for two reasons. The obvious one is fairness — the person who wasn’t driving contributed equally and shouldn’t be invisible in the history. The less obvious one is archaeology: eight months later git blame points at one name, that person half-remembers the session, and the other person — who suggested the approach and remembers exactly why — never gets asked. Co-authorship makes the second person findable.

Async Pairing

Timezone overlap is sometimes an hour, sometimes zero. Two things partly substitute.

Recorded walkthroughs. A ten-minute screen recording explaining a subsystem, posted in the PR, is worth more than a written doc and takes a tenth of the effort. The other person watches at their convenience and asks questions in the thread.

Commit-by-commit handoff. Push a branch with small, well-described commits and a note about where you got to and what you’re unsure about. The other person continues and does the same. It’s slower than real pairing but it transfers reasoning in a way a finished PR doesn’t.

Neither replaces a live session for a genuinely hard problem. Both are much better than nothing when the calendars don’t overlap.

Conclusion

Name the mode before you start, swap the keyboard every twenty-five minutes with an actual timer, and use a collaborative editor or shared tmux rather than a screen share so both people can act. Keep continuous audio, wear headphones, and narrate what you’re doing. If the knowledge gap is wide, put the less experienced person on the keyboard for the whole session. Timebox to two hours, break every fifty minutes, and stop on green. Set up co-authored commits in advance so the history records both people. Remote pairing done this way transfers more context per hour than any other practice available.

FAQs

Q1: Is pairing worth the cost of two people on one task?
For hard problems, risky changes, and onboarding, consistently yes — the code needs less review, has fewer defects, and two people can now maintain it. For routine work, it’s usually not.

Q2: What if the other person types much faster or slower?
Speed is irrelevant; the thinking is the work. If the gap is distracting, the faster typist should drive less, not more.

Q3: How do I pair when we share no working hours?
You mostly don’t — use recorded walkthroughs and commit-by-commit handoff instead, and save the one overlapping hour a week for the genuinely hard conversation.

Q4: Should juniors pair with juniors?
Yes, regularly. Two people at a similar level exploring together learn differently — and often better — than either being led by an expert. Just make sure someone reviews the result.

Q5: How do I end a session that’s going badly?
Say it plainly: “I think we’re both tired and going in circles — let’s stop here and pick it up tomorrow.” Nobody has ever regretted ending an unproductive session early.