A Practical Guide to Remote Pair Programming (and the Tooling That Makes It Work)

Pair programming has a reputation for being exhausting, and remote pairing has a reputation for being exhausting and awkward. Most of that reputation comes from doing it badly: unstructured sessions that run for hours, one person silently watching another type, and tooling that makes switching who is typing a two-minute ordeal. Done with a little structure, remote pairing is one of the fastest ways to spread knowledge across a team and to get unstuck on hard problems.

What pairing is actually for

Before choosing tools it is worth being clear about why you are pairing, because the answer changes how you should do it.

• Onboarding. A new engineer learns the codebase, conventions, and tribal knowledge far faster by watching and doing than by reading documentation.
• Hard problems. Two people reason about a tricky concurrency bug or a design decision better than one, mostly because explaining your thinking out loud exposes gaps in it.
• Risky changes. A migration or a change to payment code benefits from a second pair of eyes in real time rather than in a code review after the fact.
• Spreading ownership. If only one person understands a module, pairing on it is cheaper than the eventual bus-factor incident.

Routine feature work usually does not need pairing. Forcing it there is where the "exhausting" reputation comes from.

Driver and navigator, remotely

The classic roles still apply. The driver types. The navigator thinks one step ahead: what the next test should be, whether the current approach will handle the edge case, what to name the function. The navigator does not dictate keystrokes.

Remotely, the most important adjustment is to swap roles more often than you think you need to. In person, the navigator stays engaged because they are physically present; on a video call it is very easy to drift into checking Slack. Swapping every fifteen to twenty minutes keeps both people active. Use a timer; it feels artificial for the first session and natural after that.

Swapping only works if swapping is cheap. If changing drivers means stopping a screen share, starting another, and re-opening files, you will not do it. This is the single biggest argument for a tool where both people can type at any time.

Session length and rhythm

Ninety minutes is a reasonable upper bound for a single remote pairing block. Beyond that, quality drops noticeably. A good pattern for a half-day of pairing is:

• Five minutes agreeing on the goal for the block and writing it down at the top of the shared workspace.
• Two or three driver/navigator cycles.
• A ten-minute break away from the screen, cameras off.
• Repeat, then a short written note of what was done and what is next, so the session can be picked up later or handed to someone else.

Choosing your tooling

There are broadly two options, and the right one depends on what you are pairing on.

IDE-integrated pairing (VS Code Live Share, JetBrains Code With Me)

These share a full development session: the project, the terminal, the debugger, language-server features. They are the right choice when you are working inside a large existing codebase and need to run tests, step through code, and navigate across many files.

Their cost is setup. Both people need the same IDE and the extension installed, one of them needs the project checked out and building, and session invitations and permissions take a minute or two to sort out. For a planned two-hour session that is fine. For "can you look at this for five minutes" it is a barrier high enough that people skip pairing altogether.

Browser-based shared editors (Get My Code and similar)

A shared editor in the browser trades depth for speed. There is no project, no terminal, and no debugger. In exchange, starting a session is: open a URL, send it, start typing. Nobody installs anything, and it works identically from a work laptop, a personal machine, or a phone.

This is the right tool for a large share of real-world pairing moments:

• Working through an algorithm or data structure before touching the codebase.
• Sketching an API contract or a SQL query together.
• Quick debugging help where the problem fits in one function.
• Pairing with someone outside your organisation who cannot or should not have access to your repository.
• Any situation where the other person is not a developer and would never install an IDE plugin.

Many teams use both: a browser editor for the first fifteen minutes of thinking, then move into the IDE once the approach is clear and it is time to write real code with real tests.

Pairing across time zones

Fully synchronous pairing needs overlap, and distributed teams often have only two or three hours of it. Make those hours count by pairing on the things that genuinely need two people in real time, and use a persistent shared workspace for the asynchronous part.

A pattern that works: at the end of the overlap, the pair leaves the workspace in a known state with a short comment block at the top ("Done: X, Y. Next: Z. Open question: should we handle nulls here?"). The engineer in the later time zone continues in the same workspace, updates the comment, and the next overlap starts with both people already on the same page. Because the content is at a stable URL and does not require either person to be online at the same time, the hand-off is nearly free.

Etiquette that matters more remotely

• Narrate when driving. In person your partner can see where you are looking. Remotely they cannot, so say what you are doing: "I'm going to extract this into a helper first."
• Ask before taking over. In a shared editor both people can type, which is convenient and also an easy way to be rude. "Mind if I fix that import?" costs two seconds.
• Keep cameras optional. Audio plus a shared editor is enough. Mandatory video for ninety minutes is a big part of why people find remote pairing draining.
• Write things down. Decisions made out loud in a call evaporate. Put them in the workspace as comments while they are fresh.

Summary

Remote pairing works when sessions are time-boxed, roles swap frequently, and switching the driver is instant. Use IDE-integrated tools for deep work in a real codebase; use a browser-based shared editor for the frequent, short, low-ceremony moments where the alternative is not pairing at all. Pick the one that removes friction for the situation in front of you, and keep a written trail in the workspace so the session outlives the call.