Why Remote Pairing Matters
Pair programming isn't just about two people writing code together. It's about knowledge transfer, real-time code review, mentorship, and maintaining shared understanding of the codebase. When we went remote, losing effective pairing meant losing all of those benefits.
The first attempts were painful: laggy screen shares, talking over each other, one person passively watching while the other typed. It took months to find practices that made remote pairing genuinely effective.
The Tooling Stack That Worked
VS Code Live Share: This was the game-changer. Both engineers have full editor capabilities — navigation, editing, terminal access — in the same workspace. No more "scroll up a bit... no, too far... there." Both people can move independently while working on the same code.
High-quality audio is non-negotiable: Invest in good microphones. AirPods are fine for calls; they're not good enough for 4-hour pairing sessions. We bought proper USB microphones for engineers who pair frequently. The reduction in "sorry, can you repeat that?" improved flow dramatically.
Video optional, but available: We found continuous video during pairing was distracting. We'd start with video for the initial discussion, then turn it off during deep coding, and turn it back on for design discussions. Presence indicators in Slack showed availability without the overhead of video.
Shared timer for driver/navigator rotation: The Pomodoro technique adapted for pairing. 25 minutes driving, then swap. A shared timer keeps the rotation honest and prevents one person dominating the keyboard.
The Practices That Made It Work
Start with a clear goal: "Let's pair on the checkout flow" is too vague. "Let's implement the discount code validation and write the tests for it" gives both people a shared target. Write the goal in Slack before starting so you can refer back to it.
Think out loud — more than feels natural: In person, you can see someone's face scrunch when they're confused. Remotely, you can't. Narrate your thinking: "I'm wondering whether this should be a separate service or part of the order module... I'm leaning toward separate because..." This gives your pair the opportunity to engage with your reasoning.
Take breaks: Pairing is cognitively intense. In an office, you'd naturally break for coffee or get interrupted. Remotely, you can pair for 3 hours straight without realising. Enforce breaks. 50 minutes on, 10 minutes off.
The navigator isn't passive: The navigator's job isn't to watch the driver type. It's to think ahead — what's the next test? What edge case are we missing? Does this approach fit the broader architecture? A passive navigator is a wasted engineer.
Anti-Patterns We Learned to Avoid
The expert/novice trap: When a senior and junior engineer pair, it's tempting for the senior to just drive while the junior watches. Resist this. The junior should drive more, with the senior navigating and explaining. That's how learning happens.
Pairing on everything: Not all work benefits from pairing. Exploratory spikes, simple bug fixes, and well-understood tasks are often faster solo. Pair on complex problems, unfamiliar code, and work that benefits from multiple perspectives.
Marathon sessions: A full day of pairing is exhausting and counterproductive. 2-4 hours of focused pairing produces better output than 8 hours of tired pairing. Respect cognitive limits.
When It Clicked
After about two months of iteration, remote pairing became genuinely effective — arguably better than our in-office pairing had been. The explicit practices and quality tooling eliminated the ambiguity that had made in-office pairing inconsistent.
The discipline remote work forced on us — clear goals, explicit communication, proper tooling — made pairing more intentional. That intentionality turned out to be the key all along.