Or “what are the benefits of pair programming?”
Or “how should I get started with pair programming?”
I've recently has a number of discussions about the benefits of pair programming. Some of the thinking was that the main use of pair programming was as a learning tool, to help break down our specializations. This is the result of the emphasis we made in answering the question of breaking down specialization on a team (see How Do We Get All the Work Addressed When Our Specialists Cannot Be Everywhere?) In fact, pair programming was first proposed as a tool to help developers do better work – fewer defects, better designs – and it was found that the practice also helps with this cross-learning.
First a definition. Pair programming is “All code to be sent into production is created by two people working together at a single computer.” James Shore has an article on Pair Programming at http://www.jamesshore.com/Agile-Book/pair_programming.html (this is excerpted from the Art of Agile Development) which explains the practice.
Perhaps the canonical “benefits” paper on this practice is “The Costs and Benefits of Pair Programming” by Alastair Cockburn (one of the guys who developed the Agile Manifesto) and Laurie Williams. They tried to tease apart, through interview and data, what pair programming was all about and the paper was their findings.
In general people see the following benefits of using pair programming:
Most developers I have worked are skeptical of the idea somehow this produces better results. The thinking is that if you have 2 people doing the work where 1 used to do, it must be less productive. The reality is that if development were just a matter of typing, then yes, having two people do the work of one does not make economic sense. But if you look at the way you develop, a lot of the time is actually spent thinking (this is knowledge work after all) and so there is expected benefit of working together to improve a result. In fact, you could take this idea to the extreme. There is a concept out there called “mob programming” one keyboard / mouse for the whole team, with one team member driving and everyone else navigating (see https://www.youtube.com/watch?v=p_pvslS4gEI if you don’t believe me – and no I am not advocating this as I haven’t actually tried it myself).
Bottom line concept - “pair programming is pair 'thinking' not pair 'typing'”.
There is also significant reticence in adopting the practice as it is so different from current “solo” development practice. So my recommendation is to “try it”. Take a story that you are working and try to do it. See if there is benefit other than shared knowledge.
Note that not everyone has a positive view of the practice: