The problem with pair programming is when it is used dogmatically. "two people, one workstation, alternate who writes code and who writes tests, start with test

The problem with pair programming is when it is used dogmatically. "two people, one workstation, alternate who writes code and who writes tests, start with tests first and the other person makes the code work." This is draconian but can work sometimes. I've done that and it can be interesting but I'm largely not convinced that it is a solid use of time, especially on easier problems/domains. However, pairing is great! Double so when one member is learning the ropes. Maybe one screen, maybe two. Give junior members the opportunity to drive so they get familiar in the code base. Maybe drawing boxes on a whiteboard. Asking questions. In short: _Collaborating_. A good pair session doesn't have someone coding while someone just watches or instructs. It is truly collaborative. It could be a joint investigation or it can be a mentor/mentee situation. Generally, one person at a time on code branch, but not always. Maybe one person is knocking out something jointly understood while the other is following up on other things (documentation, asking other devs, prototypes, etc). It is a great way to share tooling, tips, tricks, code history, gain shared understanding, help destroy knowledge silos, and often two sets of eyes are better than one and can catch mistakes quickly when your own tunnel vision would have you wasting time debugging something in the wrong place. I consider these types of practices to be similar to what you learned in school, like never start a sentence with "and", and other grammatical or format rules. As a novice, these rigid rules help. And then you grow up. You realize that you can bend and break all kinds of rules to achieve good results.