5 ms·
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.
by MattRogish 14y ago
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
- agrona 14y agoFire drills strike me as an infrequent yet important safety measure. Unless it's some management term I don't understand?
- MattRogish 14y agoWhen someone else's lack of preparation or planning makes it your last-minute problem. NOT the life-saving kind.
- meej 14y agoI have long wondered how the phrase came to mean this, because when it happens, it's never a drill.
- mikeash 14y agoI 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.
- rcsorensen 14y agoYou go through all the pomp and circumstance like it actually mattered, even though the majority of the people running around know it doesn't.
- jaggederest 14y agoThe 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.
- meej 14y agoHm, 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.
- dmckeon 14y agoPerhaps it is a politically-correct version of this: https://en.wikipedia.org/wiki/Chinese_fire_drill 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.
- rhizome 14y agoI think the poster misspoke and they meant, "fire-fighting."
- meej 14y agoThis 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.
- rhizome 14y agoTo 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).
- dominicrodger 14y agoWe use it to mean practising how we handle bad things, such as unexpected server failures, which seems to me a reasonable appropriation of the term.
- jaggederest 14y agoDon't forget paperwork. Nothing kills productivity like logging time in quarter-hour increments, or filling out weekly summaries, for example.
- sounds 14y agoI 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.
- Bamafan 14y agoThis only works in environments where: [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.
- jrs235 14y agoI have a saying, "If someone's not crying or dying, they can wait 25 minutes."
- emmapersky 14y agoI 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.