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

41–50 of 253 posts

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

#41

Post by ebiester »

PMs explicitly know the issue with interruptions. Most PMs I know work 1-2 hours either before or after business hours precisely because this is the only time they can get work done.

Engineering Managers understand this too. And the goal is to minimize interruptions - and meetings are an interruption!

The problem is that the time pressures on someone on a manager's schedule are such that they do not get the information needed to make the necessary decisions. As such, Managers are in a trilemma:

* The PM makes the decision without the information necessary, and the team goes "why didn't you get me involved?" The PM or EM (Often working 50+ hours a week) then has to do rework and is not ready for the team. * The PM or EM interrupts someone on the team, reducing the team's ability to do useful work and being frustrated about how many meetings they have. * The PM/EM waits and is in a continual multitasking situation themselves, unable to do the creative work because they do not have the information necessary at the time they can do the work. (This also lends itself to long post-standups, and long hours for the PM.) Or, it turns into a "slack in a general channel and wait" situation. Slack is the same interruption in most organizations, even when not using direct mentions.

I've tried to constrain the times I meet my team around other necessary meetings, and it throws out my day trying to accommodate, and even then I can't always do it.

As an engineer, which do you prefer? (It's always great when the PM and EM are on a 7pm call because that's the only time we can do it, let me tell you.) Some engineers say that everything should be on paper from the PM, but that does not account for the extra time that it takes to put documentation together that may be based on faulty assumptions.

It's a fundamentally hard problem. Let's not treat it as trivial to solve.

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

#42

Post by thaumasiotes »

werber wrote: post #5

To add to this, there’s a lot of neurodiversity in the programming world. A lot of people have brilliant brains that just don’t work well with interaction. I had a discussion with other people on my team recently and realized I was the only extroverted person on the team. I think it’s also worth saying I personally think I’m one of the worst developers on the team but being able to context switch is unfairly rewarded…

> I had a discussion with other people on my team recently and realized I was the only extroverted person on the team.

> I wish respecting communication preferences was more respected. Asynchronous and non intrusive messaging seems so much better for the majority of my coworkers

I'm interested in this second point. You've provided an interpretation of what respecting your coworkers' communication preferences might mean.

- What would it mean for them to respect your communication preferences?

- If two people are going to communicate, and they have conflicting preferences, who gets accommodated?

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

#46

Post by comeonseriously »

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…

> 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 gratification. But, by leaving it off, you have still given them something and you've gotten your time back.

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

#47

Post by camjohnson26 »

lordnacho wrote: post #23
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 agree with the general point of the article. When you're deep coding you have a tentative model containing a lot of variables about the problem. You haven't committed them to memory yet, because it's all workings out that are undecided. Once you make some conclusions, that can be remembered because the end theory is simpler than the path to get there. Nobody else constructs models in their minds that are almost pur…

I’ve noticed that I have a lot less trouble with interruptions deeper in my career than starting out because those mental models are refined and intuitive now. The example presented in the article where the programmer has a carefully constructed recreation of a null reference bug could probably be broken up into a series of steps that don’t require keeping as many variables in your head.

I agree that interruptions are annoying but they’re unavoidable, and we can develop strategies to make them less impactful. Passive aggressively trying to make somebody else feel your pain is guaranteed not to work and will just make them resentful and make you look petty.

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

#48

Post by juliansimioni »

leephillips wrote: post #17
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 issue is that, in a typical workplace that employs some programmers, they are in fact the only ones who will be doing deep work that requires sustained focus. The typical office does not contain, in addition to programmers, poets, painters, and mathematicians. If it did, those people would understand. Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no con…

>because they have never done any real work

A good sales person can make the business money (you know, the thing that keeps them from disappearing) without _any_ product yet existing at all. Programmers who build something rarely bring in money by its mere existence.

Be careful who you insult because its unlikely you could do what they do, and it's not guaranteed that you'd keep your job ahead of them if it comes to it.

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

#49

Post by jbluepolarbear »

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…

How about you respect my time on the job and I’ll respect yours. A distraction cost me time needed to do my job. If someone doesn’t respect my time, I let their managers know.

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

#50

Post by isbvhodnvemrwvn »

lordnacho wrote: post #23
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 agree with the general point of the article. When you're deep coding you have a tentative model containing a lot of variables about the problem. You haven't committed them to memory yet, because it's all workings out that are undecided. Once you make some conclusions, that can be remembered because the end theory is simpler than the path to get there. Nobody else constructs models in their minds that are almost pur…

> Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc

Have you ever worked in sales or as a manager?

Post reply on HN