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

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

#81

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

uxp100 wrote: post #64

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

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

#82

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

lordnacho wrote: post #70

jolmg wrote: post #63

Earlier quoted context omitted.

Architects, lawyers... EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.

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.

Describing a lawyer as an "intuitivist" is pretty hilarious. Their work, especially surrounding contract work, can be extremely programming like, with very particular language, highly technical and specific terms/wording, and there absolutely are many cases where typing one thing wrong (such as a misplaced comma) can (and has[1]) completely change the meaning of crucial sections of contracts.

[1] - https://www.bbc.com/worklife/article/20180723-the-commas-tha...

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

#83

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

comeonseriously wrote: post #46

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

You don't have the context of the entire business, and sometimes they have an actual need to interrupt you, and you need to stop what you're doing.

In my experience the vast majority of people are reasonable, especially in a professional environment.

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

#84

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

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

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

#85

Post by GuB-42 » Fri, Jul 09, 2021, 9:02 PM UTC

MattGaiser wrote: post #14

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…

> 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 in your hand, everyone knows it is not the best time to interrupt you. In safety-critical jobs, like in the case of pilots, there are mandatory protocols that explicitly forbit interruptions during critical moments.

People usually know enough not to barge in when the manager is having an talk with his higher up or when the salesman is negotiating with a customer unless it really is urgent.

But programmers just stare at the screen all day, and most of the work happens in their head, so how do you know if they can be interrupted or not. Bad managers assume "always", because themselves only stare at the screen during their "off" time, so they assume programmers are always "off".

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

#86

Post by lordnacho » Fri, Jul 09, 2021, 9:02 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?

Managed teams for a long time. Not a sales guy per se, other than having been in a lot of sales calls.

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

#87

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

Absolutely true, nothing unique about programming there. In fact, a game I like to play with people to show how bad context switching is, is the letters, numbers, roman numerals game.

Make two tables of 10 rows and 3 columns on a piece of paper. Column one is letters. Column 2 is roman numerals. Column 3 is numbers.

Your task is simply to write down the letters from A to J, roman numerals from I to X and numbers from 1 to 10.

You will do this twice and you will time yourself with a (cellphone) stopwatch. First time around in the first table you will fill each _row_ first. So you will write A in first row, first column, I into first row second column, 1 first row third column. B into second row first column and so forth until you're done.

The second time around you fill out columns first. I.e. A in first row first column, B in second row first column, C ...

It's a really nice game and you can even play it just against yourself or let your boss play it against himself if he wants you to multitask. If the other person says "well that's because I didn't know my roman numerals by heart any longer!" they can play it again. You can get better at it of course but it still shows the effects of context switching just from letters, to numerals to numbers. Can't get simpler than that!

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

#88

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

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.

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

#89

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

I've been tempted to hack together a web based game. It will be some simple puzzles requiring working memory, like that addition of numbers example. It could even be word problems with multiple choice answers, but the questions has to be relatively wordy with several data points to consider. Periodically it will get interrupted, by several things, but mainly a face with a speech bubble, asking various questions like "are you busy?", "can I ask you a question?", "how much longer do you think you will take to complete this?". This will completely take over the screen and you won't see your last question. You can select some answers (yes, no, 5 minutes, etc.) and some answers will lead to more questions especially if you give wrong answers. Also questions that you need to visualise to come up with an answer, like comparison of sizes or distances of things you don't often compare (bus vs yacht) After each interruption you will return to your puzzle game. The first interruption will only kick in after a while so you get used to how easy it is without interruptions, but then they'll start to kick in frequently but also randomly so you have some breaks sometime but never know for how long.

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

#90

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

lordnacho wrote: post #70

jolmg wrote: post #63

Earlier quoted context omitted.

Architects, lawyers... EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.

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.

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.