I started writing this post when I was working in the UK, almost exactly three years ago. I never finished it so it’s been gathering dust since.

I’ve been pair programming since I arrived at my current employer. 95% of the time, I really enjoy it. 5% of the time, I don’t.

I had worked almost a year at WDS at this point and looking back on the whole experience, I’ll change those numbers to 50/50.

WDS took pride in being very early in adopting XP, Extreme Programming. One important part of XP is the belief in pair programming all the time. I’m convinced pair programming can be very valuable, especially when training new-starters and when working on a difficult task. I learned so much from the experienced developers that worked at WDS. However, one of the cons is that it can be mentally taxing, and I often left the office after eight hours feeling very tired from speaking the whole day. I relished the hours when I could skip pairing to work on a problem by myself, and I missed being able to go to the side to think for myself for a little bit. It’s like I have two thinking modes - one that can only functions if I can focus by myself, and one that functions when I’m working with others.

At WDS, we tried to figure out for which tasks pair programming wasn’t useful. The conclusion was that when doing either very easy tasks like modifying simple CSS, or when doing something that’s repetitive like writing boilerplate code for a new service, pairing doesn’t make sense. The sharing of knowledge is low, the possible mistakes that can be made is low. Basically, the long-term benefits of pairing isn’t there. I think it’d made sense to have more solitary work time for tasks that could also be suitable for pair programming, for the sake of letting people think and learn by themselves as well.

As a relatively fresh developer with limited knowledge in company products and the business domain, you tend to have much less keyboard time than other developers. The first few weeks at the company, it felt like I barely touched the keyboard.  That was a real blow to my confidence and I honestly felt a bit intimidated at times. My point is that this is something that developers have to accept and shouldn’t feel bad about, especially if you don’t have a lot of previous experience compared to the other developers.

I remember feeling horrible about this. The experience wasn’t bad though, I did learn a lot from the first weeks of a pairing. It could definitely be accompanied by some sort of Bootcamp that we have at Spotify, where new developers form a small team with the aim of getting a fix or feature into production within a week.

Try to make the most out of the pairing sessions. Ask for the keyboard when you feel you want more control of how fast you’re moving. Take small breaks to go through how the version control system is working, or the continuous integration process, or how the classes are hanging together, and so on. It is your responsibility to let your partner know when you don’t understand.

I find the short learning breaks to be very important and not just crunch code to get a story completed. It’s easier to find time for them when you’re pairing since you’re always synced, but when not pairing I think it’s very valuable to be able to consistently set aside 15-60 minute slots to fill knowledge gaps.

The worst experiences I’ve had while pairing is when I’m neither driving or navigating, but merely watching without understanding.

You can reach some sort of pairing fatigue, which I think is when you really need to stop pairing and take a few hours apart. The symptoms are that the driver stops explaining what they’re doing, and the observer stops caring or just follows along without understanding where things are going. This occurred mostly when the pairing partner didn’t really know how to solve a problem, let’s say a refactoring, and just wanted try something out to see where it went.

The most negative experience I had when pairing was when working with someone who is so eager to solve a problem that they’ll literally rip the keyboard from your hands to implement it. Patience and the willingness to explain your thoughts is hugely important when pairing.

I would not want my team at Spotify to adopt pair programming at the same rate we did at WDS, but we could definitely do it more.