Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmers, teach non-geeks the true cost of interruptions (2014)

daedtech.com

Post reply on HN
Print view View original

121–130 of 253 posts

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#121

Post by titzer »

lamontcg wrote: post #119

> "Any chance I can get an ETA on having that fixed?” This is the most annoying question in the world. I usually want to respond "probably sometime before the heat death of the Universe, but honestly that could slip". Until I write the fix I have no idea that the direction I'm taking will actually work. Very often I discover some $SADNESS while trying to actually do the fix. Some test may blow up in some way I never…

> This is the most annoying question in the world.

But this is exactly the information that other people need to plan around to get on with their own work. You need to see things from their perspective. The inner workings of your processes and the long-winded explanation, from their side, is "the most annoying" response in the world.

It's a simple question. The ETA is the only information that is actionable for them. If the answer is "anywhere from a couple days to a month", then flat out say that. If you think that sounds wishy-washy and absurd and that it must then require a long-winded explanation to soften, chances are that it does sound absurd and the long-winded explanation will not soften it, but instead the person may start to think that you are unorganized and clueless. They might start to cringe at the thought of their next interaction with you. Just give them a straight answer.

FWIW, I don't know anything about your system, but it sounds like you need to invest in making triage in your system more efficient.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#122

Post by dkarl »

PragmaticPulp wrote: post #12

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…

> We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand

Is that the only possible reason they wouldn't understand? The etiquette around interruption is different in different professions, and programming seems to be on an extreme edge of a spectrum. There are professions where people work together in offices and interrupt each other all the time, without restraint. I am not smarter than them. They are doing jobs I would not be good at. Something must be different.

Maybe the work is different in some way than most other jobs, or maybe we're defective. Honestly, I think the people who are best at accommodating this difference are alpha management types who look down on programmers. They aren't surprised that we don't cope well with interruptions, just like they're not surprised that their dog is afraid of fireworks. "Stay away from my programmers. They work better when nobody talks to them."

It's people who think we're really smart, or who rely on empathy to relate to us, who keep interrupting, because they can't wrap their heads around the idea that it's hard for us. Good communication is not a magic solution for this. Every time you try to explain, they'll translate it into something that feels reasonable and relatable to them. PragmaticPulp told me that interruptions are super bad for his productivity... so whenever I have questions I'll just pop in and out really quickly. PragmaticPulp told me that interruptions are super bad for his productivity... because I should have taken that question to John instead. PragmaticPulp told me that interruptions are super bad for his productivity... because he's been under a lot of stress this week. PragmaticPulp told me that interruptions are super bad for his productivity... because he doesn't like me and doesn't like talking to me.

The idea that what we're saying is a straightforward expression of something we actually experience is way more bizarre and unlikely to them than the idea that we're trying to say something else and it's coming out in a garbled or passive-aggressive way.

I think that's why, as misguided as the article's suggestion is, the idea of allowing people to experience what we experience is so appealing. If they could experience it firsthand, then when we talked to them about it, they could accept it at face value.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#123

Post by jbluepolarbear »

pc86 wrote: post #84
jbluepolarbear wrote: post #59

Earlier quoted context omitted.

I got so tired of defending my time at a previous job that I just started saying “Is that what our producers needs me to do?” Shuts them up every time. Generally, the people that interrupted me were people that had no authority to ask me to do anything: marketers, ad agents, sales.

I can't even imagine the hell of working with someone who responds to every request with "Is that what $THIRD_PARTY needs me to do?"

Then you’d be the kind of person I’d say this to. I am very open and accommodating for individuals on my project that are trying to get their task done. I’ll sit down and help, guide, whatever is needed. I won’t allow a marketer, ad agent, or sales person to demand that I stop everything I’m doing and address the issue they have, only to tell them that it isn’t going to be done this sprint and you’ll have to talk to our producer to get that task.

The only people that I’ve worked with that were intrusive, pushy, and demanding of engineers immediate time were the people that were trying to go around the producer because they already knew their issue was low priority for the team.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#124

Post by doublejay1999 »

dang wrote: post #88
doublejay1999 wrote: post #28

People have jobs where they need to concentrate ? and...people prefer not to be interrupted when concentrating ? oh. my. god. The author looks old enough to know better than to propagate software development as some kind of novelty role in an organisation, and also old enough to know that cultivating the image of the tortured prima dona, who must not be disturbed while creating his masterwork, does a lot more harm to…

Could you please not post in the flamewar style to HN, cross into personal attack, or call names in arguments here? The site guidelines ask you not to do any of that. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting, we'd be grateful.

The submitted article is a flame war against non-developers and promotes the same attitude in the workplace. Other people have jobs too.

It's condescends :

   "Your non-techie peers just don’t get it, no matter how many times you try to make them understand."
Demeans :

   "Tell him that you bet him lunch he can’t get it done in five minutes, only getting one shot at getting the answer right. Maybe he’ll stop laughing and get to work."
..and insults :

    "complete with ridiculous buzzword BS bingo and sports metaphors about “closing out the game in the endzone” or something. By the time the dust settles and you’ve been Six-Sigma-ed into submission by 3rd degree black belts",
As long as HN keep accepting such submissions, I'll keep giving them the treatment they deserve, which I think is fair.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#125

Post by bob1029 »

aroundtown wrote: post #101

You know what helps: 1. Stop being passive aggressive about being interrupted. 2. Take notes. Dealing with [1]: it is ok, to interrupt some one who starts talking to you, tell them "Hang on", "Just a minute", "Come back in an hour". You have to put your foot down if you are working, even with bosses. Note taking[2]: early in my career I kept too much information in my head, including debugging. Life is so much better…

Taking notes is the superweapon for mitigating distractions in my experience. It doesnt eliminate the immediate impact, but it allows you to get back to a productive state so much more quickly.

As a team leader in a 7 person company, I am not entitled to any degree of dedicated focus time during the work week. Everything is ultimately my responsibility and I have to answer some important questions immediately. Being aware that you are going to be disrupted and building in some mechanisms to deal with this reality is probably the more practical path.

Trying to convince your PMs that distractions are lethal and that developers need to be protected in some anechoic chamber 8 hours a day is never going to fly. It is total fantasy. I personally try to minimize the distractions that I as a developer incur upon other developers, but I cannot change the natures of other team members or artificially inhibit their interactions. People are just going to have to learn to get along and develop boundaries naturally. Don't be afraid to stand up for yourself, but also realize you are almost certainly not a special unicorn and that eventually you will have to interact with your teammates (the ones who don't browse HN) for the business to extract any value out of you.

An additional strategy is to try and decompose your work effort into smaller steps before you begin. Trying to eat the whole elephant in 1 sitting is how you wind up in a lot of these "interrupted" situations to begin with.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#126

Post by hinkley »

PragmaticPulp wrote: post #12

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…

> We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand.

When you think what you do is special, you will only look to other 'special' people for solutions to your problems. If you understand that many disciplines have the same problems, you can crib ideas from them. It's a major reason I push people to have extracurriculars.

Most of my crisis management skills came from volunteering at public events for clubs. Your kitchen renovation guy could fill a book on how to manage customer expectations.

> Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?" > Or: "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?"

You're trying to avoid dumping brain state, so the more open ended the question is, the more state you lose. They start bringing up related facts that your brain expects to hold onto in order to fulfill social obligations, and each fact wipes out more of your train of thought. Asking the person if it's urgent invites them to monologue. Your smarter peers will see these questions as equivalent, the rest of your coworkers won't. Don't ask them to decide. Make them decide.

"Can you come back in X minutes/at time Y?" is short. Invites little commentary. If the answer is, "No you're late for a customer meeting" or "The building is on fire can't you hear the alarm?" then you were going to be interrupted anyway. We don't want to debate the relative importance of these two tasks. If we do then the interrupter wins, whether they deserve to or not.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#127

Post by hinkley »

lmilcin wrote: post #66
PragmaticPulp wrote: post #12

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…

I think the reason this is more damaging to developers because as a developer you probably can't produce anything without focusing. As to communicating when you don't want to be interrupted -- I am still working from home, and even my kids know that when the door to the office is closed they can't interrupt. When I was still working at the office I was telling people that headphones == do not disturb. Obviously, you…

I think I'd mostly be okay going back to in-office work if I had an office door, which of course I won't.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#128

Post by Crespyl »

GuB-42 wrote: post #85
MattGaiser wrote: post #14

Earlier quoted context omitted.

> Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable and no one else can understand doesn't help the situation. We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.

I think development is a profession where it is not obvious when you are interruptible. In fact one of the best manager I had outright ask me "are you interruptible?", because she doesn't know if I am deep into a complex problem or just cleaning up stuff or waiting for my code to compile. Manual labor also require focus, but when you are occupied tends to be obvious. If you are under a car, messing around with a tool…

At a prior job we actually little LED RGB light tabs that would stick on our monitors, and set them to red or green to indicate exactly this. Uptake and responses were somewhat mixed, but it was nice to have an explicit signal, beyond just putting my headphones on, that I was not going to be welcoming of interruptions for the next few hours.

At the time we were in a pretty cramped office in a co-working space, so I appreciated anything that could help cut down on distractions even a little.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#129

Post by 8note »

gopalv wrote: post #72
MattGaiser wrote: post #14

Earlier quoted context omitted.

> Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable and no one else can understand doesn't help the situation. We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.

> We seem to be the only profession that cares then. Our profession seems to be one where it is not obvious to others that we're in a flow or in deep working mode, since there is no visible difference between work-isolation mode, browsing the internet for random programming or browsing for fun, from four feet away. My uncle is a neuro plastic surgeon, he is prone to disruptions in more ways than I am (if I talk to hi…

Instead of the at work light, keeping notes on paper is somewhat obvious, and tied to actually doing the work. Plus, you can do a pretty clear mental dump when somebody wants you to context switch, and they can see you doing it

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#130

Post by HeyLaughingBoy »

jbluepolarbear wrote: post #59
comeonseriously wrote: post #46

Earlier quoted context omitted.

> Instead, communicate like peers I agree, however... > "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?" I would just say: "I can't really stop what I'm doing right now, but I can stop by your office around 3PM." If you ask them if that will work, they'll tell you they need the answer immediately most of the time. People want instant gratificati…

I got so tired of defending my time at a previous job that I just started saying “Is that what our producers needs me to do?” Shuts them up every time. Generally, the people that interrupted me were people that had no authority to ask me to do anything: marketers, ad agents, sales.

I just instruct my guys to say "I have to prioritize what I'm doing right now. Go talk to HeyLaughingBoy if you need me to work on something else."

They have no problem doing that. Do it often enough and the people learn to just come straight to me instead.

Post reply on HN