The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#181

Post by JustSomeNobody » Tue, Jul 30, 2019, 1:03 PM UTC

jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

> 1) All production programming is done in pairs, all the time.

I stopped right there. My personality is such that being social exhausts me. Don't get me wrong, I like people, I just can only do social for short bursts and then I have to recharge. There are people who get energy from other people, so this might work for them, but not for me.

Re: The art of interrupting software engineers

#182

Post by lonelappde » Tue, Jul 30, 2019, 1:04 PM UTC

jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

When do they stop and think?

When do they write documentation?

They solved the problem of breaking flow by banning flow in the first place?

Re: The art of interrupting software engineers

#183

Post by lunchables » Tue, Jul 30, 2019, 1:04 PM UTC

6thaccount2 wrote: post #37

Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the co…

Software engineers are constantly delivering products to customers. I assume the timeline for an electrical engineering project can be many months or even years, so this isn't very surprising. When you work in an environment using continuous delivery and you are shipping features to customers every day/week, there's no way you can not have more communication. These things have to be documented, support staff trained, project goals tracked, etc.

Re: The art of interrupting software engineers

#184

Post by lonelappde » Tue, Jul 30, 2019, 1:05 PM UTC

lazerwalker wrote: post #140

ahartmetz wrote: post #130

Earlier quoted context omitted.

4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself .

An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large. Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.

We invented books because human memory storage is phenomenally expensive. Why throw them awaym

Re: The art of interrupting software engineers

#185

Post by JustSomeNobody » Tue, Jul 30, 2019, 1:08 PM UTC

_betty_ wrote: post #137

irrational wrote: post #106

Earlier quoted context omitted.

This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.

Menlo innovations do pair everything and find most their employees are introverted and like it. The theory is that introverts don't dislike social interaction but unsafe social interaction. It's why you're generally more social with friends and family.

That's only one type of introvert. The type of introvert that I am wants to be in his own head as much as possible. So even family and friends wear me out after an hour or two and I have to find a place to just be in my head for a while. I love my family and friends and enjoy them, just the experience of being social exhausts me. I don't draw energy from other people.

Re: The art of interrupting software engineers

#186

Post by lioeters » Tue, Jul 30, 2019, 1:09 PM UTC

taneq wrote: post #105

jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

I didn't even get halfway through that description of an XP workplace before the little voice in the back of my head started screaming and it still hasn't stopped.

Haha, me too, the voice in the back of my head pleaded, "Make it stop..!"

Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach.

However, every point in the description of an XP workplace sounds like torture. Paired programming, in a shared room, always a "low buzz of conversation", requirements not written but verbal only.. To be fully engaged and productive, I need the exact opposite.

Re: The art of interrupting software engineers

#187

Post by disappearance » Tue, Jul 30, 2019, 1:09 PM UTC

pflenker wrote: post #115

whycombagator wrote: post #20

> I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with. This is monumentally bad advice. > I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break So surveill and/or eavesdrop and/or ambush. Nice. > Hadrien Raffalli is…

> So surveill and/or eavesdrop and/or ambush. Nice. It's common courtesy or some kind of "office ettiquette" that if Alice wants something from Bob, but doesn't want to interrupt, she waits until there is an opportunity. Returning from a break is an obvious cue.

I'll often go for a walk when facing a troublesome problem and return with an arbitrarily Complex model in my head.

It would be an inconvenient time for an interruption, and probably looks quite a lot like returning from a break.

Re: The art of interrupting software engineers

#188

Post by GhostVII » Tue, Jul 30, 2019, 1:10 PM UTC

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 throughout the day. Unless their is a hard deadline coming up soon (in which case it is helpful to check in with the PM so you know what to cut), requesting status updates on stories on a daily basis seems like way too much. If you want a window into what I am doing, come to standup (which should be async most of the time anyways, IMO).

I've worked at a company founded by people from Pivotal, with a very similar culture, and I'm not very surprised by this post. There were a lot of new bootcamp grads and more inexperienced developers, so the company didn't really give them the same freedom that developers are used to. Everyone pair programmed all the time, even when doing basic UI work (super exhausting), working hours were fairly strict, and work was broken down fairly finely. For better or worse, developers were treated more like just people who can write code, for the most part, rather than people who are able to intelligently prioritise tasks and take initiative on things that need to be done.

Re: The art of interrupting software engineers

#189

Post by JustSomeNobody » Tue, Jul 30, 2019, 1:11 PM UTC

technion wrote: post #179

twic wrote: post #152

Earlier quoted context omitted.

Having followed the process as described, i'd agree. If a project runs for more than a few months, you forget why decisions were made. I don't think XP in general has a great story about how to deal with this.

I'd be less worried about "forgetting" and forever worried about a manager just saying "you obviously forgot (something I just decided)". I mean it happens even when there's documentation I can pull up and say "well actually..", I'd hate to imagine otherwise.

I love email for this. That way I can always pull up the email and say, "this is what we decided." I follow up all meetings with email(s).

Re: The art of interrupting software engineers

#190

Post by GoToRO » Tue, Jul 30, 2019, 1:11 PM UTC

Iv wrote: post #83

Here is a missing advice in the art of interrupting software engineers: don't. Use asynchronous messaging, not alert-based messaging. Send emails. Make sure they read emails once a day and only interrupt if your question is really more urgent than that. Thanks. Daily meetings are not good. They waste people time and constitute an interruption. If you can sync the whole team so that the meeting happens on the morning…

16 people in the daily, 1 hour every day (because we are 16). That means 16 man hours a day are for the daily. 2 people work full time to have the daily. Crazy.