What is Pair Programming Anyway?

Ask ten software engineers what “pair programming” is, and you’ll likely get ten different answers. Following my previous blog on how pair programming unlocked my growth as a software engineer, I wanted to take a step back and explain what pair programming actually is. It’s a term that gets thrown around a lot, but what does it really mean?

Different Levels of Pair Programming

Pair programming means different things to different people. For some, it’s looking over another engineers shoulder or watching their screen. For others, it’s sitting side by side, sharing a keyboard and mouse. This gives us different levels of pairing:

Only Pairing When Someone Needs Help

To me, this isn’t really pairing. This is just helping another engineer. To initiate this, the engineer being helped has to be comfortable enough to ask for it, which isn’t always the case, and can often happen far too late. This also requires the engineer helping to be free, or pulled away from the task they were working on.

I’m not saying there’s not value in this. We should 100% be helping our colleagues out. But this is not pairing.

Only Pairing on Important or Difficult Tasks

The problem with this approach, is what’s important or difficult is subjective. A junior engineer will find far more things difficult than a senior engineer. This leads to discussions during planning, which are time consuming. It also requires two engineers to become free at the same time, or one engineer pausing their own story to work with the free engineer.

I’ve experienced this approach a few times in my career, and it’s always ended up with no pairing at all.

Sharing a Story by Splitting it into Subtasks

This is no different to two team members picking up different stories, except that it requires a mini-planning between two engineers. It’s a sign that perhaps the story should be broken apart before or during planning. You also have the same issue as before with two engineers needing to align their availability.

Pairing by Default

With this, there’s no need for someone to feel comfortable to reach out for help. There is no need to discuss when to pair, then inevitably not, saving time in planning. There’s no need for engineers to have to align availabilities, as there will always be two engineers starting and finishing a story at the same time.

With this, ownership of a whole story is shared, removing the risk of the story being delayed if someone becomes ill or takes a holiday.

What about AI/Copilot?

No. Using AI/Copilot is not pair programming. It cannot (currently) proactively make suggestions or coach other engineers. In my experience, it often gets things wrong or creates overcomplicated solutions. I’m not saying it’s completely bad, just that it should be used as a tool, similar to autocomplete rather than a replacement to pair programming.

So what is pair programming?

Pair programming is two engineers, owning the same story, within the same IDE. Working together to solve a problem. It’s a collaborative process, where both engineers are actively engaged, with the ability to take control at any time.

While the other approaches I’ve discussed are reactive, or create logistical hurdles. Pairing by default creates a culture of continuous collaboration and knowledge sharing. If your team isn’t doing it already, I encourage you to give it a try. In my opinion, the improvement in code quality, team alignment, and accelerated learning is worth the effort.