[ohwaitnvm]

I'm an engineer at Pivotal, having returned after a few years at startups, both practicing XP and not. The part about verbal-only requirements couldn't be more incorrect. Stories might start as a title and a sentence or two description, but more often than not here they get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down.

Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :)

EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.

[lioeters]

Thank you for the perspective! Pivotal does sound like an exciting place to work.

> [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down

Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP.

For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together.

> I also don't really mind interruptions

Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive.

I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.

[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!