[ohwaitnvm]

Yeah I'm not sure where verbal-only came from! We definitely do less upfront specification of say a whole project or months of work - we'd probably call that waterfall style and suggest that likely so many things contained therein will change or be outright wrong that it's better to have just a rough outline, and build definition as work gets closer to being actionable or executed.

I think the interruption thing is interesting - at jobs where I was solo, I probably minded it significantly more. With constant pairing, different interruptions can be handled in different ways. Two-second questions can be answered by the non-driver while the driver continues to focus. Five minute answers should probably stop both members, but having two brains allows you to bounce back into context through re-merging your mental model of where you left off.

Thinking about this though, I realized that in pairing you have internal interruptions as well - if one person needs to use the bathroom or take a phone call, the other can choose to keep working and maintain context. When the breaker returns they can reload their mental models much more easily. Or you can both take breaks and you've already got a built-in ping-pong opponent ready to play :)

[lioeters]

> having two brains allows you to bounce back into context

Wow, I never thought of pair programming like that. It sounds nice actually, to let another brain keep the ball rolling while one is busy with something else.

It makes me realize that a big part of my reluctance (preconceived notions about pair programming) is due to having worked alone for most of my career. I never experienced the kind of "mind meld" you describe. I'll remember to keep an open mind about collaborative working methods!