To practice pair programming remotely, share both the screen and the terminal, agree a single task before you start, and switch driver and navigator every 25 minutes. Most remote pairing fails for one of three reasons: the task is vague, one person cannot run the code, or nobody switches roles.
1. Choose a task that fits the session
Good pairing tasks are concrete and bounded: implement one endpoint, fix one flaky test, refactor one module, write the first integration test. Write the task and the definition of done at the top of a shared note. If it does not fit in ninety minutes, split it.
2. Set up so both people can run the code
Voice plus a screen share is watching, not pairing. The navigator must be able to run tests, read logs and try things. Use a room that shares the terminal as well as the screen (DEVAE live rooms do this; VS Code Live Share and tmux over SSH are alternatives). Check that both can run the test suite before starting the timer.
3. Driver and navigator, with a timer
The driver types; the navigator thinks ahead, watches for mistakes and keeps the task in view. Swap every 25 minutes — a timer removes the awkwardness of asking. New pairs should over-communicate: the driver narrates what they are typing, the navigator says what they are checking.
4. Commit at every swap
A commit at each switch means a dropped call costs at most 25 minutes, and it gives the session a natural rhythm. Commit messages can be rough ("wip: retry loop"); squash later.
5. Two-minute retro
Before you close the room: what was useful, what was annoying, what to try next time. Common fixes are "share the terminal earlier", "smaller task", "less narration once we know each other".
Finding someone to pair with
- Post your task and time in a stack community; "pairing on X at 7pm UTC, join if you want" is an easy invitation.
- Open a public room; people who are curious will drop in.
- Study groups and bootcamp cohorts are natural pairs.
- The DEVAE find-teammates page lists people looking for regular sessions.
Etiquette that keeps partners
- Be on time; a remote session with a ten-minute late start loses a quarter of its value.
- Say when you are lost. The navigator's job is to notice, but tell them anyway.
- No multitasking. If you need to check a message, say so and pause.
How often
Once a week for a month is enough to feel the benefit: fewer bugs, faster onboarding to unfamiliar code, and a partner who will review your work without being asked.
A worked example
Two developers, one in Karachi and one in Berlin, share a three-hour evening overlap. They pick "add retry with backoff to the HTTP client" as the task and write the definition of done: three retries, exponential delay, tests for success on the second attempt and failure after the third. They open a room, confirm both can run the suite, and set a 25-minute timer. The Berlin developer drives first and writes the failing tests; at the swap the Karachi developer implements the loop; at the next swap they refactor the delay calculation and commit. Seventy minutes, three commits, a two-minute retro: next time, share the terminal before the timer starts.
Questions people ask
**What if our skill levels are very different?** Let the less experienced person drive more. Driving forces engagement; navigating while confused becomes passive watching.
**Is it worth pairing with someone I have never met?** Yes, for a bounded session. Public rooms on a specific task are low-risk: if it does not click, you have lost an hour and learned something about how you work.
**How do I pair if I only have a laptop with a small screen?** Share a single editor window and the terminal in a split, and keep the voice call on a phone. Two screens help but are not required.
