Apparently in NYC it is the implicit responsibility of the second person in line at a red light to immediately honk their horn when the light turns green so as to remind the first person in line that it is their turn to go. Having been the second person previously, subsequent drivers (usually numbers 3 thru 5 or so) are often concerned that this person may not be aware of this responsibility or is simply in need of assistance. So they take it upon themselves to also gently remind those in front of them of their responsibility by utilizing their horns. Who knew NYC was so full of concerned and considerate driver??
When breaking down your “stuff”, tasks get assigned a context. These contexts are an important piece for a functional GTD system since they allow you to quickly move to the next task based upon certain criteria without having to re-process your entire list of work. Given their key role in the system and highly personal nature, they’re also a big point of contention among practitioners. Here are a few things that I’ve found.
Contexts generally fall into 3 types:
- Location based contexts – “Home”, “Work”, “Errand” (specific store)
- Tool dependent contexts – “Mac”, “Browser”, “Phone”
- People specific contexts – “Boss”, “David”, “Spouse” (please use their name)
Given the broad range of people and tools we interact with on a daily basis, this list could get out of hand really fast. If you’re trying to figure out what contexts For people contexts, I’ve found that keeping the top 5 people I see the most and the least handles most cases. If you’re unsure what your contexts should be, keep a log for a week. Record where you went, who you saw/talked with, what tools you used at regular intervals throughout the day and the compile your list from that. Don’t forget to record the weekend.
Be Wary of “Anywhere”
“Anywhere” is a catch all and can be a dumping ground so be careful. It should only be for “thought” items since your brain is probably the only things you carry with you 100% of the time. Personally, I skip it so I don’t have to worry about it getting out of hand but you could always rename it to “brainstorm” a la Merlin Mann. Don’t put “Read & Review” items on here – that’s just redundant.
One and Only One
Nothing should ever have more than 1 context. If you think it does, you haven’t thought the task through completely. “I could do this at home. Or at work if I have [noun]”. That noun should be your context not “Home” as it is your real dependency. Often times envisioning yourself completing the task will help in finding the right context.
If a context gets more than about 15-20 items, it may be too general – or you may have committed to too much. Go back and do a fair assessment of your current commitments and see if you shouldn’t put off or turn down some of your projects. Trying to function with a list of that many items means you’ll have to re-process the whole list in order to figure out what to do next and that’s wasted effort.
To Tag or Not To Tag
Ok, so they’re not EVIL really unless you try to use them as contexts instead of what they’re really meant for – metadata. And, in my opinion, tags are not helpful since they simply expand the metadata around the task rather than adding to the effort to get it done. If you’re a total report monster, they’re cool to slice and dice but then I’d question how much work you’re getting done. I know I’ve burned numerous hours tweaking reports and graphs that later were completely useless.
Evolve your system. Change your contexts if you think that it will help – if you don’t like it, change it back or try something different. GTD is about find a setup that works for you within the framework.
David O’Hara is a Senior Consultant with Improving Enterprises in Dallas, Texas.
I find discussions like this one between Ayende and Casey typical of my experience in the .NET community. This archetype (I refuse to use the “M” word) is held up as the standard to which we must aim since it represents a typical, MS developer but then any discussion degrades into a “that’s too complex for this guy” argument. This is oxymoronic – these developers are NOT stupid. They’re intelligent, they get the job done, and they are able to handle things like complex business processes, recursion, debugging, etc. These developmental practices are not harder than whatever they currently are doing, they’re just different. These developers usually fall into one of two camps – they’re either unaware of the concepts or apathetic. We need to speak to the former and just hope that the latter comes around eventually.
I gave a presentation earlier this year to our local .NET user group on unit testing, mocking and dependency injection. In talking with folks afterwards about the topics, I found a very disturbing trend. Most of them knew about unit testing. At a minimum they’d heard about it but quite a few were trying to use it and several mentioned that they’d even explored NUnit and/or MbUnit. You know why there was awareness?? MSTest. Because Microsoft had created their own unit testing framework and tools and threw their marketing muscle behind it, awareness of unit testing concepts spiked. But that’s where things went south. With mocking, there was a lot of misconception around mocking and dependency injection was a totally new concept to a large majority. I find these to be fundamental to testing in the real world since rarely do we work on systems that don’t have numerous dependencies. Since we have dependencies and we have to account for them for successful testing, they are either not testing or doing integration tests instead and just calling them the wrong thing. I honestly believe that this misunderstanding, this misuse is simply due to a lack of knowledge and visibility.
I believe MSDN Events are part of the solution. While at Alt.Net, I was talking with Chris Koenig about the marketing nature of these events. He was quick to point something that eluded me previously – these are 100 & 200 level events. They’re aimed at the lowest common denominator and an entry point for developers. These are the perfect vehicles for us to introduce these practices to folks. Now, I understand Microsoft is not a non-profit organization and they shouldn’t do something unless it makes business sense so I’m asking that we come up with a good BUSINESS reason to make these more of an outreach. Like the old E.F. Hutton commercials; “When Microsoft talks, people listen.” and we need to help them tailor that message so that we can expose these people to these concepts as early as possible.
Another part of the solution is our user groups. Microsoft spends a LOT of money every year to facilitate and fund these meetings so we need to leverage these to promote good development practices. Volunteer to give a presentation or a lightning talk or just start asking questions and get a dialog going. If you’re nervous, try teaming up for a presentation. Rather than arguing who is or isn’t capable of learning something, let’s start trying to figure out how to get the material out there and nurture those who do come along.
I wanted to compile some of the things that I did in leaving my developer position at Alt-N that made things less stressful for both myself and those who were be left behind.
First off, if you’re looking for some good advice on how to resign, I highly recommend listening to the “How to Resign” podcast from Manager Tools (part 1, part 2, part 3). Heck, even if you think you know what you’re doing, listen to them – you just might pick something up.
Before “The Talk”
One of the things they talk about in the podcasts is what you need to have prepared BEFORE you walk in to resign. For a developer, this is your project list. If you’re a GTD practitioner, this should already be done, otherwise, you’ll need to put this together. Your list needs to consist of all projects you’re currently working on, the projects that are “pending” or near term, and any wish list projects. For each of these, be sure to include a short description – expected outcome in GTD parlance, any current commitments as well any specific decisions that were made. I found it easiest to think about the things I would want to know if the project were being handed to me for completion. Having this document, along with your letter of resignation, will show them that you’re not just bailing on them and are going to handle this transition in a professional manner.
The rest of the sections assume that you’re not immediately escorted out. I can’t stress enough – BE PREPARED FOR THIS TO HAPPEN, even if you know that it won’t. This is not a surprise that you’d want and it certainly isn’t something within your control so it’s better safe than sorry.
Once you’ve got an idea of how long you’ll be continuing on you’ll need to plan out your remaining time effectively. The biggest and most important piece will be to schedule a project handoff meeting for every project in your current list and possibly even the pending ones. If you don’t know who will be following up on the project, ask to have a couple of folks attend. Since this is going to be a “crash course” on the project, you have a better chance of getting the material across if there are more brains in the room as opposed to less.
Starting the day after your resignation, you should begin a conscious effort to document any and all aspects of your job. To facilitate this, I started recording what I was doing every 30 minutes. While it did slow me down and didn’t really allow for any real coding efforts to flow, it showed me a number of areas where I did things that no one else knew about. By keeping in 30 minute increments, I was able to easily remember what I had been up to and not miss anything. Turning this over to my boss allowed him to get a better picture of what I was doing on a daily basis as well as pointing out some of the areas that may need to be handled until a replacement was found.
Write down your current password. Change it. Now, write down the new password and give it to your boss (you don’t have to do that right now – just put it on top of the pile of things you’ll be handing over shortly). Granted, they probably will change it the minute you’re out the door but this way, it’s their choice. Ours is a small shop so we often install things ourselves on the servers. In doing so, I have been known on (rare) occasion to use my account in setting up a dev server or install a service on said server. By changing the password now, I’ll hopefully see something that might not have cropped up until after I was gone.
For some folks this is as simple as packing up your LOTR action figures or your various schwag items but for some this can be a little more trouble. As a general rule, if you’re not sure if you should take it with you – you probably shouldn’t.
Personally, I’d recommend slowly moving your stuff home a little at a time rather than showing up with the U-Haul on the last day – especially if, like me, you’ve had a bit of time for things to accumulate. Start off with your filing cabinet – pull any personal folders and take those home first. Next should be books and binders. Finally, you should focus on the files on your machine.
There are 3 things to remember while in your exit interview:
- Shut up
- Shut up
- Shut up
We don’t have exit interviews at Alt-N so I haven’t had to deal with this but this also applies to talking with co-workers. What makes you think that you can fix, on your way out the door, what you couldn’t while you were there? Stay positive in everything you have to say about everyone. There is no valid reason for burning bridges in my opinion.
Scott Hanselman recently left Corellian for Microsoft and has a great post on cleaning up before leaving. I especially likes the parts about removing the personal aspects on your machines. Yeah, they may pave the machine anyway but at least you did your part to make it possible for them to hand it off to the next guy.
The single best piece of advice I have is to COMMUNICATE. Whatever it is you’re doing, talk about it. Tell your boss, tell your co-workers, tell whomever you think might need to know later. It’s better to tell too many folks than not enough because if you don’t, you’ll be gone and they’ll be stuck. With just a few thoughtful things and a little effort, you will make the transition easier for everyone and show them what a professional you are.
I seem to reach a point at which I feel a driving need to change tools. First it was from paper to My Life Organized; then it was MLO to MonkeyGTD; now it’s MonkeyGTD to something else. Why do I feel the need to reboot my system?? Is it a symptom of not keeping things “squeaky clean” or just “tool-itis”?? Obviously if I’m rebuilding my system on a regular basis, I’m not getting things done so how do I stop this madness??
I know that there’s a tipping point which I must pass in order to really “get” GTD and most folks say it’s just time in the system as a whole but I’m beginning to wonder if system hopping is the same as pressing a reset button for myself.
Why is it that programs assume that they know best for you and don’t honor your requests?? When I installed Adobe CS2 (great software BTW), I also got Acrobat 7.0 installed. I’m not all that thrilled about the PDF in general but they do make reading a big document a little easier. And they are the de facto standard when it comes to whitepapers, something I read a TON of, so I’ve learned to live with them. What I can’t live with is the fact that they add all kinds of garbage to all my applications. The toolbars in Word are nasty enough with Adobe throwing a bunch of extra crap in there that I’ll never use. I don’t need a top-level menu item to generate or comment on a PDF. To make matters worse, when I hide the toolbar it simply reappears (seems to happen when the window loses focus and then regains it). GAAHH!!
UPDATE: You’ll also want to set AttachmentsOption to 0 in the Settings for Outlook. This will get rid of it in the Compose a New Email. (Thanks Trint for catching this one.)
I googled around for a solution but nothing was forthcoming so I attempted to edit my “normal.dot”. Nothing. Enter the registry hack.
** DISCLAIMER: DO NOT EDIT YOUR REGISTRY IF YOU DON’T KNOW WHAT YOU’RE DOING **
In HKEY_CURRENT_USER\Software\Adobe\Acrobat\PDFMaker\7.0, there is a list of apps that it
hooks onto like a life sucking leech attaches to. Each app is it’s own directory and has a sub-directory called Settings (e.g. Word | Settings) which contains a REG_BINARY key called ToolBarVisible. Delete this key and start the application in question. When you remove the toolbar, it should stay gone. Not sure why it won’t honor this normally but this was the only way that I could get my system to stop re-adding the toolbar – at least for the moment. 🙂