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

191–200 of 253 posts

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

#191

Post by dave_sullivan »

camhart wrote: post #187

Programming is like riding a bike. It takes time to get on the bike, to get momentum going. Interruptions are like someone hitting you with a stick while you ride. Getting hit, falling off, and climbing back on the bike takes a lot of effort, and you have to rebuild your momentum each time it happens. The more times you're knocked off in a day, the more tired you get of climbing back on. Rebuilding the momentum when…

This is a very good analogy.

A similar one I have heard before is "It's like falling asleep... It takes a while to get into sleep mode and if someone interrupts you, you have to start the process again." Most people can understand how annoying it would be to be interrupted all night and not get a good night sleep.

Though riding a bike makes programming sound more active than sleeping, which is good.

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

#192

Post by PicassoCTs »

wruza wrote: post #190

Re-diving is not only hard but also demotivating and morally tiring. You spend the same efforts again and again and at the fourth try you just stop understanding why they need you, a deep-analyzing guy, in the first place, when they could just hire a “friday ETA at any cost, boss” guy and ship whatever they could do right at friday evening. I wore these shoes, but one case was special. I was being young, debugging so…

Similar experience in automation. When the factory was prone to that behavior or the project we got was already "escalated", we had a 2nd guy working as a "Linebacker" who would stop the whole shenanigans, allowing the first guy to work and concentrate.

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

#193

Post by dpritchett »

rendall wrote: post #164
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…

> Recovering quickly from interruptions is a skill that can be developed and learned This is absolutely true. I no longer mind interruptions. I don't love them, but they aren't devastating productivity crashes either. Weirdly enough, friendly, helpful answers to the query seems to reduce interruptions. I think people don't mind interrupting grumpy programmers. Also, adopting contemporary coding practice helps. Keepin…

Firming up your tests, logging, observability, and debugging practices really does help here.

The only time I enter a desperate fugue state juggling too many disparate code modules in my head is when the system is a poorly factored enterprise monolith.

Those aren’t uncommon but I reflexively avoid jobs that make those the majority of my work.

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

#194

Post by ElFitz »

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…

> We expect co-workers to get back to us right away so that WE are no longer blocked.

Perhaps you do, but I and some of the people I’ve had the pleasure to work with do not.

Personally, I’ve almost always worked asynchronously.

If I have a question, I send it on the proper Slack channel and either keep going on what I was doing if isn’t blocking, or do something else when it is. Tasks are usually large enough for that.

Regarding Slack interruptions, all my notifications aside from a handful of phone numbers are disabled.

Things rarely are urgent, and can usually wait an hour or even until the next break.

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

#195

Post by dpritchett »

MattGaiser wrote: post #57
ViViDboarder wrote: post #32

Earlier quoted context omitted.

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…

I forget where I read it, but there was a blog post that mentioned how open offices basically turn developers into furniture as part of the job is appearing busy like bees. This actually happened to me once. Some big investor was coming one day, so we were all to be in our seats for a certain time to show that we were productive.

Happened to us at a small agency. Allowed WFH days were standardized to specific days of the week so we could show a full house on days when we had client visits.

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

#196

Post by mtsr »

ideamotor wrote: post #167

Interruptions are very challenging with any deep work that takes hours. This is true. What I am facing however, is a related issue. Perhaps because I have not been doing much programming lately, I find it increasingly difficult to actually get and be in the zone. When I go in, I go all in, and enter a kind of fugue state where the hours slip away. While for some this may sound advantageous, in the past, it has been a…

I would recommend trying the pomodoro method: 25 minutes of work, 5 minute break away from screens, repeat. 30 minute break after a few cycles.

I’ve discovered I’m much more in touch with my mental and emotional state and even a five minute break will really relieve some of the pressure you put on your mind and body. Also because it’s just for 25 minutes anyway, it’s much easier to get started again, even with unfun work.

Edit: In case you’re worried this will make things worse, because of the regular interruption, I’ve found it to not be so bad with the exception of some types of debugging. The mind is pretty good at mulling over the problem while you’re taking a break and often I’m more effective afterwards. But the 25/5 isn’t a hard requirement and should be changed depending on preference and type of work.

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

#197

Post by Aeolos »

jbluepolarbear wrote: post #123
pc86 wrote: post #84

Earlier quoted context omitted.

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

Then you’d be the kind of person I’d say this to. I am very open and accommodating for individuals on my project that are trying to get their task done. I’ll sit down and help, guide, whatever is needed. I won’t allow a marketer, ad agent, or sales person to demand that I stop everything I’m doing and address the issue they have, only to tell them that it isn’t going to be done this sprint and you’ll have to talk to…

That is exactly my experience too.

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

#198

Post by faeyanpiraat »

dave_sullivan wrote: post #191
camhart wrote: post #187

Programming is like riding a bike. It takes time to get on the bike, to get momentum going. Interruptions are like someone hitting you with a stick while you ride. Getting hit, falling off, and climbing back on the bike takes a lot of effort, and you have to rebuild your momentum each time it happens. The more times you're knocked off in a day, the more tired you get of climbing back on. Rebuilding the momentum when…

This is a very good analogy. A similar one I have heard before is "It's like falling asleep... It takes a while to get into sleep mode and if someone interrupts you, you have to start the process again." Most people can understand how annoying it would be to be interrupted all night and not get a good night sleep. Though riding a bike makes programming sound more active than sleeping, which is good.

Some people can fall asleep almost instantly even when there is significant noise around

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

#199

Post by [deleted] »

faeyanpiraat wrote: post #198
dave_sullivan wrote: post #191

Earlier quoted context omitted.

This is a very good analogy. A similar one I have heard before is "It's like falling asleep... It takes a while to get into sleep mode and if someone interrupts you, you have to start the process again." Most people can understand how annoying it would be to be interrupted all night and not get a good night sleep. Though riding a bike makes programming sound more active than sleeping, which is good.

Some people can fall asleep almost instantly even when there is significant noise around

[deleted]

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

#200

Post by xaedes »

evilotto wrote: post #22

If you had to use a piece of software that ran lengthy operations and had to start over from the beginning if it was interrupted for any reason, would it be more effective to prevent interruptions as best you can and hope they never happen, or to fix the program so it saves its work along the way and can restart after an interruption? There are a lot of reason why you can get interrupted, not all of which are your bo…

That sounds like this line of thinking:

If you had to use a piece of software that ran lengthy operations and you had to wait very long for the results, would it be more effective to wait for the results or fix the program so it runs faster?

I.e. Some feature needs too long to be implemented? Ok lets fix these slow workers, send all the devs to a workshop for time-management and speed-coding or whatever.

Post reply on HN