Skip to main content
Culture

[FAKE] Pair programming in remote-first teams

1 min read

The remote pairing problem

Pair programming in an office is natural. You roll your chair over, point at the screen, and think out loud together. Remote pairing over video call is exhausting — screen sharing lag, audio delays, and the cognitive overhead of narrating every keystroke.

Most remote teams try to replicate the in-office experience over Zoom and burn out within weeks. We took a different approach.

Async-first pairing

The handoff model

Instead of simultaneous pairing, we use a handoff model. Engineer A works on a problem for 25-50 minutes, then records a 3-minute Loom explaining their approach, what they tried, and where they're stuck. Engineer B picks it up, continues the work, and records their own handoff.

This preserves the collaborative benefit of pairing — two minds on one problem — without requiring synchronized schedules or sustained video calls.

Live pairing for specific moments

We reserve synchronous pairing for three scenarios: complex debugging (when you need real-time hypothesis testing), architecture decisions (when you need to sketch and discuss trade-offs), and onboarding (when a new team member needs guided context).

For everything else, the async handoff model works better.

Tools that make it work

  • Loom: Short video walkthroughs (3-5 minutes max)
  • GitHub PR comments: Async code review with inline suggestions
  • VS Code Live Share: For the occasional synchronous session
  • Slack threads: Quick questions that don't warrant a video

The results

Our async pairing approach reduced meeting time by 40% while maintaining the knowledge-sharing benefits of traditional pairing. Code review quality improved because engineers had time to think before responding, rather than reacting in real-time.

The key insight: pairing is about collaboration, not co-location. When you separate the two, you can optimize for both.

Tags

Pair Programming Remote Work Team Ops