On Pair Programming, Hacker News

On Pair Programming, Hacker News

Many people who work in software development today have heard of the practice of pair programming, yet it still only has patchy adoption in the industry.   One reason for its varying acceptance is that its benefits are not immediately   Obviously, it pays off more in the medium- and long-term. And it’s also not as   simple as “two people working at a single computer”, so many dismiss it   quickly when it feels uncomfortable. However, in our experience, pair   programming is vital for collaborative teamwork and high quality   software.

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 criticize       each other, and find each others errors, and use the best ideas.

Jean Bartik, one of the very first programmers

Write all production programs with two people sitting at one machine.

Kent Beck

Jean Bartik was one of theENIAC women, who are considered by many to be the very first programs.     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 90     more years for pair programming to become a widespread term, when     Kent Beck described the term in his book “Extreme Programming” in the late      s. 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 approach 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.

How to pair

Styles Driver and Navigator

These classic pair programming role definitions can be applied in           some way or other to many of the approaches to pairing.

TheDriver is the person at the wheel, ie 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.

TheNavigator **************** 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:

************************** (Start with a reasonably well-defined task