Both pair members have to be interested in some amount of compromise.

I often have moments where I pair with someone who doesn't value the exact same things as I do in a codebase. I try to achieve the most important of my consideration while letting them achieve the most important of theirs.

In the event of a major split that you feel that you can't compromise on, you can always bring in a third person for perspective, but you it's a bad sign if that is frequent.

I also find going back and changing the code after the fact to be a bit of a violation of trust with the pair. They probably will see that code again, and they will know that you waited for them to be gone to write it your way.

That's not to say that I won't do that from time to time, but I try to make it as rare as possible, and only when I don't think the person discovering it later is going to bother them much.

The most productive software development in my experience happens when team members informally form and disband work groups to solve problems. These work groups can involve 3, 4 or more engineers, depending on the size of the issue to solve, and can last for 5 minutes, hours or days as necessary.

This kind of work environment easily occurs when (1) the team is composed of seasoned engineers without ego attachment to getting their way, (2) the team's highest objective is code quality and "customer" satisfaction, whoever the "customer" is, and (3) the work environment (management and social values) assume that each engineer is competent, responsible, and manages time well.

Engineers, like anyone else, rise to the level of expection placed on them.