...So as I was saying, he makes good points but he also invokes math. Whenever someone on a blog invokes math to make a point about computer programming, it is healthy to be a tad skeptical. (Even if it's Steve Yegge. Even if it's Paul Graham.... hell, especially if it's Paul Graham.) In that spirit, here is some nitpicking about Ethan's assumptions.
If they don't interrupt you now, then the question they need answered doesn't get addressed in a timely manner. That might also mean lost productivity.
If you aren't on break, you are in "the Zone" — all the time? Are you really in the Zone 6 hours a day? Aren't you ever compiling?
If you are interrupted for N minutes, Ethan assumes it takes exactly N minutes to get back in, regardless of N. That's seems arbitrary.
When you are spending the N minutes getting back into the Zone, is that all pure waste? I would imagine it's just normal work with a bit less momentum.
Still, it is something to think about. Cheers!
P.S. And by "something to think about" I mean to say that Ethan's conclusion is more or less correct. It is only his reasoning that is a bit flawed. There's no doubt that interruptions do waste valuable time. I also think the best reason to avoid interrupting people is they don't like it. Particularly not Ethan (or Dan). However, "Borrowing at 100% interest" is a much more compelling title than "Hey, that's kind of annoying!"
7 comments:
LOL. Math is just another tool. Yes.
Yes Ethan. I love staying in the zone too.
Ray,
Definately some good points. Of course, the math is all based on assumptions that are designed to maximize the impact of the proposoal. I here-by stand chastened for trying to use numbers to justify something I want (and I also am considering a career in presidential campagning). ; )
Still, I think there's a lot to be said for considering the practice of avoiding interruptions unless necessary. As I said in my post, you WOULD borrow at 100% interest if there was an emergency and you needed the money, but you probably wouldn't if it were for a vacation or something.
Likewise, probably 80% (another number that's mostly made up) of my interruptions are not emergencies or even things that should be looked at TODAY, and I think keeping those items to a minimum can result in nothing but good things.
I know you work in an Agile shop, and I think XP does a good job of dealing with this issue by having a "huddle" every morning. All the things that weren't important enough to bother a developer with yesterday can be brought up during that time period. That means that if a coworker is stuck on something during a development session and it's in your area of expertise, he'll probably bother you for a few minutes so he can get back on track. But he probably WON'T bother you to ask about sports or to discuss a project that hasn't even started yet or to chat about something he was "just wondering" about. You know what I mean?
By the way, I enjoy reading your posts. You should start a writer's guild.
Mike: If I did that, could I go on strike?
Seems like integrating a "placemarking" habit into one's flow state should alleviate any "oh where was i?" moments. If you feel like "you can see the path for your code clearly in front of you", learning to break that seemingly clear line of sight into a simple to-do list wouldn't take more than 10 seconds. If you can't break it down into simple steps and it's still hard to return to after interruption then you don't understand what you're doing well enough.
</twocents>
Leftover signals, if that is your real name:
I think that if you were a programmer and not an IT guy / dancer, you might agree that software is often complex enough to make task switching an serious issue. However, I would add that code would be much easier to come back to if it were cleanly abstracted.
In fact I might even go so far as to say: "Unneeded mutable state is like borrowing at 300% interest!"
Well said, Ray. There are certainly many perils WITHIN the code that can be much more wasteful than simple interruptions.
Post a Comment