Pair Programming

A developer typically writes code alone. Pair programming is a practice in which two developers are paired together to jointly complete a task. The task could be software design, algorithm, coding or testing. The rationale is that two minds are better than one. If done correctly, pair programming yields better software faster and at lower cost.

The pair share the same computer and possibly share a single keyboard. Each developer of the pair has a specific role but roles alternate often. Moreover, pairs are not static. Any two developers in the team could become a pair for a few hours.

Pair programming is an essential practice in Extreme Programming. Remote pair programming is a specialization where developers can be at different locations. Peer programming is a term that's sometimes used when more than two developers are involved.


  • Why should I adopt pair programming?
    Benefits of pair programming. Source: Böckeler and Siessegger 2020.
    Benefits of pair programming. Source: Böckeler and Siessegger 2020.

    Among the many benefits of pair programming are faster onboarding of employees, better collaboration within the team, faster processing of pull requests (where code changes are reviewed and accepted), fewer bugs and ultimately better quality software. Pair programming also fits nicely into modern development pipelines such as CI/CD and truck-based development.

    Codebase is more consistent with coding guidelines due to collaboration. Solutions are better designed. Where problems are challenging, pair programming finds solutions faster. Due to increased social interaction, there's greater job satisfaction and higher productivity.

    Ultimately, pair programming is not just about writing code. It's also about planning the work, discussing ideas, clarifying viewpoints and coming up with better solutions.

  • What are the different styles of pair programming?
    Driver-navigator pairing style. Source: Böckeler and Siessegger 2020.
    Driver-navigator pairing style. Source: Böckeler and Siessegger 2020.

    A few types of pairings exist:

    • Driver-Navigator: One developer (driver) writes the code while the other (navigator) observes, asks questions, and thinks ahead. Driver explains her actions so that the navigator understands. Navigator is essentially doing a real-time code review.
    • Driving School: Aka backseat navigator or strong-style. Navigator takes more control and gives specific instructions such as "create a method" or "create a new file".
    • Tour Guide: The tour guide (driver) providing strategic and tactical thinking while also typing. The other developer is like a tourist, listening passively. In the long term, this style is not favoured since we learn better by doing than by observing.
    • Ping-Pong: Suited for Test-Driven Development (TDD) methodology. One developer writes the test while the other writes the code to make the test pass. Then they switch roles.
    • Pomodoro: Similar to ping-pong style but based on time limits. Pairing is for 25 minutes, followed by a 5-minute break. Then developers switch roles. After four such sessions, there's a longer 20-minute break. Breaks keep the sessions productive.
    • Tag-Team: Switching of roles can happen anytime for any valid reason.
  • How is strong-style different from driver-navigator style of pairing?
    Comparing traditional driver-navigator with strong-style of pairing. Source: Falco and Pyhäjärvi 2016, slide 5.
    Comparing traditional driver-navigator with strong-style of pairing. Source: Falco and Pyhäjärvi 2016, slide 5.

    In traditional driver-navigator style of pairing, the developer who gets an idea grabs the keyboard and takes the role of the driver. If the navigator doesn't know where the driver is going (due to lack of clear communication), the navigator may become bored and disengaged.

    In strong-style, the person with the idea takes the role of the navigator instead and guides the driver. Thus, both developers are actively involved. There's greater trust and knowledge sharing.

    In strong-style, the navigator gives high-level commands and the driver implements them at a low level. To ensure understanding, the navigator adjusts the level of abstraction. If the driver doesn't understand, the navigator provides more detailed commands. The driver trusts the navigator. The driver may sometimes work with partial understanding so that the navigator's flow is not broken. At a suitable pause in the flow, he may asks questions. It's been said of this style that,

    For an idea to go from your head into the computer it MUST go through someone else's hands.
  • What underlying mechanisms make pair programming effective?

    In pair programming developers are required to discuss the code and ask questions. Asking the right questions can challenge assumptions and trigger new perspectives. Pair programming is therefore not just coding but also active learning. Vocalizing our thoughts helps us to arrive at the right understanding.

    As humans, we tend to focus on general ideas than fine details. As a pair, developers are likely to spot mistakes faster. No two developers will look at code the same way. This is aided by the assignment of specific roles, driver and navigator. The driver is thinking tactically while the navigator is thinking strategically and looking at the big picture. Code reviews are immediate.

    Pair programming avoids the bad practice of writing code by trial and error: if the code works, the developer may move on without checking for hidden flaws or bigger design problems. Pair programming allows developers to understand the problem fully before starting to code.

    Pair programming allows each developer to gauge the expertise of the other and even oneself. It's easy to claim expertise but when developers discuss and explain things, they become better at gauging each other's expertise.

  • How should novices and experts be paired together?

    Pair programming is beneficial at all expertise levels because it's essentially a learned social skill. You're learning to work cooperatively with other team members. Where junior developers are involved, prioritize learning over productivity.

    It's common to identify the following pairings:

    • Novice-Novice: Novice developers may not be confident enough to tackle a challenging problem alone but they can do so more effectively as a pair.
    • Novice-Expert: Useful for training novices or quick onboarding of new developers to the project. The novice must ask questions and grow in confidence as a developer. The expert must be empathetic and explain the reasons for the code. The expert should not do all the work.
    • Expert-Expert: Useful when each expert specializes in different areas, such as frontend versus backend. They can pair up when a feature impacts both areas of expertise. One study showed that expert-expert pairing is less effective when both experts are familiar with the coding task and its solution.
  • What are some best practices for pair programming?

    Developers must have an attitude to share and learn from each other. Empathy, patience and openness are important traits. One developer should move only as fast as the other can understand.

    For better knowledge sharing and team collaboration, each developer must pair with different team members. However, where there's a personality conflict between two developers, such pairings must be avoided. Pairings can be changed daily, weekly or when user stories change.

    Pair programming can be demanding at times. Frequent breaks can help. It's also best not to do pair programming all the time or for every task. During pair programming, avoid interruptions from others. Between sessions, it's good to give and take feedback.

    To make participation easier, each developer has his own keyboard. Configure the system with key bindings and shortcuts that's comfortable to both developers. Create dedicated pairing stations uncluttered with personal items.

    Those new to pair programming can start with a simple task that can be completed in a short time. Minimize distractions during the session. Management should ask developers to try pair programming rather than forcing it on them.

  • What are the antipatterns in pair programming?
    Pair programming anti-patterns. Source: Gunjal 2018.

    The navigator should avoid a few things: pointing out errors too quickly, giving too detailed low-level instructions, and perhaps not bringing a keyboard.

    The driver should avoid a few things: driving too fast that the navigator can't keep up, partially blocking the screen, not taking breaks, driving without listening to the navigator, and avoiding eye contact.

    Both developers should avoid a few things: distractions such as notifications or text messages, not swapping roles, not communicating with your partner, or giving up too early if you're just learning to code.

  • Could you share some case studies on pair programming?
    Comparing individuals versus pairs across various measures. Source: Nosek 1998.
    Comparing individuals versus pairs across various measures. Source: Nosek 1998.

    Jensen (1996) reported from a study that pairs wrote 175 lines of code per person-month compared to 75 from individuals. Error rate was three orders of magnitude lower than the organization's norm.

    Nosek (1998) compared five experienced programmers working independently and ten others working in pairs. All teams outperformed the individuals, completing their tasks 40% faster and producing better code.

    A survey by Williams (1999) found that 96% enjoyed their job more when pair programming.

    Cockburn and Williams (2001) reported that pair programming incurs 15% extra development cost. But in the long term, it saves 15x the cost when bugs are discovered during testing or 60x the cost when bugs are experienced by customers.

    Hulkko and Abrahamsson (2005) empirically found that pair programming is most useful for learning and complex tasks. It leads to higher comment ratio. It doesn't always increase productivity, decrease defect count or conform to coding guidelines.

  • What are some concerns or criticisms of pair programming?

    Not every developer is a fan of pair programming, particularly when it's imposed on them by the management. Developers like to be trusted and pair programming makes them feel they're being watched. However, once the benefits of pair programming are understood, developers are more likely to question the implementation rather than the practice itself.

    Some problems require deep thinking that's best done in isolation. One approach is to work out the solution in advance before starting a pair programming session. In fact, humans can't multitask effectively. Pair programming requires the pair to constantly communicate while also performing their individual tasks.

    There could be a personality clash. Developers are usually introverts. To them, pair programming can be overstimulating. Even for extroverts, pair programming all the time can be exhausting. Feedback between sessions is useful but developers are not naturally inclined to share feedback.

    Two developers doing the job of one is sometimes seen as wasteful. Pairing two novices maybe ineffective but other types of pairings if correctly implemented bring long term rewards.

    Lack of ownership and accountability can be a problem. The developer who creates the pull request can be made accountable.



ENIAC, the first programmable, electronic digital computer is completed. In an interview in 2011, one of ENIAC's programmers, Jean Jennings Bartik, claims that she and Betty Synder were a pair and they programmed together. This anecdote shows that pair programming is certainly not an invention of the 21st century.


Fred Brooks, author of The Mythical Man-Month (1975), has claimed that he and fellow graduate student Bill Wright programmed together in the 1950s. He claims, "We produced 1,500 lines of defect-free code; it ran correctly first try."


In the early 1980s, Larry Constantine visits P.J. Plaugher's software company, Whitesmiths, Ltd. He observes a room full of two programmers working at each computer. He calls them "dynamic duos". Their code was defect-free. He states that, "Two programmers in tandem is not redundancy; it's a direct route to greater efficiency and better quality."


Nosek publishes The Case for Collaborative Programming, which is perhaps the first empirical study on the subject using experienced programmers. An earlier 1993 study by Wilson et al. used student programmers. Also in 1998, Extreme Programming (XP) as practiced at Chrysler is talked about. Pair programming is one of the core practices within XP.


Some practitioners of XP introduce the roles of driver and navigator to explain pair programming in a better way.


The book Pair Programming Illuminated by Williams and Kessler is the first book dedicated to pair programming. It's also perhaps a sign that pair programming is ready for mainstream adoption.


The ping-pong style of pairing is suggested on C2 Wiki. This combines pair programming with test-driven development.


On his blog, Arlo Belshee coins the term strong-style for the style of programming advocated by Llewellyn Falco. In July 2016, Falco and his colleague Maaret Pyhäjärvi present this style at the Agile2016 conference.


  1. Agile Alliance. 2015. "Pair Programming." Glossary, Agile Alliance, December 17. Updated 2021-03-04. Accessed 2021-09-15.
  2. Archer, Adam, Ritchie Schacher, and Scott Will. 2021. "Program in pairs." IBM Garage Methodology, IBM Cloud Architecture Center, IBM Corporation. Accessed 2021-09-13.
  3. Atwi, Ahmad. 2019. "10 Pair Programming Best Practices Questions & Answers." Philippe Bourgau's XP Coaching Blog, April 25. Accessed 2021-09-13.
  4. Belshee, Arlo. 2012. "Llewellyn Falco – What makes a good test suite?" Blog, Arlo Being Bloody Stupid, July 7. Updated 2012-07-15. Accessed 2021-09-15.
  5. Borgeson, Tylor. 2020. "What they don't say about Pair Programming." Level Up Coding, gitconnected, February 13. Accessed 2021-09-13.
  6. Brack, Fragner. 2016. "Pair Programming." On Medium, August 11. Accessed 2021-09-13.
  7. Böckeler, Birgitta, and Nina Siessegger. 2020. "On Pair Programming." January 15. Accessed 2021-09-13.
  8. Cockburn, Alistair and Laurie Williams. 2001. "The Costs and Benefits of Pair Programming." In: Extreme Programming Examined, pp. 223–243. Addison Wesley. Accessed 2021-09-15.
  9. Computer History Museum. 2011. "Jean Bartik: ENIAC's Programmers." Computer History Museum. Accessed 2021-09-15.
  10. Cummins, Holly, Tobias Wetzel, and Joshua Vines. 2021. "Remote pair programming." IBM Garage Methodology, IBM Cloud Architecture Center, IBM Corporation. Accessed 2021-09-13.
  11. Esposito, John. 2016. "Maaret Pyhäjärvi & Llewellyn Falco Bring Strong-Style Pairing to Agile2016 and the World." SolutionsIQ, Accenture, July 28. Accessed 2021-09-15.
  12. Falco, Llewellyn. 2014. "Llewellyn's strong-style pairing." Blog, The way things work in Llewellyn's world, June 30. Accessed 2021-09-15.
  13. Falco, Llewellyn, and Maaret Pyhäjärvi. 2016. "Strong Style Pairing." Presentation at Agile2016, July 25. Accessed 2021-09-15.
  14. Fischer, Sarah. 2014. "Peer programming: 5 reasons learning in a group beats studying on your own." Blog, Code Fellows, October 30. Accessed 2021-09-14.
  15. GreekDataGuy. 2021. "Why Everybody Hates Pair Programming." BetterProgramming, on Medium, June 24. Accessed 2021-09-13.
  16. Gunjal, Digvijay. 2018. "Pair Programming Anti Patterns." On YouTube, October 16. subscribersAccessed 2021-09-15.
  17. Hinchman-Dominguez, Amanda. 2018. "Debunking the Myths of Pair-Programming." mvndy, on Medium, August 24. Accessed 2021-09-13.
  18. Hulkko, Hanna and Pekka Abrahamsson. 2005. "A Multiple Case Study on the Impact of Pair Programming on Product Quality." Proceedings of the 27th International Conference on Software Engineering, 15-21 May. doi: 10.1109/ICSE.2005.1553595. Accessed 2021-09-13.
  19. Lui, Kim Man and Keith C.C. Chan. 2006. "Pair programming productivity: Novice–novice vs. expert–expert." Int. J. Human-Computer Studies, Elsevier, vol. 64, pp. 915-925. Accessed 2021-09-15.
  20. Nosek, John T. 1998. "The Case for Collaborative Programming." Communications of the ACM, vol. 41, no. 3, pp. 105–108, March. doi: 10.1145/272287.272333. Accessed 2021-09-15.
  21. Oram, Andy, and Greg Wilson. 2010. "A History of Pair Programming." Section 17.1 in: Making Software. O'Reilly Media, Inc. Accessed 2021-09-13.
  22. Render, Joshua. 2019. "4 Reasons Pair Programming Should Not Be a Standard Practice." Blog, Agile-Mercurial, June 6. Accessed 2021-09-13.
  23. Tuple. 2021a. "Pair Programming Styles." Pair Programming Guide, Tuple, Inc. Accessed 2021-09-15.
  24. Tuple. 2021b. "Pair Programming Antipatterns." Pair Programming Guide, Tuple, Inc. Accessed 2021-09-13.
  25. Tuple. 2021c. "How to pair with a junior developer." Pair Programming Guide, Tuple, Inc. Accessed 2021-09-13.
  26. Tuple. 2021d. "Scientific Research Into Pair Programming." Pair Programming Guide, Tuple, Inc. Accessed 2021-09-13.
  27. Wikipedia. 2021. "ENIAC." Wikipedia, September 12. Accessed 2021-09-15.
  28. Williams, Laurie A., and Robert R. Kessler. 2000. "All I really need to know about pair programming I learned in kindergarten." Communications of the ACM, vol. 43, no. 5, pp. 108–114, May. doi: 10.1145/332833.332848. Accessed 2021-09-13.

Further Reading

  1. Weblab Technology. 2018. "Pair Programming Guide." Weblab Technology, on Medium, January 25. Accessed 2021-09-13.
  2. Böckeler, Birgitta, and Nina Siessegger. 2020. "On Pair Programming." January 15. Accessed 2021-09-13.
  3. Williams, Laurie A., and Robert R. Kessler. 2000. "All I really need to know about pair programming I learned in kindergarten." Communications of the ACM, vol. 43, no. 5, pp. 108–114, May. doi: 10.1145/332833.332848. Accessed 2021-09-13.
  4. Atwi, Ahmad. 2019. "10 Pair Programming Best Practices Questions & Answers." Philippe Bourgau's XP Coaching Blog, April 25. Accessed 2021-09-13.
  5. Falco, Llewellyn. 2014. "Llewellyn's strong-style pairing." Blog, The way things work in Llewellyn's world, June 30. Accessed 2021-09-15.
  6. Williams, Laurie and Robert Kessler. 2003. "Pair Programming Illuminated." Addison Wesley.

Article Stats

Author-wise Stats for Article Edits

No. of Edits
No. of Chats

Cite As

Devopedia. 2021. "Pair Programming." Version 2, September 15. Accessed 2021-09-15.
Contributed by
1 author

Last updated on
2021-09-15 17:27:05
  • Remote Pair Programming
  • Extreme Programming
  • Agile Methodology
  • Software Engineering
  • Code Review
  • Test-Driven Development