As we’ve noted before, GTD contexts lose a lot of their focusing power when either a) most of your work takes place at one context (e.g. “@computer”), or b) you start using contexts more for taxonomical labeling than to reflect functional limitations and opportunities. As you may have discovered, these problems can collide catastrophically for many knowledge workers, artists, and geeks.

Part of what makes the Natural Planning Model so attractive are the decisions that can be guided by contextual limitations (“I’m near a phone” vs. “I’m at the grocery store” vs. “I’m at my computer”). While it’s definitely a kind of “first world problem” to have, facing the unlimited freedom to chose from any of a bajillion similar tasks from similar projects with similar outcomes is not nearly as fun as it first sounds. Consider the contextual hairballs of certain jobs and tasks:

• Developer - Much of the work is writing new code, fixing old code, or testing code. All of these require essentially the same tools and environment, so how do you apply real contexts?
• Writer - Needs to research, draft, revise, and edit manuscripts. While the “Write book” project will break down nicely into multiple sub-projects and tasks, how do you satisfactorily “context-ize” this physically identical work?
• Designer - Whether coming up with a print layout, web design, or what will become a physical artifact, how do you segment the work further than “@photoshop” and ”@illustrator”?

This causes many of us to fashion more or less phoney-baloney “sub-contexts” that reflect some facet of the parent (e.g. “@computer” might contain “@email,” “@web,” “@code,” “@print,” and so on). While this makes terrific sense from a logical standpoint (and it can certainly have its uses), it doesn’t reflect the true meaning of a context, at least in my own mind: “what tools, resources, opportunities, and limitations are unique to this situation?” or put slightly differently from the perspective of choosing tasks at a given time, “what are the things I can’t work on now given where I am and the tools to which I have access?”

More and more, I think the solution may be to toss out or consolidate any contexts that don’t have unique functional attributes. I mean, by all means, keep them if they’re working for you, but if you find yourself spending more time deciding where to file tasks than actually completing them, you might consider dialing your contexts back as far as you can stand. For the geeks in particular, consider having two and only two computer-related contexts: “@online” and “@computer-anywhere.” If you have other contextual needs, add them in with care, then periodically revisit to make sure you aren’t maintaining superfluous parts.

If you feel a gnaw about the loss of your old contexts, try to shunt some of the mental load into sub-projects and better verb choices in your tasks. Where you once had (as I did) an “@print” context, consider whether an “@computer” task of “Print Jim’s email” might be sufficient for the job. Remember, maintaining fewer buckets is always a good thing.

As you doubtless have learned, this is ultimately all about choosing valuable work and then tracking it as simply as possible via carefully-worded task reminders. No amount of meta-crap can magically transform junk tasks into stuff you really want or need to do. Contexts can help shape your day, but they’re less than useful if they don’t track realistically to the demands of your work.