Finding The Right Pair Programming Balance

Pair programming is part of the DNA of my company. We brought in Pivotal to help build the company’s first product a few years ago (before I joined) - and have been a pairing friendly environment ever since. For the past few weeks though, we’ve been trying to do 100% pair programming (including remotely). This has actually been awesome for me personally, as I’ve been able to learn a lot - especially about JavaScript. As a result of this increased pair programming I think our code quality has improved, and the team is communicating more.

However, one unexpected consequence of all this pairing was the mental and emotional exhaustion of our team. There is a huge difference between solving a problem alone and having to talk it through and implement it with another person. Writing code alone is a serene experience, and I really enjoy it, but it’s almost a different skillset than what’s needed to pair program. Yes, you still code when you pair, but pairing is much more about verbal communication and logical collaboration than it is about coding. You can’t just know what to do, and in your own non-linear way code up a story. Each step of the way is verbally discussed, alternatives that you never thought up of are introduced, and you proceed through the story in a completely different way.

The non-stop talking combined with the extra mental burden of not only dealing with your own thoughts, but also processing and integrating the other person’s thoughts is nothing short of exhausting. This is doubly true for introverts, which (from my experience) are more prevalent among programmers. This was brought to the forefront in our mini pairing retro two weeks ago, and we decided to make a few adjustments.

First, we decided to try and end pairing at 4pm. This would give us the bulk of the day to pair, but also let us rest our minds and be at peace for the last part of the day before we had to go home. Second, one of our consultants from Neo suggested we adopt an ‘Investment Fridays’ concept, which they do at Neo. Basically on Fridays you are not responsible for delivering stories, but you do have to learn or work on something relevant to what we are doing.

We’re just over a week into these new adjustments, and so far I’m really enjoying it. I get in just about as much learning and knowledge transfer as before, even though I’m pairing less. I think this has to do with the fact that towards the end of a long day of pairing, we are tired, we go slower, we start making more mistakes, and we are more prone to shaving yaks. It’s harder for my brain to absorb new information in this kind of state, but I can still make some progress on stories in my own little world. The first Investment Friday we had was also pretty awesome. I’ve been in JavaScript land for most of the last month, so I spent some time solving Project Euler problems in ruby - and learned a few new tricks!

While none of these adjustments are set in stone, they feel right. More importantly, we as a team are constantly gauging what works for us, and what makes us most productive, and keeps our code quality high. Just like we iterate on our product, we are constantly iterating on our internal processes, and over time I think we’ve been getting closer and closer to getting it right on both fronts.