It's up to the entire company to make sure to leave ample time for developers to enter flow. And to reduce any interruptions that will negatively impact flow.
I find it really amusing when companies have "no meeting Wednesdays!" - fix your damn system so that you don't need so many meetings. I know of no actual programming problem that requires so much coordination that a programmer actively needs more than two or three meetings a week. My goal is to get every developer to 1 meeting a week (the weekly 1:1).
Things to remove:
* Meetings
* Interruptions/Noise (this is why open-plan offices are terrible)
* "Can I ask you a quick question?" questions
* High-bandwidth communication for anything that isn't life-or-death emergency
* Fire-drills/"emergencies"
* Fixed work schedule
Things to do instead:
* All meetings (with the exception of 1:1's) are optional
* Async communication wherever possible (chat rooms, email)
* Assume that any person, at any time, can be remote (this changes everything and makes sure that folks prepare ahead of time)
* 100% flexibility in work schedule to allow for folks to find their productive peaks, whether that's at 4am or 4pm
[a] Others (non devs) can be entrusted to make decisions without developer input. Rare, in my experience.I've been in several hour-long meetings where I've only had 5 minutes of input, but that 5 minutes of input saved weeks/months of frustration/headaches.
[b] Offices are setup in such a way that devs get their own quiet space without surrounding distractions.
Most money available in the industry exist at places where 'a' and 'b' don't exist.
I agree in principle, but especially when I'm still getting up to speed on a complex code base (and when am I not?) I need something like a weekly summary to achieve a good balance between exploratory and goal-driven tasks. Not to say that every weekly summary is as useful – sometimes management turns it into Sisyphean labor.
For instance when I'm starting to learn a new language: I do a mix (whatever's comfortable) between exploring and goals. Explore: read some documentation, look at tutorials, make toy projects. Goals: figure out how hard it is to get "real work" done.
The weekly summary often is the catalyst for my mind to take the different small projects and find larger threads in them.
I imagine it's due to the superficial similarities, i.e. a bunch of people running around not really knowing what they should be doing, but in a big hurry.
Perhaps it is a politically-correct version of this:
https://en.wikipedia.org/wiki/Chinese_fire_drill
which includes the substitution of mere activity
(all hands on deck & running around)
in place of the desired results.
The vast majority of business firedrills are arbitrarily caused by someone wanting a deadline met for no particular reason.
Everyone does crunch time not because there is actually a pressing emergency, but because the company wishes to extract additional effort for no additional pay.
Hm, ok. That's not been my experience. For example, I have definitely heard it used in Operations contexts to describe broken shit that needs fixing now -- things that are real problems and not drills. "Drill" to me implies preparation for an event in the future like a test or an emergency.
This makes a lot of sense to me, and might explain what's going on with the puzzling uses of "fire drill" I've witnessed in recent years. I almost want to say that there's been a shift in jargon going on, because I feel like I hear people talk about fighting fires at work less often than I used to say, a decade ago.
To the degree that it's systematic, I'd say it's probably a perjoration as people became uncomfortable talking about fighting in the workplace (or whatever).
I think striking a balance is better, or more specifically allowing individuals to find there personal optimum spot. Personally, I love working in a busy open place office with conversations and discussion going on all the time. I thrive on the energy and excitement. But I like to balance that with only working part of my day like that, and stay after the hubbub dies down.
I find it really amusing when companies have "no meeting Wednesdays!" - fix your damn system so that you don't need so many meetings. I know of no actual programming problem that requires so much coordination that a programmer actively needs more than two or three meetings a week. My goal is to get every developer to 1 meeting a week (the weekly 1:1).
Things to remove:
* Meetings
* Interruptions/Noise (this is why open-plan offices are terrible)
* "Can I ask you a quick question?" questions
* High-bandwidth communication for anything that isn't life-or-death emergency
* Fire-drills/"emergencies"
* Fixed work schedule
Things to do instead:
* All meetings (with the exception of 1:1's) are optional
* Async communication wherever possible (chat rooms, email)
* Assume that any person, at any time, can be remote (this changes everything and makes sure that folks prepare ahead of time)
* 100% flexibility in work schedule to allow for folks to find their productive peaks, whether that's at 4am or 4pm