376
Do not Interrupt Developers, Study Says (shiftmag.dev)
submitted 1 year ago by to c/programming@programming.dev
75 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 1 year ago (3 children)

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.

  • permalink
  • fedilink
  • source
  • hideshow 3 child comments
    •
  • [–] 19 points 1 year ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent