Live data from Hacker News

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

daedtech.com

141–150 of 253 posts

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

#141
post #64

Earlier quoted context omitted.

I guess I consider it part of my Job to be there and answer questions, assist other developers, etc. (Also please do not slack me when you're sitting right next to me, it's like, more disruptive and annoying than just talking to me. But mostly just use Email, please.)

I am fine with that, just not immediately that second. And do you enable Slack notifications? I don't. I just look for the glow of the icon.

I do, though it’s not just that, it’s also the read and typing notifications and stuff I don’t like. Disabling it would make it more tolerable though.

However, there really are things I want someone to have the ability to notify immediately for. Narrow time slots on in demand hardware like prototypes or FPGAs, change of team location in a lunch room or a big lab, and drop what you’re doing and debug this when it makes sense.

Maybe I just don’t focus as deep as others.

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

#142
post #52

I have been programming since 1977/78, and sometimes for work, but most of the time for fun. As someone who does technical work at heights with rope access, and many years of technical diving on hydraulics, pneumatic, and electrical equipment, I can say it all depends on your ability to shut out interruptions and get to a good stopping point. I get frustrated when I am programming and I am interrupted, but my most fr…

FWIW I think you could write an interesting book.

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

#143

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…

If I'm interrupted while I have a lot of unstructured thoughts floating in short-term memory, I try to ask for a "couple seconds" and scribble down some key words on a post-it before switching attention. Looking at the post-it later brings most everything back.

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

#145

Earlier quoted context omitted.

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

That's one of my pet peeves in this (recurring) discussion.

If you're a programmer, and you're telling me that every time you work you have to reconstruct the state of a system so large you can barely hold it in your head, maybe you should invest in learning about modularity, abstraction, or just... taking notes?

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

#146

Earlier quoted context omitted.

> the possibility that managers do real work (they do, and hopefully this isn't controversial). I mean, I'd hope it's uncontroversial that any general statement about people has exceptions, but I assumed it was clear that we were talking about typical managers and salesdroids, not making blanket universalisms. If it wasn't I apologize for the confusion.

I don’t think it’s even possible to define - and it’s certainly not fair to summarily dismiss - typical managers. If you’re just talking about managers that are bad at their jobs, call that out. If you’re advocating for a change in the actual management structure itself, call that out. Maybe “typical” narrows the net ever so slightly, but the definition of typical is “ having the distinctive qualities of a particular…

> "typical" is applied to managers broadly

Yes.

> and then the negative characteristics you find fault with are inherent to the management role itself (and not necessarily the manager)

In the same sense that "typical" could be applied to, say, pickpockets broadly, and the associated negative characteristics are inherent to the pickpocketing role itself (and not necessarily the pickpocket)... sure? I don't really see why that would be a useful distinction, but I agree that it seems like a distinction you could make.

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

#147

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 we’re one of the few that requires nearly entirely deep work yet also often work in an environment that isn’t conducive to it. Many other professionals that do this kind of work have private offices. Painters, architects, lawyers, etc. Meanwhile we cram ourselves together, surround ourselves with physical and digital distractions, and expect near immediately responsiveness from peers. I’m glad to have my team…

> in an environment that isn’t conducive to it

You may have hit the crux of the problem. Programmers aren't uniquely dependent on deep work, but tech companies seem to be uniquely determined to do everything they can do to make the office as hostile as possible to that. Add to that the expectation of instant availability via whatever messaging and it's clear even among tech company deep workers, programmers have worse conditions.

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

#148

Earlier quoted context omitted.

At least on the teams I have been on, we didn't physically interrupt people. We sent Slack and Teams messages for all of that stuff about merges and staging.

Fair, but I think Slack/Teams are just as disruptive as physical interruptions, at least to me.

There's definitely an issue with notifications in things like Slack/Discord/Teams, but it's a symptom of a larger problem software where everything is competing for attention. Social media apps do it because it's part of their business model and built in to the addictive-by-design need to get eyes on ads.

Chat systems aren't (yet?) dependent on ad revenue, so they don't need to copy the behavior of social media, but, possibly because they use the same operating-system level notification APIs, that's how they act.

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

#149

Earlier quoted context omitted.

At least on the teams I have been on, we didn't physically interrupt people. We sent Slack and Teams messages for all of that stuff about merges and staging.

Fair, but I think Slack/Teams are just as disruptive as physical interruptions, at least to me.

How disruptive depends on company culture. If the expectation is to respond immediately, it's no different than a physical interruption. On the other hand, I leave Slack notifications off and only use it through the browser. Usually, I only notice the tiny glowing favicon once I'm largely out of the zone anyway.

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

#150

Earlier quoted context omitted.

Which, interestingly shines a light on just now reductive the original comment was. Parent comment’s take was actually more charitable to the GP by at least leaving room for the possibility that managers do real work (they do, and hopefully this isn’t controversial). And I’d go a step further and argue that even within the managerial role, there are tasks that demand focus and deep work.

> the possibility that managers do real work (they do, and hopefully this isn't controversial). I mean, I'd hope it's uncontroversial that any general statement about people has exceptions, but I assumed it was clear that we were talking about typical managers and salesdroids, not making blanket universalisms. If it wasn't I apologize for the confusion.

[deleted]
Post reply on HN