Nine months of pair programming

Submit to HN

I’ve paired off and on throughout my programming career, but for the last nine months, I’ve had a chance to pair nearly full time. I’m not much of a drink-the-koolaid dogmatist, so I’ll try to give my honest opinion about what’s wonderful and not so wonderful about pair programming.

The Good:

Zero time for knowledge transfer – when my pair partner decided to leave the company, we didn’t have weeks of knowledge transfer sessions. Because we had been pairing about 90% of the time, there was actually no knowledge transfer required. Contrast to previous companies, where a core engineer with siloed knowledge leaving the company would wreak havoc.

I felt more productive. A pair keeps you honest and prevents you from facebooking and checking email compulsively. This meant that we would get a very strong groove going and be very productive. Conversely, by the time 4:30 or 5pm rolled around, we were pretty destroyed. While we tried to take sporadic breaks, I found that when I worked by myself, I would work longer but with more breaks. With a pair, we would work shorter hours but start to feel quite inefficient by the afternoon.

Higher quality code. I did feel that after discussing things with a pair, the overall code quality improved. For this to work, your pair doesn’t always have to be an all-knowledgeable rockstar. Even bouncing ideas off someone who doesn’t understand them fully can often lead to a better design. But it’s even better if your pair nicely complements your knowledge in areas you’re not strong in. I was lucky to work with some pretty bright people. In past companies, I had been paired with B-level guys, and that was not only a drag on productivity but also morale, leading me to dismiss pairing. But that’s more of a hiring issue, and not a pairing problem.

Not So Good

My voice got tired. I also find that when coding, something happens to my linguistic center for English and I just start speaking very strangely. Switching constantly between English and code is hard and reduces overall productivity. On the other hand, discussing things usually leads to better code.

Research and learning is awkward. It’s definitely counter productive to read over someone’s shoulder while they’re doing research, as people read and absorb information on different schedules and in different ways. For example, I google and skim pages at lightning speed, causing my partners to probably think I have ADD, but that’s what works for me. I found it extremely helpful if one person was coding, the other could use a second computer to look things up and pass things back and forth as chat links.

Creative tasks are harder. While our combined creativity in refactoring code was high, non-coding tasks such as visual/ux design became a chore with someone over your shoulder. I found it easier to break apart for such things and have one person work on the connecting code while I mocked up the design.

Simple tasks take longer. While the overhead of pairing is well justified when you’re debugging complex issues, designing new areas of the system, and so on, for quick one liner tasks the overhead of having to explain to your partner what you’re doing slowed the overall process down.

During times when I worked remotely, I was able to knock lots of little tasks in a day, whereas with a partner it felt like we achieved half as much. During remoting sessions, we would not simultaneously pair, but we would discuss things in chatrooms, and do code review via github pull requests. I believe if you are not lazy in code review, and really question every line of code, it can be just as good as pairing in terms of code quality.

Page 1 of 2 | Next page