339
Do not Interrupt Developers, Study Says
(shiftmag.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Aug 2025
339 points (98.6% liked)
Programming
22274 readers
637 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
This study emphasizes to me that I'm not a dev, I'm the library's designated techie (aka a systems librarian). I do write scripts, but mostly I maintain servers, help coworkers with CSS, and figure out what obscure setting is assigning unwanted overdue book fines (under Configuration Menu > Fulfillment > Physical Fulfillment > Advanced Policy Configuration, naturally).
I enjoy interruptions because they help me prioritize my day.
I am a dev, and I enjoy the odd distraction. Sometimes. But not when I'm in the zone.
It's not about being a dev or not being a dev. It's about whether the tasks you are doing require you to hold a lot of state in your head. Sometimes you can't write everything down. And when someone calls you in for a quick chat about TPS reports, all that state is thrown out and has to be rebuilt from scratch.
If I'm writing a short script where I can find my place again just by reading the screen, it's not a problem. Me mentally refactoring code that goes across dozens of files and isn't documented anywhere? Please, I'll need some focus time. As a dev I'm not always in flow state, but when I am, I prefer if you let me finish what I'm doing.
Having to maintain large states is key. I've learned recently that this is why I keep starting so many new projects instead of finishing things. The larger a project becomes, the larger the states I have to hold in my head and the fewer opportunities I have to rebuild and maintain that state. So if I want to do some coding, the only option available is usually to start something new with a blank slate.
Yep. I just don't tend to have tasks that require much state, they're all pretty easy to pick up or put down.
I've had positions where I would get in the zone and didn't want to be interrupted, I get how that feels. It's lovely. I used to sit and rework test cases to handle updated requirements across dozens of files, back when I was in QA doing automated testing.