Programmers, teach non-geeks the true cost of interruptions (2014) • Hacker News Board

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

#91

Post by snarf21 » Fri, Jul 09, 2021, 9:05 PM UTC

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…

Interruptions are annoying but I think people are going a little overboard with this vitriol. I would wager that we are all just as guilty of doing the same to our team members who are deep in thought on something. "Did you merge that git branch?", "Is the staging server down for you?", "Can you take a look at this query and see if you notice anything?"; things like this are batted around between co-workers without thinking much about what someone else is doing. We expect co-workers to get back to us right away so that WE are no longer blocked. If someone is showing offline, we'll just ping the next person and so on until we get an answer. The difference is that the other engineers are on our team, we are in it together. The others aren't and they don't "deserve" to interrupt us.

The other thing I don't see being discussed is that maximizing LoC per day may not be the thing that provides the most value to the company. It is tough though because those things aren't necessarily concrete and don't give us the same kind of satisfaction and feedback. We can't point to a new class or module or page that is now done, even if what it does isn't actually the result needed from the business. Sometimes the most important value you can provide to a business is thinking about what you are working on or what the newest requests from the business side are.

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

#92

Post by MattGaiser » Fri, Jul 09, 2021, 9:06 PM UTC

isbvhodnvemrwvn wrote: post #50

lordnacho wrote: post #23

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…

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

Looking at their schedules for the ones on my team, you could not break up software development like they do with that they do.

My manager's day is filled with stuff in 15 minute to 1.5 hour increments.

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

#93

Post by lordnacho » Fri, Jul 09, 2021, 9:06 PM UTC

camjohnson26 wrote: post #47

lordnacho wrote: post #23

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…

I agree it's silly to hit back at people.

As for managing the interruptions, I tend to think of it that a deep session needs maybe 3 hours from one end of the pool to the other. Break it and you might need to start over, depends on how checkpointy you can make it, so try to make a way to not get interrupted for that length of time. That's a real senior coder skill BTW, making your own exploration recoverable. You already mentioned one thing you can do, which is to not try the really long crossings.

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

#94

Post by haliskerbas » Fri, Jul 09, 2021, 9:06 PM UTC

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…

> Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. 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.

When we get to this sort of absolute perspective. I like to think “either everyone before me is/was an idiot, or maybe I’m missing an unknown unknown”

I’m sure other technical fields of non programming require holding more than one thought in the head at once.

Perhaps anyone constructing anything that depends on an intricate set of rules may experience the same thing.

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

#95

Post by MattGaiser » Fri, Jul 09, 2021, 9:08 PM UTC

snarf21 wrote: post #91

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…

Interruptions are annoying but I think people are going a little overboard with this vitriol. I would wager that we are all just as guilty of doing the same to our team members who are deep in thought on something. "Did you merge that git branch?", "Is the staging server down for you?", "Can you take a look at this query and see if you notice anything?"; things like this are batted around between co-workers without t…

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.

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

#96

Post by lowercased » Fri, Jul 09, 2021, 9:08 PM UTC

xwdv wrote: post #56

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. 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 trying to address the problem. We don't really have to. It is far better for us to keep selling the ima…

> and certainly within a single company no one has to work as deeply in their minds as the programmers do.

I sort of agree, but... I do think there are orgs where folks do deep thought work who aren't labelled 'programmers', but... they're probably doing the same 'type' of thinking, at some level, as folks doing coding.

I'm certain 'developers' aren't the only folks who do deep thinking work, but we seem to be ... the ones treated the most like we're not, at various companies. In law firms I've been in, all the lawyers get doors, and those doors are closed when they're doing 'deep work' (planning, writing, talking to clients, etc). That's ... deep work, and they're getting billed out at hundreds of dollars per hour.

20+ years ago, I was doing dev work getting billed out at $180/hr, and was stuck in a cube next to project managers who were on the phone all the time. Wearing headphones was seen as "rude" by colleagues around me, but them talking on the phone for 5+ hours per day 6 feet from me was... totally AOK.

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

#97

Post by MattGaiser » Fri, Jul 09, 2021, 9:08 PM UTC

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?"

That hell is seemingly the point.

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

#98

Post by Zababa » Fri, Jul 09, 2021, 9:09 PM UTC

SamBam wrote: post #80

Zababa wrote: post #67

Earlier quoted context omitted.

> Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?" That's already too late though. At this point I've already lost what I was doing.

I feel like if your mental model of the program is so fragile that even saying "Sorry, I'm in the middle of something important" breaks it, then it may be worth working out how to ground more of it. When I find myself six or seven levels deep in a stack, I often realize I need to open up a new coding window and write myself some quick notes.

That's a fair point and good advice, however the full quote was "Sorry, I'm in the middle of something important. Can you come back at lunch time?", which can then start being a full conversation to find a time that fits both of you. I think a good way to respect other people time is to use asynchronous means of communication as long as what you ask isn't urgent.

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

#99

Post by a1369209993 » Fri, Jul 09, 2021, 9:09 PM UTC

testudovictoria wrote: post #31

leephillips wrote: post #17

Earlier quoted context omitted.

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…

> Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work. Wow. This is exactly what the top comment was talking about with the opening sentence. These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.

> These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.

They didn't claim that. They claimed that the fact that these people don't do real work means that they don't need deep concentration to be successful. A implies B, not B implies A. (For example, off the top of my head, plumbers (unlike salesdroids and managers) clearly do real work, but very little if any of it involves a deep mental model that would take significant time to rebuild if interrupted.)

FWIW, I don't actually agree with that implication as such - it would imply that, eg, playing Factorio is "real work" - but the problem is less stupid than "doesn't need deep concentration => doesn't do real work".

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

#100

Post by jolmg » Fri, Jul 09, 2021, 9:09 PM UTC

lowercased wrote: post #77

lordnacho wrote: post #70

Earlier quoted context omitted.

Intuitivists. They might take their time to refine their thoughts but they aren't programmers. Type one thing wrong and your novel is still a novel.

type one thing wrong and my code is still code, but the meaning changes, just like the meaning in the novel changes. with many novels, the author may have intended X, but readers are often encouraged to bring their own views and interpretations to the work, and those may often be useful to others in understanding the work. that's not as true for most software I've worked on though.

And when I mentioned writers, I was thinking of the work that's probably required to build the plot, even before writing it. I'm not a writer, but I would imagine it involves holding a world and timeline in their head and tweak it while making sure they're not introducing plot-holes. I imagine quite a bit of research is involved, too.