Loading today’s stories
Build1 distinct publisher2 min readPublished
The 23-minute recovery figure everyone quotes was measured on general office workers, not developers, and the coding-specific study puts a full context rebuild nearer 45 minutes. That is the number a batched remediation campaign has to beat.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Treat the alert stream as a scheduling problem and the design falls out of it. A scanner that files a ticket or drops a pull-request comment the moment it finds a medium-severity dependency bump is an interrupt handler with no priority check, and shift-left practice has developers fielding a steady flow of those through the day [7]. The real cost is re-entry, not the fix itself, which is why scattering the work can erode delivery without making the codebase safer any faster [8].
Price it with the software-engineering numbers, not the famous one. The ICSE study measured roughly 10 to 15 minutes just to resume actively editing code after an interruption [5]. Its upper bound for rebuilding full mental context runs about 1.3 to 1.9 times Gloria Mark's general-office figure [1].
Then the arithmetic a campaign has to beat. Ten routine fixes arriving as ten separate pings cost 100 to 150 minutes of resume time before anyone types a line of the fixes themselves. Batched into one block, you pay that entry cost once, leaving 90 to 135 minutes [2]. I chose ten because it is a round number, not because anyone measured your repository.
For Mark's figure to price your team, two things would have to be true: your interrupts would need to resemble the ones her observers timed in general office settings, and your developers' recovery would need to look like an office worker's [4]. The dev.to post that assembles this evidence carries its own section warning readers to be careful which numbers they cite, which is the right instinct [10].
Where the design breaks is the exception path. The post is explicit that a small number of vulnerabilities still have to be fast-tracked [9], and that carve-out is the whole load-bearing joint. A campaign only recovers time if the set of findings permitted to preempt it is small and written down before the first block, not argued per finding. The second failure mode is the block itself. A recurring slot only counts as protected if a manager actually defends it against reclaiming, and a batch needs an SLA clock on it or it is just a backlog with better branding.
So the adoption bill comes down to this: a written preemption rule and a manager willing to defend a recurring calendar block, backed by an SLA you report on where people can see it. In my context that is cheaper than another deployment gate, and the post's opening complaint is that delivery hasn't gotten faster despite better frameworks and tighter gates, never mind the broader platform suites [11].
Ranked by verification strength, evidence, and original report placement.
The widely quoted figure of 23 minutes and 15 seconds to fully return to a task after an interruption comes from Gloria Mark's field research at UC Irvine, where researchers observed office workers directly and timed how long resumption took.
Mark's finding is that interrupted work is usually picked back up the same day, about 82% of the time, and that it takes roughly 23 minutes on average to get back to full focus partly because people rarely return to the original task immediately and typically drift through a couple of other things first.
Mark has noted that a fast resumption is not necessarily a costless one: people often speed up afterward, which comes with more stress and a higher error rate.
Mark's 23-minute number comes from general knowledge-work settings, not specifically from developers writing code.
A study titled "Breaking the Flow: A Study of Interruptions During Software Engineering Activities," presented at the ACM/IEEE International Conference on Software Engineering, had developers perform realistic coding, comprehension and code-review tasks while being interrupted in controlled ways, and found developers took roughly 10 to 15 minutes to resume actively editing code and up to 30 to 45 minutes to rebuild full mental context.
Attention residue is a term coined by Sophie Leroy, now dean of the University of Washington Bothell School of Business, in a 2009 study; her experiments found that when people switch from an unfinished Task A to a new Task B, part of their attention stays on Task A and performance on Task B suffers.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 1, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
science
Two social features, opposite results: a diet app trial argues against "add engagement"1 distinct publisher
science
Housing and commute type sort how Californians talk about heat online1 distinct publisher
product
The 150,000-to-1 gap: scaling is a workaround for a learning mechanism nobody has found1 distinct publisher
science
Brain organoids with a front and a back, and a fragile X gradient that flattens2 distinct publishers
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Named studies, one relay
Three anchors are named specifically enough to go check — Mark's UC Irvine observation work, Leroy's 2009 attention-residue experiments, and the ICSE paper 'Breaking the Flow' — which is more discipline than this genre usually shows. The ceiling is that all three arrive through the same dev.to post, and the one that carries the headline, the 30-to-45-minute context rebuild, comes with no authors, year or link.
Nobody named
'A growing number of engineering organizations' is the entirety of the uptake evidence. Not one company, team, or before-and-after delivery number appears, and the arithmetic that makes batching sound like hours reclaimed runs on a ten-fix workload we supplied for illustration, not a volume anyone measured.
Strict with other people's numbers, loose with its own
This post does something rare for the category: it stops mid-argument to dismantle statistics that would have flattered its case, calling the 42%-of-the-week claim marketing copy rather than research. That buys it real credit. The overhang is on the prescription, not the science — the developer-specific number is a secondhand relay, the shift to scheduled remediation blocks names no one, and the payoff is arithmetic on an assumed workload.
Content marketing that audits its peers
Read the top of the page before the headline: a raw block of search terms — 'batch security patching ROI', 'SLA-backed fix campaigns', 'DevSecOps velocity' — sitting above a piece published under a company handle and landing on a workflow that a remediation vendor would happily sell. Then read the part where it torches a competitor-flavoured statistic it could have quoted for free. Both things are true, and the second is not what pure promotion looks like.
One post, one voice
We are working from a single blog post with no second outlet, practitioner account or primary paper in front of us to test the relayed figures against. What steadies the read is that the research claims are specific and falsifiable — a named study, a named venue, a named year — while the claims about what engineering teams are actually doing are neither, and that split is exactly where our certainty divides.