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

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

#111

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

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…

Note taking is underrated especially because when you're junior you don't get interrupted and you can keep everything in your head. People think "If I could just not get interrupted" I wouldn't need to take notes.

It has the added benefit of day to day it can help you remember what you're doing. Also if you save your notes if you come back to the project in a few months you have a refresher.

Besides basic note taking I suggest two additions to it.

1. Keep it in reverse chronological order. For multiday or multiweek projects this makes it easier

2. Add the links to sites you were using instead of trusting browsing history

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

#112

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

juliansimioni wrote: post #48

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…

>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[’]s unlikely you could do what they do”

Not just unlikely—practically impossible. I don’t have the skills of a good salesperson or manager¹. But that’s orthogonal to what I was talking about, and to the subject of the fine article.

[1] And neither do most people employed in these positions.

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

#113

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

haliskerbas wrote: post #94

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…

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

In a lecture Lamport once talked about the difference between mathematical equation (where half a page is a lot) and a program (which is a sort of math, only many pages long).

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

That's not a good enough comparison. You don't see the qualitative difference.

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

#114

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

a1369209993 wrote: post #99

testudovictoria wrote: post #31

Earlier quoted context omitted.

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

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.

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

#115

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

lordnacho wrote: post #107

jolmg wrote: post #90

Earlier quoted context omitted.

As if programming can't involve intuition. There isn't one way to do things nor do we operate with strictly defined rules to follow. We need a fair amount of intuition from experience to make the decisions that will be more beneficial for the future development of our projects.

The point is others tend to rely more on intuitive structures that are everyday. Crystallised intuition about a specific domain doesn't count because of course everyone who is a specialist is going to have their own local knowledge. Calling it domain intuition might make more sense.

What kind of intuition do they rely so much on to call them intuitionists that is everyday in nature rather particular to their domain, but that programmers don't also rely on? Are we talking "everyday" like "I need to buy groceries" type of intuition? I don't understand what you're trying to say.

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

#116

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

This reminds me of the scene in The Shining when Wendy disturbs Jack. I can’t tell you how many times I’ve wanted to do Jack’s reaction when someone interrupts me.

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

#117

Post by haswell » Fri, Jul 09, 2021, 9:42 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…

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

The fundamental issue I have with this argument is that it assumes the role of “sales guy” and “manager” are always the same.

I’ve spent quite a few years in the Enterprise software space, and I can assure you that the knobs to twist on a massive deal are numerous, highly complex, and would paralyze some devs in their tracks.

It’s easy to trivialize these roles because they often appear to be full of “busy work”. If you have the opportunity, go spend some time with the sales team! Listen in on some calls. Get involved in a hiring round. Participate in a marketing meeting about establishing positioning for your next product/feature.

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

#118

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

SamBam wrote: post #102

> Now, tell him to add those numbers in his head. He can look at the screen and talk/whisper/mutter to himself, but he can’t write anything down and he can’t type anything. "Why can't I write anything down?" "Because when I'm seven to ten levels deep in a stack of issues, I never write anything down, I need to keep it all in my head ." "But why?" "Well... I have a whole mental model constructed. I couldn't possibly w…

Notes still require you to build context. Additionally, they have to be useful and up to date. I can't speak for others, but even with notes, it takes a while to get back into the flow.

This study claims it takes >20 minutes to get back on track: https://www.ics.uci.edu/~gmark/chi08-mark.pdf The effects of notes weren't quantified, but if you have a study on that, I'd be happy to read it.

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

#119

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

> "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 expected (often on some platform that I'm not actively testing until I run it through CI because I don't have an AIX virt on my laptop). That could derail me for a week or two.

Then there's CI itself which breaks quite often due to how complicated it needs to be (we have to support AIX builds and things like that). I can't give you an estimate on that because I don't know how that is going to fail or how long it'll take to fix it, but if I tell you we can fix it next week that's exactly the time CI gets broken in some way that'll take 2 weeks (often for a different team that I don't have any control over) to sort out all the mess.

The realistic estimate is often closer to 4 weeks for something that might seem like it'll only take a few days at the start. And it doesn't matter how vitally important it is to some customer. I'll try to get it out in a few days / next week, but it might slip for a month due to the unknown-unknowns and breakage outside of my direct control.

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

#120

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

haswell wrote: post #114

a1369209993 wrote: post #99

Earlier quoted context omitted.

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

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.