Hacker News new | ask | show | jobs
by lioeters 2510 days ago
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.

1 comments

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 :)

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