[hmeh]

Pair programming is, first and foremost, a technique for implementing continuous review. The old adage: If code reviews are good, do them constantly and continuously. We pair/mob when appropriate, and we don't do pull requests. If you pair AND do pull requests, it may be worth examining that.

The secondary order effects cannot be ignored either. On our team, pairing is used to:

- Coach more junior developers into being more proficient at their work

- Share knowledge so that norms, standards, and other knowledge can propagate through the team in a more natural (and effective) way than documentation

- Share techniques at the more tactical level

- Further explore the solution space and do better planning and execution (go slow to go fast)

And others.

[ParetoOptimal]

The biggest downside to pair programming is that unless you are a strong communicator and feel like investing the energy, great ideas get averaged down to well.. Average.

It doesn't have to be the case, but because of averages it typically is.

[hmeh]

If I understand what you are saying correctly, you are saying that if two people are pairing and the one with the better idea does not successfully communicate their idea, either from lack of trying or lack of effectiveness, then the person with the lesser idea might "win" and that is what would be implemented?

If so, I would say that the appropriate response to that is to, as a team, work to improve communication and collaboration consistently -- every day, in every work item. Leadership should reinforce the import, exemplify it, and observe and coach.

In general, what it sounds like you are saying is that people who are bad at things do things poorly. Yes, that's true, but that's why we have all the tools we have available to us to help them do things better. We don't have to like in squalor, we can choose to help each other rise above it.