Yes, I practice part-time pair programming, as do a lot of programmers I know. Frankly, I think it's good to pair full-time while you (you, personally or your t

Yes, I practice part-time pair programming, as do a lot of programmers I know. Frankly, I think it's good to pair full-time while you (you, personally or your team) are learning it, but not beyond that. The OP tried pairing for a month - not enough time to learn how to do it well, IMO. People pair for all sorts of reasons - as a continuous code review, knowledge sharing, and mentoring; but as the OP described, it comes at a cost - of flexibility, and of innovative design[1]. It takes experience to learn how the cost/benefit of pairing stacks up for any given situation[2]. One of these days I'll get around to documenting pairing ant-patterns I've witnessed. For now, here's one: Guerrilla Pairing: Programmer A is in the middle of a task. Programmer B is blocked waiting on something so feels the need to pair, notices Programmer A is unpaired, and jumps in. Programmer A will now spend time bringing Programmer B up to speed, at which time, Programmer B becomes unblocked on her original task and jumps back to that, rendering the disruption in Programmer A's day pointless. [1] Any design that cannot be communicated orally or sketched out in code in under 5 minutes is unlikely to emerge from a pair. [2] Situations including type of work, availability of a pair, etc.