Now, I don't know what the job description was of the person who wrote the article, or yours. Maybe your saying that distractions in management need to be expected and dealt with? You could be right, I don't really know. :)
When flying IFR then you've planned ahead, filed that plan, and either received exactly what you want or gotten an updated plan. If things change along the way you get small digestible updates. And you are of course going to brief your approach before executing it.
Meetings are much more dynamic.
I can deal with interruptions, but I’m also able to setup work blocks? People wouldn’t dream of interrupting me during a four hour meeting, and they don’t need to know my work blocks are that, rather than meetings.
I agree that context switching and interruption has a high cost, but isn't the cost pretty much the same regardless of your job?
I'll admit that trivial CRUD applications are boring, but with that kind of application it's about understanding and shaping the domain. Naming things, if you will. (disclaimer: I'm working on a CRUD app as we speak, thousands of fields in dozens of modules).
also, what does original work mean? If you mean in the sense of PhD level research, I haven't worked in a lot of places where 'original work' was done. it is mostly glueing together other people's work (which is original to the person doing the glueing maybe).
Only if you let it be.
Minimize the context. It turns out that good programming practices work well for this: break things down and encapsulate them. You haven't done that if you need to maintain a giant complex picture in your head that goes "poof" and disappears when people interrupt you, or when you need to go to the bathroom, or when you go to lunch.
Break things down into smaller parts. Encapsulate. Write things down. Get used to picking up where you left off. It takes practice just like anything else, but it's worth it. Demands on your time only become more intense as you advance in your career, so it's very beneficial to develop those skills early on.
I didn't downvote the comment (yet), but I understand why many people did: It's incredibly dismissive and wrong! Yes, you should adopt methods for keeping the context so you don't lose it and continue from where you started. I've added plenty of tools to my mental toolbox, and now I work on more complex problems more quickly then before. However, even with good context-keeping skills, protecting a block of time will still 10x your productivity over being interrupted constantly.
Developers don't demand focus time for their own comfort. It's because the focus time is necessary for good work.
1. It tries to address the sympthoms without solving the problem. Building a workflow around the distractions assumes that my time is less important than everybody else's.
2. Programming is hard. The comment suggests that the solution to the overhead caused by context switching is... adding more overhead. How about letting people work in peace instead?
In short: my work is rarely "beads on a string" that can easily be popped off, and to the degree they are, the unit of time is typically hours, not a half hour.
I let people know "ask me before you schedule over a meeting". They'll do it anyway, but this allows me to decline a meeting with an excuse if I don't need to be there. If it's important: they're not likely to explain their justification for me (in doing so providing me with more context on their problem).
If by luck 4/5 days stay unbooked you have 16 focus hours of work. I use 2 hour blocks 5 days a week
Being productive despite interruptions is a job skill. It can be achieved. It's a more realistic path to success than blocking off 4+ hours per day, because most people are in a position where they need to attend the meetings they are told to attend.