The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#251

Post by ohwaitnvm » Wed, Jul 31, 2019, 6:30 PM UTC

lioeters wrote: post #250

ohwaitnvm wrote: post #243

Earlier quoted context omitted.

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 is…

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 cl…

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

Re: The art of interrupting software engineers

#252

Post by lioeters » Wed, Jul 31, 2019, 8:43 PM UTC

ohwaitnvm wrote: post #251

lioeters wrote: post #250

Earlier quoted context omitted.

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 cl…

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 i…

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

Re: The art of interrupting software engineers

#253

Post by parasubvert » Wed, Jul 31, 2019, 9:19 PM UTC

GhostVII wrote: post #188

Seems like engineers are not trusted to do their job. I mean if you hire lots of inexperienced engineers, fair enough, but I certainly wouldn't work at Pivotal. If my PM was constantly worrying about whether I was distracted, or working on something outside of the backlog, I wouldn't be too happy about that. As an engineer, part of my job is to prioritize my daily and weekly tasks, and to avoid getting distracted thr…

The point at Pivotal is that stories tend to be less than a day to implement. If they take longer than a day (or two), something is very wrong with the estimate, and the PM might be able to help shift priorities.

Re: The art of interrupting software engineers

#254

Post by parasubvert » Wed, Jul 31, 2019, 9:23 PM UTC

tschwimmer wrote: post #38

I'm a PM and this does not resonate with me. If you're getting status twice a day... I think something is very wrong. The brutal truth of software development is that the quality of your output is going to vary with the quality of the engineers you work with. Good engineers don't need daily standups to build great products, and bad engineers aren't going to be helped by doing twice-daily checkins.

I think you'd need to experience the flow of a place like Pivotal before passing judgement. I find it interesting that you've immediately jumped to "good vs. bad engineers". The mindset at Pivotal tends to be that all engineers are equal. There is no good or bad. This is why they rotate pairs.

Checking in with a pair isn't a status update, it's really about collaboration and visibility. Estimates are often wrong, assumptions get tested, the team dynamic is "let's ensure we all understand this".

Stories in tracker tend to be <1 day, so checking in occasionally isn't exactly a wrong thing (every half day to me is excessive), so priorities can be shifted, or big stories can be broken up.

Re: The art of interrupting software engineers

#255

Post by parasubvert » Wed, Jul 31, 2019, 9:26 PM UTC

skgoa wrote: post #133

finder83 wrote: post #64

Earlier quoted context omitted.

It depends a lot on the company. I've been fortunate enough to avoid companies like the one posted, but there really are two (maybe three) views of developers: 1.) Treat them as engineers who are capable, able to communicate problems or expected delays, and professionals who want to grow. 2.) Treat them as assembly line workers who constantly want to screw around and need to be whipped back into shape. I'd argue mayb…

In my experience "the old waterfall companies" are the ones where the engineers are trusted with a task and left to do their thing. In such an environment, managers are only there to assist the engineers. I.e. escalate issues, provide ressources etc. and most importantly: fight for their team/department in meetings. We go to our team lead only when it is necessary and he only asks for updates when he needs to report…

What's odd about the "agile" companies, is that while you are a designer or engineer in product mode, you're not supposed to attend any meetings beyond daily standup, weekly IPM, and weekly retro... Maybe the odd town hall. Maybe the odd inception day or cross-team retro every few months for a major new initiative. But that's about it. PMs do attend other meetings mostly as a liaison to the outside world, because that's the gig, but even then, it tends to be limited.

The whole point (at least at Pivotal) is to spend more time coding/designing/testing and not in meetings.