The problem with pair programming, as with any other tool is when people read about it in a book and try to apply to 100% of the situations and the people as pu

The problem with pair programming, as with any other tool is when people read about it in a book and try to apply to 100% of the situations and the people as pure dogma. Several years ago I worked for a company where the "effective CTO" (he was not the CTO but given the CTO was remote (WTF!!) this guy acted as the intermediary) used to read TONS of books about XP, agile, scrum, team dynamics, programming paradigms, SOLID, design patterns, etc, etc and he *forced* every single f*ng thing he read about to everyone because "that's the professional way to do it". On the methodology front, pair programming was the worst part, as we were basically forbidden to work alone. He used to say stupid things (half kidding, half serious) such as "we should have one laptop every two developers". It was terrible. On the technical flank we ended up with a CQRS system passing messages between microservices on kubernetes and decoupled SPAs and a bastardised Python codebase that looked like Java and was the most unidiomatic python I've seen in my life, because hey, I've read the book of design patterns and object oriented programing 3rd edition. We were 5 devs. F*ng insane. So yes, a wrench can be an awesome tool to fix you car's motor, or could also be a weapon to hit somebody in the head and kill him. It's understanding the use cases and the situations what matters, not applying everything you read about as the definitive way to do it.