Bad pair programming

Bad pair programming

Bad pair programming can not just ruin pair programming, but the team atmosphere itself.

Play this article


Sometimes when I hear people speak about why they don't like pair programming, it is because they have had a bad experience with it. They didn't get the value of pair programming.

They haven't done pair programming correctly, or better said, the right way. Some try it blindly, which is worse than working alone on a task.

Bad pair programming is horrible. I know it because I have been there myself during my younger days. It can be much worse than working solo.

Not taking breaks

I've heard some people pair coding for hours without a single break. Of course, you feel drained after such a session!

Pair coding takes energy. You're listening, paying attention, discussing, thinking together...

Make sure to take breaks. You could for example pair code for 45 minutes and take a 10-minute break. Whatever works for you and your teammate. I don't recommend pair coding for over an hour.

Not rotating

When pair coding, one is often driving, and the other is a passenger or navigator. One of the complaints I've heard is that people find it hard to balance out who should drive or navigate, or one ends up doing it too much.

Make sure to rotate the driver, and the person typing on the keyboard, otherwise, both partners won't get to experience both sides of pair coding and it might be too much for them to either be driving or navigating all the time.

You can rotate after each break. Make sure to balance it out. That should be fine.

Dominant figure

No one should dominate. If one person is dominating and doing whatever they believe to be right, the other person won't have a pleasant experience.

This also takes away the value of pair coding. When we pair code, we have each other. That's the point of it. Two brains are better than one.

Communicate with each other, talk, make sure you're on the same page, and collaborate...

Not feeling safe

Some people don't feel safe showing the mistakes they do. This leads to them not wanting to pair code because otherwise, the partner might notice the mistakes they do.

I'm not entirely sure how to fix this situation other than saying we're a team and if one person does a mistake, it is good for the rest of the team to learn from it. We wanna become better as a team. We're building this together.

If you're one of the senior engineers on the team, something you could do:

Not preparing

Some complain that they need time to read a task or prepare for a pair coding session, and don't want to be pushed into it without preparation.

My answer to that is simple, then prepare. I agree as well, I'm rather prepared for a session, making sure we're productive and share the same understanding of what we need to do before jumping on a call to figure it out or chat about things that are unrelated.

Prepare, then pair code, there are no excuses.


Remove your ego. Put it away.

If the ego is in the way, collaboration just won't work. Discussions will never get anywhere because one of the parties is too busy defending and trying to justify whatever points.

Pair coding won't work if one of the partners got their ego in the way.


In conclusion, bad pair coding sessions can be a much worse experience than working alone. It is something we have to be aware of. We need to pair code intentionally and try to make the best out of those sessions.