Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each others errors, and use the best ideas.
Write all production programs with two people sitting at one machine.
Jean Bartik was one of the ENIAC women, who are considered by many to be the very first programmers. They took on the task of programming when the word "program" was not even used yet, and there were no role models or books to tell them how to do this - and they decided that it would be a good idea to work in a pair. It took about 50 more years for pair programming to become a widespread term, when Kent Beck described the term in his book "Extreme Programming" in the late 1990s. The book introduced agile software development practices to a wider audience, pairing being one of them.
Pair programming essentially means that two people write code together on one machine. It is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.
The first part of this article, "How to pair", gives an overview of different practical approaches to pair programming. It's for readers who are looking to get started with pairing, or looking to get better at it.
The second and third parts, "Benefits" and "Challenges", dive deeper into what the goals of pair programming are, and how to deal with the challenges that can keep us from those goals. These parts are for you if you want to understand better why pair programming is good for your software and your team, or if you want some ideas what to improve.
Part four and five, "To pair or not to pair?", and "But really, why bother?", will conclude with our thoughts on pairing in the grand scheme of team flow and collaboration.
These classic pair programming role definitions can be applied in some way or other to many of the approaches to pairing.
The Driver is the person at the wheel, i.e. the keyboard. She is focussed on completing the tiny goal at hand, ignoring larger issues for the moment. A driver should always talk through what she is doing while doing it.
The Navigator is in the observer position, while the driver is typing. She reviews the code on-the-go, gives directions and shares thoughts. The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacles.
The idea of this role division is to have two different perspectives on the code. The driver's thinking is supposed to be more tactical, thinking about the details, the lines of code at hand. The navigator can think more strategically in their observing role. They have the big picture in mind.
A common flow goes like this: