About pair programming

When I first heard about pair programming I didn't like the concept. I'm much faster on my own without someone else slowing me down.

And I was right - at the time.

This was in university and since I had programmed a lot before I started at university I solved the assignments quickly. Working together with someone who was learning programming would indeed slow me down, and slowing down would mean less time to play video games or hang out with my friends. So I worked alone as much as possible.

Nowadays, I no longer mostly implement bubble sort, linked lists or rock-paper-scissor simulators but real software with complex requirements, large codebases and actual users. The focus is no longer on passing the assignment as quickly as possible but to deliver qualitative software that provides value to my customer (and likely to their customers as well).

Pair-programming has several benefits. Chief among them being that code is being collaboratively developed. This means that fewer bugs enter the code, you get stuck less by helping each other think, and both code and design are being reviewed during implementation instead of after. This continuous review also means that - depending on the team and who you are pairing with - you can skip the PR review step and push straight to main once any pipelines pass.

Another major benefit to pairing up is the amount of knowledge sharing that takes place. By working together we learn from each other and while you can pick up patterns and techniques by reading someone else's code, it is much easier to learn it from them directly by watching them or having them explain. You also get to see how they work and might learn features of your tools that you did not know about.

I have read that frequent pair programming in teams increases inclusivity and makes people who belong to otherwise marginalized groups get a better sense of belonging. Probably because collaborating closely means you get to know each other better and someone who might not be comfortable taking centre-stage get to show off their skills in a more relaxed setting. I think this aspect of pairing is at least as important as the above two. We develop software as a team and everything that makes the team function better is a worthwhile investment.

So what about downsides? I wouldn't call them downsides, but pair programming is not always suitable.

I currently pair between 4 and 6 hours most days, but sometimes I just need to be alone. This is how I work as a person. Working together with someone for a full day can be taxing and I need some time alone to recharge.

Not all tasks are suitable for pair programming either. Some tasks are straightforward enough that pair programming will not really add anything. In my current project we sometimes just hang out in a pair programming session but work on separate tasks like these. Remaining in the virtual meeting means that the barrier to asking for help is lowered and if we reach a point where pairing up would be beneficial, doing so is as easy as sharing the screen because we're probably already talking about the problem at hand.