Pair Programming in Remote Settings

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Pair programming has been a subject of discussion in software engineering for over two decades. It was popularized by Kent Beck (Beck & Andres, 2004) as a core practice of eXtreme Programming (XP). The concept is straightforward: two developers working together at one workstation, with collaboration being the fundamental principle that drives code quality and knowledge sharing.

Before the COVID-19 pandemic, pair programming was predominantly practiced on-site, with developers sharing physical keyboards, screens, and desks. The pandemic forced a rapid shift to remote work, fundamentally changing how pair programming is conducted. New tools, methodologies, and approaches emerged to accommodate distributed collaboration (Barros et al., 2021).

This post examines what academic literature reveals about remote pair programming effectiveness, explores practical tools and techniques for successful remote pairing, and shares insights from real-world application. The goal is to provide evidence-based guidance for teams transitioning to or improving their remote pair programming practices.

Understanding Pair Programming Fundamentals

Before examining remote practices specifically, it is important to establish what makes pair programming effective. The practice involves two roles that developers alternate between: the driver, who writes the code, and the navigator, who reviews each line as it’s written, thinks strategically about the direction, and spots potential issues (Williams et al., 2000).

Research demonstrates that pair programming yields measurable benefits. A meta-analysis by Hannay et al. (Hannay et al., 2009) examined 18 controlled experiments and found that pair programming produces code with 15% fewer defects on average, though at the cost of approximately 15% more development time. However, when considering the entire software lifecycle including testing, debugging, and maintenance, the net effect often favors pair programming due to reduced defect remediation costs.

A practical example from my professional experience illustrates this well when it comes the time to “hand-over” code to another team or developer, the overhead of having to load everything from the start is reduced to a minimum, since both developers have been involved in the process from the start, and the knowledge transfer is done in real-time. Comparing it with solo programming, where the hand-over is usually done through documentation or code comments, the time spent on understanding the code is higher.

Cockburn and Williams (Cockburn & Williams, 2001) conducted industry studies showing that while pair programming uses 15% more person-hours during initial development, it results in code with 15% fewer defects that pass through to testing and production. More importantly, they found that pairs typically complete tasks 40-50% faster than individuals working alone on the same task sequentially. This seemingly paradoxical finding occurs because pairs encounter fewer blockages, make better design decisions upfront, and produce code requiring less rework.

The Shift to Remote Pair Programming

The transition to remote work created both challenges and opportunities for pair programming. Barros et al. (Barros et al., 2021) conducted a study during the COVID-19 pandemic, surveying 149 software practitioners about their remote pair programming experiences. Their findings revealed three distinct collaboration patterns that emerged:

1. Synchronous remote pairing: Both developers work together in real-time using screen sharing and video conferencing
2. Asynchronous collaboration: Developers contribute at different times, reviewing and building on each other’s work
3. Hybrid approaches: Teams mix synchronous pairing sessions with asynchronous code reviews

The study found that 67% of practitioners reported maintaining or improving their pair programming practices during the pandemic, contradicting assumptions that remote work would necessarily diminish collaborative coding. However, success required deliberate effort: teams that succeeded invested time in establishing clear communication protocols, selecting appropriate tools, and adapting their pairing sessions to the remote context.

One critical finding was that remote pairing fatigue became a real concern. Developers reported that continuous video calls and screen sharing consumed more cognitive energy than in-person pairing, leading to recommendations for shorter pairing sessions (45-60 minutes) followed by breaks, compared to the longer sessions (2-3 hours) common in co-located environments.

Tools and Techniques for Effective Remote Pairing

Hughes and Parkes (Hughes & Parkes, 2020) identified several categories of tools that support remote pair programming, each addressing different aspects of the collaborative process:

Screen Sharing and Co-editing Tools

Traditional screen sharing via Zoom, Microsoft Teams, or Google Meet represents the most accessible entry point. However, these tools have limitations: only one person controls the keyboard, switching control requires manual intervention, and latency can disrupt the flow of work.

More sophisticated solutions provide true collaborative editing:

• VS Code Live Share: Enables real-time collaborative editing where both developers can type simultaneously, see each other’s cursors, and share terminal sessions and debugging contexts
• Tuple: Purpose-built for remote pair programming with low-latency screen sharing, remote control handoff, and drawing tools for discussing code
• tmux with tmate: Terminal multiplexing that allows multiple users to share the same terminal session, particularly valuable for developers working primarily with command-line tools

Communication Infrastructure

Video conferencing remains essential for maintaining the social connection and non-verbal communication that makes pair programming effective. However, the specific setup matters: developers should position their video feed to simulate sitting side-by-side rather than facing each other, reducing the psychological distance.

Audio quality proves more critical than video quality. Clear audio enables rapid back-and-forth discussion without the frustration of dropped words or misunderstandings. Many experienced remote pairs use dedicated microphones rather than relying on laptop microphones.

Establishing Effective Remote Pairing Practices

Based on both research evidence and practical experience, several practices emerge as particularly important for remote pairing success:

1. Explicit role switching: In co-located pairing, physically handing over the keyboard naturally signals role changes. Remote settings require explicit verbal agreements about when to switch driver and navigator roles. Successful teams establish time-based switching (every 25-30 minutes) or task-based switching (after completing each test or function).

2. Pomodoro-adapted sessions: The traditional Pomodoro Technique (25 minutes of focused work, 5-minute break) maps well to remote pairing but with modifications. Many teams extend the work period to 45-50 minutes to account for the overhead of context switching in remote tools, followed by 10-15 minute breaks to combat video call fatigue.

3. Clear audio protocols: Background noise disrupts pair programming more severely in remote settings. Teams should establish norms: use push-to-talk if in noisy environments, mute when not speaking, and use headphones to prevent audio feedback.

4. Document decisions asynchronously: Remote pairing benefits from supplementing synchronous sessions with asynchronous documentation. After each pairing session, capture key architectural decisions, trade-offs discussed, and areas requiring future attention in shared documents or wiki pages.

Benefits and Challenges: What the Research Shows

Lemos et al. (Lemos et al., 2012) conducted empirical assessments comparing solo programming, pair programming, and test-first programming (TDD with pairing) across multiple development tasks. Their findings revealed that pair programming excelled particularly in tasks requiring auxiliary function development—the supporting code that enables core features. Pairs made fewer design mistakes and required less debugging time, though at the cost of higher initial development time.

For remote contexts specifically, the benefits include:

Knowledge sharing: Remote pairing proved particularly effective for distributed teams where knowledge might otherwise become siloed. The practice forces documentation of decisions and rationale that might remain implicit in co-located environments (Barros et al., 2021).

Reduced distractions: Paradoxically, some developers report that remote pairing reduces interruptions compared to open-plan offices. Once in a pairing session with video on, other team members are less likely to interrupt than they would be walking up to a co-located pair.

Geographic flexibility: Remote pairing enables organizations to pair developers across time zones, though this requires careful scheduling. Teams report success with overlapping 4-6 hour windows for synchronous pairing, supplemented by asynchronous code reviews.

However, significant challenges persist:

Technical barriers: Network latency, unstable connections, and tool unfamiliarity create friction. Teams report that technical issues consumed 15-20% of their initial pairing time until they established stable tooling configurations.

Relationship building: Salleh et al. (Salleh et al., 2011) emphasized that pair programming effectiveness depends heavily on interpersonal dynamics. Remote settings make it harder to establish rapport, particularly for new pairs. Teams address this through dedicated social time, virtual coffee chats, and intentional ice-breaking exercises before pairing sessions.

Fatigue management: The cognitive load of sustained video calls combined with focused programming creates exhaustion faster than in-person pairing. Teams that ignore this reality experience declining code quality and developer satisfaction over time.

Practical Recommendations from the Field

Drawing on research evidence and practical experience, consider these recommendations for implementing or improving remote pair programming:

Start with willing participants: Research consistently shows that forcing developers into pair programming creates resentment and poor outcomes. Begin with developers interested in trying remote pairing, document what works, and let success stories drive adoption.

Invest in proper tooling: While basic screen sharing suffices for occasional pairing, teams practicing regular remote pairing should invest in dedicated tools. The productivity gains from seamless control handoff and reduced latency justify the cost.

Establish clear schedules: Remote pairing requires more explicit scheduling than co-located pairing. Teams succeed when they establish regular pairing slots (e.g., “Tuesday and Thursday mornings”) rather than trying to arrange sessions ad-hoc.

Measure and adapt: Track metrics that matter: code review time, defect rates, developer satisfaction, and knowledge distribution across the team. Use this data to refine your approach rather than defending dogma about how pairing “should” work.

Recognize pairing isn’t always appropriate: Not every task benefits from pairing. Research suggests pairing excels for complex problem-solving, knowledge transfer, and code reviews, but provides less value for routine tasks or well-understood implementations. Give developers autonomy to choose when pairing adds value.

Address power dynamics: Remote settings can amplify power imbalances between senior and junior developers or between dominant and reserved personalities. Establish explicit norms about turn-taking, questioning assumptions, and creating psychological safety for disagreement.

Conclusion

Remote pair programming represents an evolution of an established practice rather than a fundamentally new approach. Research evidence demonstrates that distributed teams can maintain the quality improvements, knowledge sharing, and collaborative benefits of co-located pair programming, provided they adapt their practices to the remote context.

Success requires three elements: appropriate tooling that minimizes technical friction, explicit communication protocols that replace implicit co-located cues, and intentional energy management to prevent the fatigue inherent in sustained video collaboration. Teams that invest in these areas report pair programming outcomes comparable to or exceeding their co-located experiences.

The pandemic-driven shift to remote work created an unintended natural experiment in distributed collaboration. While challenging, this transition has revealed that pair programming’s core value transcends physical proximity. The teams that will thrive are those that deliberately design their remote pairing practices based on evidence rather than assuming co-located practices will transfer directly to remote contexts.

For organizations considering or improving their remote pair programming practices, start small, measure outcomes, and iterate based on developer feedback and code quality metrics. The investment in establishing effective remote pairing practices pays dividends in code quality, knowledge distribution, and team resilience that extend far beyond the immediate code being written.

References

1. Beck, K., & Andres, C. (2004). Extreme Programming Explained: Embrace Change (2nd ed.). Addison-Wesley Professional.
2. Barros, G., Pinto, G., Soares, L. R., Dias, L. F., Meirelles, P., & Santos, I. S. (2021). From Collaboration to Solitude and Back: Remote Pair Programming During COVID-19. Agile Processes in Software Engineering and Extreme Programming, 3–18. https://doi.org/10.1007/978-3-030-78098-2_1
3. Williams, L., Kessler, R. R., Cunningham, W., & Jeffries, R. (2000). Strengthening the Case for Pair Programming. IEEE Software, 17(4), 19–25. https://doi.org/10.1109/52.854064
4. Hannay, J. E., Dybå, T., Arisholm, E., & Sjøberg, D. I. K. (2009). The Effectiveness of Pair Programming: A Meta-analysis. Information and Software Technology, 51(7), 1110–1122. https://doi.org/10.1016/j.infsof.2009.02.001
5. Cockburn, A., & Williams, L. (2001). The Costs and Benefits of Pair Programming. In G. Succi & M. Marchesi (Eds.), Extreme Programming Examined (pp. 223–243). Addison-Wesley.
6. Hughes, J., & Parkes, S. (2020). Remote Pair Programming. Communications of the ACM, 63(12), 83–89. https://doi.org/10.1145/3416969
7. Lemos, O. A. L., Ferrari, F. C., Silveira, F. F., & Garcia, A. (2012). Development of Auxiliary Functions: Should You Be Agile? An Empirical Assessment of Pair Programming and Test-First Programming. Proceedings of the 34th International Conference on Software Engineering, 529–539. https://doi.org/10.1109/ICSE.2012.6227165
8. Salleh, N., Mendes, E., & Grundy, J. C. (2011). Empirical Studies of Pair Programming for CS/SE Teaching in Higher Education: A Systematic Literature Review. IEEE Transactions on Software Engineering, 37(4), 509–525. https://doi.org/10.1109/TSE.2010.59

Changelog

• Dec 29, 2025 - Published.
• May 07, 2022 - Draft was created.