Some days an interruption will throw me off my train of thought, and I spend the remaining six hours collecting discarded bottles and railway ties for hopeful use somewhere, somehow, sometime.
Other days an interruption costs me pretty much nothing.
I’m still trying to figure out how to tell which of those days I’m going to have and whether to just not log into Slack for the day.
As I get older, I feel I take more time to get back on track.
I don't feel less intelligent, maybe more experience compensates for it. I probably make less wrong turns. But I have to be more rigid to prevent interruptions.
For me, it is more about the nature of the interruption. An easy question that only requires pulling something from memory doesn't cost much. A question that requires some thinking has a huge cost, even more so when you have to check the code or documentation. Sometimes even reading an email/teams notification can throw me off. It's not about the interaction (someone coming to your desk, a call,...), it's about the topic.
However I think that in both cases, if the interruption happens while coding, the risk of bug is about the same.
For me it's a combination of the nature of task, where I'm at and the nature and duration of the interruption. But usually an interruption causes a large amount of penalty points.
Do you think it's related to the level of emotion tied with the interruption? For example, finding out a friend or relative was in a bad accident is surely gonna be more distracting than someone asking if they can borrow a pen for a few minutes.
I've personally come to the conclusion that the novelty of the thought process is a big factor in recovery. Simply put, if I reach a conclusion that takes a rather unusual road through my mind, it's much harder to get back to after an interruption.
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.
When I'm doing "physical labour" I find interruptions almost as impactful. (Though I'd accept that I'm the type to just overthink things.)
"Take this pile of stuff and pack it in that moving truck."
I mean, sure, I might just grab the nearest thing, carry it and set it in the first available spot and repeat... But usually I'm putting a little more into it than that. Unless the destination is comically oversized, I need to make sure I'm making good use of the space. Even just packing boxes, putting a 150lb plastic tub full of ammo on top of a bunch of boxes full of dishes is... probably not going to turn out well at the other end.
I started by doing a quick walk through and looking at labels to figure out roughly what I have to deal with. If the boxes are somewhat standard, I've probably found a pattern to how they best fit to minimize wasted space. I may have some piles I'm working on on the side that are "very heavy" or "very light" to try and at least roughly sort them into "heavy on the bottom light on top". That also lets me cut down the number of trips since the "very light" boxes can probably be carried two or three at a time. The boxes stack 6" short of the top of the truck, so I should probably put these bed frame boards aside and once I have solid base of boxes I can slide those right on top...
So I'm walking around with the context of a couple of temporary piles, a couple things to go once I have the right spot for them, the rough shape of the source pile, vaguely what the inside of the truck looks like and what I need next for each stack, the next couple moves to make, and more all floating around in my head. Losing that is not without consequence.
"Get all these pallets off of the loading dock and into the store."
They probably weren't put into the truck and then unloaded based on any sort of knowledge of the layout of the store at all. And each individual stack of pallets was stacked for the lower one supporting the upper one sufficiently to survive a semi ride across the continent. (If you have two pallets of TVs and two pallets of toilet paper, you don't make a stack of each.) I could just grab the next stack, set it down where the first pallet belongs, grab the one on top, drive that to where the next belongs...
Or I could see "Hey there's two stacks here with TVs on the bottom and toilet paper on top. Those are opposite corners of the store. Let me spend a few seconds on the loading dock to restack these, and cut my driving way down."
I _could_ take this one with that one I see back there... but that one way back there is deep into the pile, and I've got limited "scratch" space to drop stuff. In all likelihood, if I don't just take this one now and eat the drive across the store, it's going to just be in my way for the next hour. Screw it.
If someone pulls me on to something else for a bit and I lose all the context, the next few steps I have planned, why I put that pallet to the side for now, etc... yeah, I'm gonna come back and operate less efficiently.
(And if you're thinking "well yeah but you're clearly an insane person" or "that's just bringing a CS background to forklift driving"... I had and have no CS background, and while I picked this stuff up way more intuitively this was something the "lifers", who in some cases had literal brain damage, were teaching to the new guys.)
"Count these recyclables by type and write down the number on this paper."
Okay this one there's no real crazy context to hold in your head, but you definitely get into a flow where your brain is almost checked out besides your hands moving containers and your brain keeping tally marks.
While I _can_ do basic math, there were a number of slightly embarrassing incidents where I'd done things like looked at a paper where I'd written "100", "100"...
Funny, you sound a lot like me. And for the record, in addition to my tech "day" job, I work in a live music venue, and a lot of the work is physical labour so I am exposed to both of the paradigms every day. I also own a tractor and split firewood manually. And I'm hoping to get forklift certified soon, because why, not? I, too, have been working since I was very young (15, in Texas, doing roofing, commercial electric and demo) and working people are my people.
Anyway, in some ways I agree more than disagree with you, but I wanted you to understand that I've had all the jobs (restaurant/Bar, field service, tech, executive, manager, director) in a lot of industries because I see value in labour and community. If the other things (welding, fork lifts, live event tech) paid better I would rather do that than work in "tech" to be honest. Real value is measured more effectively in the "real" world. Our industry is far more built on hype and performative gestures and bullshit, frankly.
Knowledge and physical work is not the right distinction. It's fine for two broad categories, but within knowledge work there is — at the very least — the manager vs. maker schedule.
Pre-pandemic, I tended to keep an erratic home-work/office-work schedule. Sometimes I would be at home working, and then leave to go to the office for a meeting, but I'd arrive a half hour before the meeting was to start. That time turned out to be mostly wasted. There was no way I was going to get any deep work done in that time. Sure, sometimes I could do some idle research, stuff that I could get into and out of quickly, but largely it was wasted time.
I could have just spent all my time in the office, but the open office plan environment is not conducive to deep work, even without direct interruptions (which there would be, too).
I guess the best solution for me would have been to arrive at the office 5-10 minutes before the meeting start time, but it was surprisingly hard to get that right, even with a predictable commute time (bus or walking).
On top of all that, I would occasionally completely miss meetings if I was in a flow state before that. I would somehow miss desktop and phone notifications that a meeting was coming up. I guess the solution to that would have been to set an actual alarm on my phone, something that I couldn't ignore, but I never ended up doing that for some reason.
This is adjacent to the post but most (software) engineers I have interacted with are amazing plate spinners and an interruption is just another (ephemeral) plate to spin and it's not even close to 20 minutes recovery time.
Unless it's an emergency (boohoo it'll take whatever it takes) or it tickles my fancy more than what I'm doing - which is a me problem.
Someone yelling at me costs themselves however long it takes to hire my replacement. I did my time working for overgrown children, I won't put up with that kind of nonsense anymore.
I’m not finding it in a quick search, but I believe I’ve read something by Mihaly Csikszentmihalyi about the time needed to get into a flow state after being interrupted.
> GMJ: How long does it take to get back to work after an interruption?
> Mark: There's good news and bad news. To have a uniform comparison, we looked at all work that was interrupted and resumed on the same day. The good news is that most interrupted work was resumed on the same day -- 81.9 percent -- and it was resumed, on average, in 23 minutes and 15 seconds, which I guess is not so long.
I interpret this and the article as saying that those 23 minutes are not spent trying to resume the original task, but on the interruption itself and the other intervening tasks that are worked on before returning to the original task.
If that interpretation is correct, those 23 mins are not wasted in confusion but simply spent on other things.
Unfortunately that's not the source. The author of this piece, Jaro Fietz aka oberien, is already familiar with that article, noting it in their diagram and linking to it toward the bottom of the page. They're looking for the underlying research itself rather than a quote about it.
>So in the end, where do the 23 minutes and 15 seconds come from? They are mentioned in interviews multiple times by Gloria Mark. But I wasn’t able to find a primary printed source. There are many more publications by Gloria Mark, but none of them turned up while searching for the 23 minutes 15 seconds figure. If someone knows a paper or study where that figure originally appears in, please tell me.
If it was actually 23mins, and not modifiable, then a myriad of important professions would be completely unviable (e.g. medicine). That is to say, it seems doubtful that the impact of interruptions can be meaningfully summarised in a single figure.
"When people did resume work on the same day, it took an
average length of time of 25 min. 26 sec (sd=54 min. 48
sec.). This may seem like a relatively short amount of time,
but it is also important to consider that before resuming work,
our informants worked in an average of 2.26 (sd=2.79)
working spheres. Thus, people’s attention was directed to
multiple other topics before resuming work. This was
reported by informants as being very detrimental. In some
cases, the physical or desktop environment is restructured,
which makes it more difficult to rely on cues to reorient one
to their interrupted task. For example, a blinking cursor at the
end of the last typed word can enable one to immediately
reorient to that document, whereas if other windows have
been opened, it can be hard to remember even which
document had been worked on."
And
"We found a trend that showed more externally interrupted
working spheres are resumed on the same day (53.3%)
compared to internally interrupted working spheres (47.6%),
X2
(1)=2.97, p<.09. Externally interrupted working spheres are
resumed on the average in a shorter time (22 min. 37 sec.,
sd=53 min. 52 sec.) than internally interrupted working
spheres, (29 min. 1 sec., sd=55 min. 43 sec.), t(987)=1.92,
p<.055."
So no, it does not say 23 minutes and 15 seconds in that paper.
But to say: "the paper never goes into details regarding the recovery time between finishing the interruption and getting back to the original task." is flat out incomplete, because they are reading the followup paper to the original work in isolation; and haven't considered that a number of reports summarized the findings of that (22 m 37s) as "about 23 minutes".
The way it is written implies the research is all wrong, rather than more accurately stating "I can't find the exact source of a quote but it's broadly 22-23 minutes, not 23m15s afaict".
There is also some irony in "ctrl+f", "23" being explained as the methodology for review on the topic of attention span for complex tasks...
I think it's unfortunately very common for people to come here into the comments without having read the article.
I'll admit I do that sometimes, mainly to get an impression as to whether or not the article is worth reading in the first place, but sometimes I'll end up getting drawn into the discussion here, having not read the article at all.
But I can't imagine posting a toplevel comment without reading the article.
A search for "Gloria Mark 23 minutes" is interesting reading.
At this point I would suggest going to the source, establish contact with Gloria Mark or a relevant student or co-author and ask whether Dr Mark can confirm that it is an accurate quote, and if so, whether it is a published result. One approach might be to develop the enquiry through a potentially sympathetic third person such as Cal Newport.
I actually thought this was going to reference the (earlier) 2000 Spolsky post (point 8 from https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...), which is itself dependent on the 15 minute per-person interruption cost (higher than 23m15s in aggregate time)
Conversely, I often think about the value I add by being interruptable, by helping my colleague with something that might save him more time than I lose. Good for the company.
As a manager a lot of the annoying interruptions I put down to, and I chafe at using the word, a lack of hustle.
Okay, so I view my job as primarily giving devs some strategic direction and priority, but also unblocking them from getting work done.
On the later, the kind of interruptions I get are from folks who just don't want to do and figure some things out for themselves. Need access to a database... Go ask infra support. Don't know who wrote this API client, go look in git. There's folks who just don't bother to go search for these things themselves.
54 comments
[ 7.0 ms ] story [ 67.6 ms ] threadOther days an interruption costs me pretty much nothing.
I’m still trying to figure out how to tell which of those days I’m going to have and whether to just not log into Slack for the day.
I don't feel less intelligent, maybe more experience compensates for it. I probably make less wrong turns. But I have to be more rigid to prevent interruptions.
Knowing what I wanted to focus on and achieve from 10-11 am makes it much easier to get back on track.
In contrast, when I simply begin working on something, I end up elsewhere easily, even without external interruptions.
However I think that in both cases, if the interruption happens while coding, the risk of bug is about the same.
Or you could be tired. It’s crazy how ineffective one gets with a little less sleep.
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.
Knowledge work is not the same as physical work. Both are noble in my opinion, but not the same.
"Take this pile of stuff and pack it in that moving truck."
I mean, sure, I might just grab the nearest thing, carry it and set it in the first available spot and repeat... But usually I'm putting a little more into it than that. Unless the destination is comically oversized, I need to make sure I'm making good use of the space. Even just packing boxes, putting a 150lb plastic tub full of ammo on top of a bunch of boxes full of dishes is... probably not going to turn out well at the other end.
I started by doing a quick walk through and looking at labels to figure out roughly what I have to deal with. If the boxes are somewhat standard, I've probably found a pattern to how they best fit to minimize wasted space. I may have some piles I'm working on on the side that are "very heavy" or "very light" to try and at least roughly sort them into "heavy on the bottom light on top". That also lets me cut down the number of trips since the "very light" boxes can probably be carried two or three at a time. The boxes stack 6" short of the top of the truck, so I should probably put these bed frame boards aside and once I have solid base of boxes I can slide those right on top...
So I'm walking around with the context of a couple of temporary piles, a couple things to go once I have the right spot for them, the rough shape of the source pile, vaguely what the inside of the truck looks like and what I need next for each stack, the next couple moves to make, and more all floating around in my head. Losing that is not without consequence.
"Get all these pallets off of the loading dock and into the store."
They probably weren't put into the truck and then unloaded based on any sort of knowledge of the layout of the store at all. And each individual stack of pallets was stacked for the lower one supporting the upper one sufficiently to survive a semi ride across the continent. (If you have two pallets of TVs and two pallets of toilet paper, you don't make a stack of each.) I could just grab the next stack, set it down where the first pallet belongs, grab the one on top, drive that to where the next belongs...
Or I could see "Hey there's two stacks here with TVs on the bottom and toilet paper on top. Those are opposite corners of the store. Let me spend a few seconds on the loading dock to restack these, and cut my driving way down."
I _could_ take this one with that one I see back there... but that one way back there is deep into the pile, and I've got limited "scratch" space to drop stuff. In all likelihood, if I don't just take this one now and eat the drive across the store, it's going to just be in my way for the next hour. Screw it.
If someone pulls me on to something else for a bit and I lose all the context, the next few steps I have planned, why I put that pallet to the side for now, etc... yeah, I'm gonna come back and operate less efficiently.
(And if you're thinking "well yeah but you're clearly an insane person" or "that's just bringing a CS background to forklift driving"... I had and have no CS background, and while I picked this stuff up way more intuitively this was something the "lifers", who in some cases had literal brain damage, were teaching to the new guys.)
"Count these recyclables by type and write down the number on this paper."
Okay this one there's no real crazy context to hold in your head, but you definitely get into a flow where your brain is almost checked out besides your hands moving containers and your brain keeping tally marks.
While I _can_ do basic math, there were a number of slightly embarrassing incidents where I'd done things like looked at a paper where I'd written "100", "100"...
Anyway, in some ways I agree more than disagree with you, but I wanted you to understand that I've had all the jobs (restaurant/Bar, field service, tech, executive, manager, director) in a lot of industries because I see value in labour and community. If the other things (welding, fork lifts, live event tech) paid better I would rather do that than work in "tech" to be honest. Real value is measured more effectively in the "real" world. Our industry is far more built on hype and performative gestures and bullshit, frankly.
I could have just spent all my time in the office, but the open office plan environment is not conducive to deep work, even without direct interruptions (which there would be, too).
I guess the best solution for me would have been to arrive at the office 5-10 minutes before the meeting start time, but it was surprisingly hard to get that right, even with a predictable commute time (bus or walking).
On top of all that, I would occasionally completely miss meetings if I was in a flow state before that. I would somehow miss desktop and phone notifications that a meeting was coming up. I guess the solution to that would have been to set an actual alarm on my phone, something that I couldn't ignore, but I never ended up doing that for some reason.
And some smartypants will schedule meetings with 1h gaps between so absolutely nothing will get done
[0] https://en.wikipedia.org/wiki/Addiction_Rare_in_Patients_Tre...
Unless it's an emergency (boohoo it'll take whatever it takes) or it tickles my fancy more than what I'm doing - which is a me problem.
> GMJ: How long does it take to get back to work after an interruption?
> Mark: There's good news and bad news. To have a uniform comparison, we looked at all work that was interrupted and resumed on the same day. The good news is that most interrupted work was resumed on the same day -- 81.9 percent -- and it was resumed, on average, in 23 minutes and 15 seconds, which I guess is not so long.
If that interpretation is correct, those 23 mins are not wasted in confusion but simply spent on other things.
Do i read it correctly?
>So in the end, where do the 23 minutes and 15 seconds come from? They are mentioned in interviews multiple times by Gloria Mark. But I wasn’t able to find a primary printed source. There are many more publications by Gloria Mark, but none of them turned up while searching for the 23 minutes 15 seconds figure. If someone knows a paper or study where that figure originally appears in, please tell me.
Again, the actual quote is not specific enough, but that would be a very wild and easily dismissed claim.
"When people did resume work on the same day, it took an average length of time of 25 min. 26 sec (sd=54 min. 48 sec.). This may seem like a relatively short amount of time, but it is also important to consider that before resuming work, our informants worked in an average of 2.26 (sd=2.79) working spheres. Thus, people’s attention was directed to multiple other topics before resuming work. This was reported by informants as being very detrimental. In some cases, the physical or desktop environment is restructured, which makes it more difficult to rely on cues to reorient one to their interrupted task. For example, a blinking cursor at the end of the last typed word can enable one to immediately reorient to that document, whereas if other windows have been opened, it can be hard to remember even which document had been worked on."
And "We found a trend that showed more externally interrupted working spheres are resumed on the same day (53.3%) compared to internally interrupted working spheres (47.6%), X2 (1)=2.97, p<.09. Externally interrupted working spheres are resumed on the average in a shorter time (22 min. 37 sec., sd=53 min. 52 sec.) than internally interrupted working spheres, (29 min. 1 sec., sd=55 min. 43 sec.), t(987)=1.92, p<.055."
So no, it does not say 23 minutes and 15 seconds in that paper.
But to say: "the paper never goes into details regarding the recovery time between finishing the interruption and getting back to the original task." is flat out incomplete, because they are reading the followup paper to the original work in isolation; and haven't considered that a number of reports summarized the findings of that (22 m 37s) as "about 23 minutes". The way it is written implies the research is all wrong, rather than more accurately stating "I can't find the exact source of a quote but it's broadly 22-23 minutes, not 23m15s afaict".
There is also some irony in "ctrl+f", "23" being explained as the methodology for review on the topic of attention span for complex tasks...
Interesting because it is an active demonstration of their entire point.
I'll admit I do that sometimes, mainly to get an impression as to whether or not the article is worth reading in the first place, but sometimes I'll end up getting drawn into the discussion here, having not read the article at all.
But I can't imagine posting a toplevel comment without reading the article.
At this point I would suggest going to the source, establish contact with Gloria Mark or a relevant student or co-author and ask whether Dr Mark can confirm that it is an accurate quote, and if so, whether it is a published result. One approach might be to develop the enquiry through a potentially sympathetic third person such as Cal Newport.
Okay, so I view my job as primarily giving devs some strategic direction and priority, but also unblocking them from getting work done.
On the later, the kind of interruptions I get are from folks who just don't want to do and figure some things out for themselves. Need access to a database... Go ask infra support. Don't know who wrote this API client, go look in git. There's folks who just don't bother to go search for these things themselves.
I just check the mail in checkpoints, 2-3 max. 4 times per day if I am focused bc anything else would be too productivity-lowering.
I think I am more sensitive to interruptions than most people maybe? This is mainly when programming. For other tasks it is a bit more tolerable.
(I thought this was on xkdc and was looking for it some time ago without success. Found it now)