I can't imagine doing any useful work in the scenario being described.

If I'm being strung along like that, knowing that my attention could be required at any minute, it is extremely hard to load a chunk of code in my head because any spare brain-cycles are reflexively spent trying to figure out if my input is required yet.

This is very much like trying to read when you're tired. You'll read 5 pages and then all of a sudden realize you don't even know what you read in the previous paragraph.

Sure you can triage your mail and small tasks and quickly do the stuff that takes 3 or 4 minutes, but I find that I often have just a few of those tasks. Certainly not enough to fill 3 hours worth of time.

Great response. It's hard to get any real work done when you have to constantly context switch between different things. Ed didn't know that he'd have to waste 3 hours of his time. It was only supposed to take 10 minutes after all.

I've often had people ask me how I could context switch all the time like I did and stay sane and a bit productive. I usually reply this: "I might be a bit rusty but I can still dual task". It's generally enough for them to realize that they are asking me to do something that they would never accept to do themselves. They might not know the first thing about computer science, project management or actual IT work, but at least they understand that they're doing something wrong when they see me multitask only because of the additional work they give me.

Call that passive-aggressivity, social engineering or mind games, I call it just a game. Multitasking at work is tons of fun when you've practiced enough to recognize and leave all error-prone activities out of the picture. And it's very good to make people double-check their problem before they come bother you, even though you're behaving like an open and helpful guy all the time.

And if you do happen to try writing some code amid the constant interruptions, you stand a good chance of introducing some stupid error that could take hours to debug later. Best not to even try to code under such conditions.

I'll add that, after enough time, one can start to do this as a self-defense mechanism. Trying to switch back and forth -- and remember to keep switching back and forth -- becomes exhausting. And after this has happened to you enough in the first few years of your career, you can also start to get pretty pissed off. Deliberately "opting out" of the counter-productive switching, and/or of dwelling on its context, can be a way of retaining your sanity. Just document your time and how it was consumed, so that you can't be accused of being the cause of missing targets.

P.S. I'll add that if the boss had taken Ed's suggestion, all of this could have happened asynchronously in email or the ticket system. Especially if the user has been given a copy of SnagIt or similar screen capture software on their system (along with strong admonition to never "snag" confidential data) and been shown how to use it.

Screenshots (or these days I suppose, video) go into the ticket. Ed can see it's "really happening". Ed confirms and follows up with Fred. Fred responds the next time he reviews emails or tickets. Ed follows up with the boss.

    Time for Sue:  ~30 minutes
    Time for boss:  ~15 minutes
    Time for Ed:  ~15 minutes
    Time for Fred:  ~15 minutes

If Fred reviews at least once a day, boss would have his answer latest by mid-day of the following day. As compared to mid-afternoon of the same day while burning a lot of expensive time/resources.

A lot of times, there isn't anything you can work on that doesn't require a lot of concentration. I got an interrupt earlier today that put me on hold for an hour, while an email chain tried to sort out what was necessary.

How can I focus on implementing a hard feature when at any point, someone might pull me away from it and knock down my house of cards?

Hell, even if I'm writing code and suddenly I have to actually start working on a different project, I have to commit what I was doing, and try to squash everything later, or start stashing code around, and set up the other project's environment, etc. That's five minutes eaten up already.

I find learning something new doesn't require a lot of context switching, and while does not show immediate productivity, the long term gains to the organization are present and quite valuable. It beats just randomly surfing the internet anyway; bean counters may not agree.

Ed allocated his time according to his bosses request. During the entire time he was dedicated to making progress on his action item. If his company allocates time so poorly it is not Ed's fault. His boss clearly deprioritized his other tasks probably because he poorly estimated the time required by close to 2 orders of magnitude.

But, this should not have taken three hours. Seems like most of that time was spent waiting for unexpected[1] blocks. Why context-switch if it is possible that you'll need to do again in two minutes?

[1] Of course, when does web conferencing software work straighaway (whether it's a problem with the software or somewhere between the keyboard and the chair).

I for one find it really difficult to context switch like that. I'd likely idly attempt to work on whatever I was doing to begin with, but it would be frustrating and not very rewarding:)

When I am on the hook like that, I think about existing problems at a high level, scribble some docs, or read some educational material.

This is what I'm getting at. I don't believe most people are so laser-focused on a single one task that they have nothing else to do but read HN. If you have one and only one thing to do, you still might as well attempt to complete some facet of it. If you really can't find things to fill your time, perhaps you have a different problem. I don't see how reading HN is less frustrating than reading documents. It sure makes a nice excuse, but it's nothing more than an excuse to waste time.

Maybe I don't get it since I have a BigCorp job, but I've always got tons of little things I can do, if/when I want to. That sure seems like significantly better use of the companies time. Making the argument that "well this shouldn't happen!" is hardly solving any problem.

Interruptions are a fact of life, embrace them when they can't be avoided.