You are viewing an old revision of this post, from April 17, 2009 @ 19:25:34. See below for differences between this version and the current revision.
About 10 minutes into a talk he gave at the Philadelphia library, David Allen says:
A lot of it was based upon my experience getting a black belt in karate. … One of the things you need to learn is the strategic value of clear space. Trust me, when four people jump you in a dark alley, you do not want to have your brain wrapped around 3000 e-mails sitting in your in basket. That’s why, when I’m not doing anything else, folks, I’m cleaning up e-mail to zero: if I’m not exactly sure there’s something mission-critical I need to be doing right now, I am cleaning up.
Why? Because there is a surprise coming toward me I can’t see, and when that sucker hits, tonight, it might be landing while I’m speaking, … when that surprise hits, do you want to have still a lot of unconsciously accepted but not clarified agreements with yourself that you don’t know exactly what it means but it might be important and then suddenly having more stuff come in on you? That’s why interruption and surprise is becoming such a stresser these days, simply because most people have such a backlog of stuff that those surprises are hitting on huge backlogs so you have a subliminal sense of angst, you’re going to have a level there that is not clear to engage with that appropriately.
Which is a great argument for paying down your technical debt, too. If there’s one thing you can be sure about when working on legacy code, it’s that surprises are going to hit you when you don’t expect them. And, when that happens, you’ll be so much better off if you have a relatively small backlog of technical debt to work with. Whereas, if your code has “a lot of unconsciously accepted but not clarified agreements with [itself]” (where “not clarified” can mean untested, it can mean tested but badly structured, it can mean code that only one person knows how to work with), then your sense of angst will be far from subliminal, and you won’t be able to engage with the code appropriately to solve your problem.
Incidentally, about 50 minutes into the talk, he mentioned that he’s started generating a tentative daily plan. He’d previously recommended against that, since one unexpected event can and probably will change the course of your entire day, but now he’s finding it useful to structure his day by picking up a few candidate high-priority items, while accepting that events may cause that plan to change. Which I was glad to hear, because I’ve been doing that at work for a few months, and am quite happy with the results. Though he also says that he didn’t need to do that until a year ago; I’m quite sure that I’m less busy now than he was a year ago, which suggests that I’m having problems with managing my commitments and next actions.
Post Revisions:
- April 17, 2009 @ 19:35:34 [Current Revision] by David Carlton
- April 17, 2009 @ 19:25:34 by David Carlton
Changes:
There are no differences between the April 17, 2009 @ 19:25:34 revision and the current revision. (Maybe only post meta information was changed.)