←back to thread

The cost of interrupted work (2023)

(blog.oberien.de)
282 points _vaporwave_ | 4 comments | 23 Aug 25 21:45 UTC | HN request time: 0.001s | source
Show context
PaulKeeble ◴[23 Aug 25 23:37 UTC] No.44999980[source]▶
This is a really common problem with science reporting in general. Its often the case that the news will say things about the paper that aren't in the paper, often they say something that is completely the opposite of what the paper actually represents with its data. Its become such a common thing and its very common when you can't find the referenced study itself from the article. Sometimes its the authors fault and they said things that aren't supported by the data but the science reporters do this a lot.

My basic rule on all science is go at least look at the papers abstract, method and their graphs/data. In 5 minutes you'll be better informed than the pop science article and it gets easier the more you read them.

Interruption do impact getting back in but I find it very variable, I actually if I am doing very strict TDD I recover from interruptions well. If I am busy thinking about a design or doing some more complex algorithm performance analysis its all happening in my head and they take longer. I think it is measurable and you could set up experiments to see how long it took to start producing again and if there is a slow start or not on a well defined programming task.

replies(3): >>45000015 #>>45000071 #>>45000418 #
hinkley ◴[23 Aug 25 23:43 UTC] No.45000015[source]▶
When I work places where interruptions are expected I change how I do my work. So an observer may see them costing me less time but that’s amortized across the rest of my work as a consequence of leaning into interruption. It’s still there, it’s just spread out more.
replies(1): >>45003112 #
1. monkeyelite ◴[24 Aug 25 10:45 UTC] No.45003112[source]▶
This is a great point and a lesson that has taken me decades. If you aren’t given quiet uninterrupted time the company is signaling to you that office time is about managing day to day fires, not deep work.

Often you need to protect time to get something done but they literally want you to be doing something other than writing 10k LOC.

replies(1): >>45006287 #
2. hinkley ◴[24 Aug 25 18:01 UTC] No.45006287[source]▶
At the most disruptive place I finally arranged it so I worked at home on Fridays and Monday through Thursday were used to answer questions, attend meetings, do shallow work and do exploratory work for deep work. For instance, you need to do a refactor for a new feature or a bug fix. Is the code going to just let you do it, or will this change require another, and another, and another to get things working again?

So most Fridays I knew exactly what I needed to do and I coded for a solid six+ hours. And having already poked around I typically got about twice as much done in that time as I typically would in a day.

replies(1): >>45006706 #
3. kelnos ◴[24 Aug 25 18:58 UTC] No.45006706[source]▶
Oof, I don't think I could be successful at a place like that. Only 6-ish hardcore-productive hours of coding per week would make me sad. I would want to invert your arrangement: I'm in the office Monday to answer questions and interact with people, and Tues-Fri I'm at home doing deep work.

(I know that's unrealistic. But that would be my ideal.)

replies(1): >>45007070 #
4. hinkley ◴[24 Aug 25 19:41 UTC] No.45007070{3}[source]▶
By this point the project was out of primary development and moving toward long term maintenance. My main value was in making sure everyone there understood how certificates and code signing worked, and that nobody made any dumb architectural decisions.