I don’t think engineers are very good at pairing. I know I wasn’t, and it was a big reason why I took my previous job at Carbon Five where I was pairing all the time. In addition to being a well respected shop, I thought forcing myself to pair all the time might improve my ability at working with other developers, explaining concepts to others, and might even make my job more enjoyable.

This style is actually very close to an actual navigator / driver situation in a car or on a boat. With all the high level commands coming from the navigator and the lower level implementation happening from the driver.

This style of programming is all about increasing communication and collaboration. Verbally communicating code and editor commands is a skill like anything else but it is one that many people have not developed yet. Don't worry, it's pretty easy to gain and most people pick it up the basics in a few hours.

It's more fun than it sounds: two programmers at one computer. One drives; the other navigates. Switching roles fluidly, they constantly communicate. Together, they accomplish better work more quickly than either could alone.

The driver types. She focuses on tactics--writing clean code that compiles and runs. The navigator focuses on strategy--how the code fits into the overall design, which tests will drive the code forward, and which refactorings will improve the entire codebase.

Pairs self-organize by selecting partners who can best help with the current task. They switch every few hours to share perspectives and knowledge.

This article focuses on an argument based on the author’s extensive experience with development and pairing. If you’d like to read a summary of scientific studies conducted on pair programming, check out our Scientific Research Into Pairing article.