I never did XP style pairing until I arrived in London. My experience had been mostly solo work, with plenty of team collaboration, and some rare pairing on tough problems. I was pretty excited about trying something new. And it’s part of why I picked my first role in London.

Pairing for the first time

That first day of pairing was pretty bad. It was a complex codebase that was years in the making. The person I paired with, a consultant, wasn’t interested in explaining things to me or letting me touch the keyboard. It was a very frustrating experience. I’m used to diving into new codebases and picking up things quickly. Instead, I just sat there unable to contribute much, counting down the minutes until the day ended.

What doesn’t kill you…

I eventually got the hang of pairing and started to enjoy it. It took about 6 months. That first impression really stuck in my mind though. Pairing can be downright awful when done poorly.

A few things went wrong that day. Pairing, as I understand it, is meant to be done between peers with similar amounts of knowledge. I had no on-boarding or mentoring as a new joiner. My first pairing partner was not good at pairing and didn’t have much interest in being so.

Pairing is fundamentally different to working solo. Actively interacting with another person while trying to think deeply about an engineering problem relies on a whole set of brain muscles that I wasn’t used to using. I like to think of it as social coding.

In London

Pair programming is very popular in London. If you’re from the USA, you’ll probably find it a bit of an adjustment unless you’ve worked at one of the companies that pair all the time. It’s probably more difficult to find a job that doesn’t require pairing.

I think pairing is hard to get right, and there isn’t a convention on the right way to do it. It’s also worse for individuals when it goes wrong, compared to non-pairing. It can be torture to be pair with someone when it doesn’t work out.

So you want to do it right?

I believe pair programming can be done in a constructive way, although it’s not easy.

Social, in-person interaction between team members becomes more crucial. It’s now part of the critical path of all code commits, even key presses. This requires a manager skilled in building people’s personal skills and resolving conflicts in teams. This is important in any team, but I think even more so in a team of 100% pairing.

Another thing is ownership. Pairing seems to naturally de-emphasize individual ownership and responsibility. Many teams that pair will rotate daily on tasks. It’s hard to feel ownership of a task when you only spend a day on it, then move to the next thing. I’ve seen tasks go astray, a bit like the game where a message gets passed from kid to kid by ear in a circle. For tasks longer than a day, I suggest one person stays on the task and owns it. That person is responsible for stewarding that change to production and on-boarding new pair partners.

External interaction can be tricky in a team that pairs. It’s difficult to read github feed, emails, and chat when pairing. All things commonly used in software development. All focus is on the social interaction of pairing. If your team supports external clients, I suggest having a solo support role that rotates and can respond without having to break the pairing flow.

Not all tasks are ideal to be paired on. It can be difficult to write up a detailed design doc as a pair. For research and learning, it can make sense to split up and do research independently.

People also learn differently. Ask newcomers how they learn best. Some people would prefer to spend time on their own to get up to speed. When they are ready, you can incorporate them into the pair rotation. Or if they prefer mentorship, assign a dedicated mentor for the first few weeks until they are comfortable.

Pair programming is exhausting. I believe Kent Beck claims in the XP book he doesn’t pair for more than 6 hours a day. My first pairing experience was 8 hours without many breaks. It was tiring! Take more breaks and work less hours when pairing. That’s the cost of it. Alternatively, consider a day off a week from pairing.

It’s different, not better

It annoys me when people claim pair programming is superior to anything else. The shows no obvious superiority.¹ Outside of the microcosm of London IT, I think it’s an oddity more than the norm.

Choose to pair if it suits your team, not because you think it’s the silver bullet of software engineering.