by Chris Erin on January 24, 2017

I received an email recently from a programmer who had just read Pairing in practice and had some questions. I try to answer them as best I can below.

The questions have been edited for clarity

Developers at Hashrocket pair on a regular basis. As a consequence, whenever we have an apprentice, we pair with them too. Actually, pairing an experienced developer with an apprentice slows down the pace. Apprentices should ask questions and senior developers should take the time to explain all that they can, within reason and the process of explaining for the purpose of teaching certainly takes time.

Two senior developers will share a lot of knowledge which makes many joint decisions easier and increases the pace of development.

Our default is to pair all the time, and our experienced developers (each developer at Hashrocket has a fair amount of experience) prefer this over working alone. Its enjoyable to share your craft with someone who also appreciates the finer points of programming. Your pair will force you to write better code than you would otherwise write by yourself. The joy of coding with an equal and the knowledge that the code will be better overall makes pairing a welcome practice each and every day.

Pairing tends to take away both the highs and lows of individual efforts. There is no chance in pairing to achieve the kind of singular development flow that many developers have experienced in their best moments. When conditions are right, an individual developer can create amazing things in a short period of time. Look at the two-week creation of Javascript by Brendan Eich. There is no way this could have happened if Brendan was pairing with another developer, because that effort took extraordinary vision and was very opinionated. If Brendan was pairing he would have had to justify each of the many decisions that he made and that discussion may have resulted in a watered down vision that took longer to implement.

There are other circumstances where a developer might feel like they could have done a better job while soloing. Writing algorithms seems to elicit a desire to write it yourself rather than being constrained by a pair. It's the type of programming that as high-level web programmers, we don't get to do very often and enjoy doing when we get the chance. You and your pair may have different approaches to solving an algorithmic problem, but can only try one approach at a time. Ultimately, if the tests pass (and hopefully there are enough tests) then you've done a good job, whatever the approach, because the tests will provide a platform for refactoring, should that prove necessary.

Another struggle we face when pairing is the conflict between "thinking" about a problem and "poking" at a problem. "Poking" at a problem means writing a test and trying to solve that test without really having any good idea what the solution will be. This mode of work can be unnerving to some people: why would you code something you don't really understand? The point to "poking" is not to solve the problem but to learn about the contours of a problem through programming. The same thing can be done by "thinking" about a problem, and done more abstractly which can yield a better solution. The conflict with pairing, however, is that the poker would rather not watch another person think. The thinker will not want to start coding before having thought. This happens sometimes, but not often enough to detract from our desire to pair.

Two developers pairing on a problem will solve problems at a faster rate with better quality than one developer working alone, but not twice as fast. Two developers working on their own on different features will be faster than two developers working together, but not twice as fast and with lower overall code quality.

The one aspect of pairing to consider, vs. two lone programmers, is communication overhead. Some tasks that two developers work on alone don't need communication overhead, perhaps there are two separate applications in two different languages. Some tasks require developers to communicate. The tasks may need to touch the same lines of code, in which case communication will be necessary to resolve conflicts. Both programmers probably want the application to have internal consistency, to use the same patterns to solve similar problems across the application, but without communication this can be difficult. If these types of things tend to be accomplished during code reviews, where iterative development slows down, then perhaps two developers working on one problem will be twice as fast. Pair programming tends to produce code that would pass initial code reviews 80% of the time.

Not all deadlines are created equal. Some deadlines are permissive and developers can put forth an effort to write the best code possible in the first iteration with minimal technical debt. Some deadlines are constrained and require developers to knowingly take on technical debt. When pairing on a problem where technical debt must be created to achieve a constrained deadline, pairing can be very helpful in order to acquire that debt in ways that can be unwound gracefully in the future.

It's important to never force pairing on a developer. If a developer is not open to the idea then it will fail. At Hashrocket, we've been fortunate to have had the opportunity to pair program as part of our hiring process and this has led to a collection of developers that believe in and enjoy pairing.

Many developers are wary of new workplace techniques, which is understandable. We all learn to program alone, late at night in the computer lab, in a basement on the family computer, or with our laptop outside in the park. In order to be a good pair programmer, a developer must appreciate that there is no such thing as perfect code and that any dedicated review of any given code will produce justified criticisms, both large and small.

It's very beneficial to have a workstation setup that conforms to pair programming. One large monitor, two keyboards and two mice per workstation are what we use at Hashrocket.

Thanks for reading. If you have questions about pairing let me know at chris.erin@hashrocket.com.