There’s an obvious productivity pattern to note:

1. Figure out what needs to be done.
2. Figure out what, of that list, can be done.
3. Do the things that can be done. Repeat.

As I think about this stuff, it’s clear to me that there are best practices (“adopt tools mindfully”), tips (“keep paper nearby”), great ideas (“capture ubiquitously”), and sound advice (“value time in every way”) — so far I’m struggling to munge them into true patterns that can be expressed in something like this:

IF you find yourself in CONTEXT
for example EXAMPLES, with PROBLEM,
entailing FORCES

THEN for some REASONS,
apply DESIGN FORM AND/OR RULE
to construct SOLUTION
leading to NEW CONTEXT and OTHER PATTERNS

I could see a few dozen of those being a great repository for people who are curious about solving problems related to the “stuff” we talk about here.

Best of all I’d love to hook these together similar to the way chromatic has done in the XP Miniguide. Like “this tool” supports “this pattern” in solving “these sorts of problems.” I could see that being really useful. If I can just figure out what the hell I’m doing. :)

How about: SomethingInSomethingOut: If you start something new, stop with something else that consumes the same amount of time.

AvoidBadProcrastination There are three variants of procrastination, depending on what you do instead of working on something: you could work on (a) nothing, (b) something less important, or (c) something more important. That last type, I’d argue, is good procrastination. The most dangerous form of procrastination is unacknowledged type-B procrastination, because it doesn’t feel like procrastination. You’re “getting things done.” Just the wrong things.

I recently posted that I think GTD might be the “Extreme Programming” of time management (link here). Maybe there’s some overlap with the two?

Wow this stuff is really interesting to me. Perhaps the wiki could create a pattern section. I am fasciated by the 80/20 rule… the freedom of boundaries, questioning of your assumptions, multidisciplinary questions such as how is architecture, like software programming, like lifehacks, considering ALL the stakeholders, consider the entire product lifecyle especially how we get rid of things when we are done with them. The power of checklists. The power of getting clarity on the problem, the power of the first step! Wow I could go on and on. I like the idea of anti-patterns there are some things that I have not been able to make work for me like organizational metrics.

Do we have a standard for what a pattern should contain. Initial Conditions, purpose, Outcome? I am not overly familar with the pattern concept. Here is one that I call might call the “project” pattern 1) Initial State (what is, the facts, current situation) 2) Future State (Our Intention) 3) Stakeholders (Owner, sustainer, Sponsor, end user etc.) 4) Pattern or Architecture (i.e. receipe) 5) Tools 6) Judging (Monitoring/Auditing) 7) Quality Charateristic (or lack of) User friendly, good, actionable, dependable etc. I look forward to trying to contribute to the patterning effort for LifeHacks.

I think one interesting area of dealing with in the patterns might be to define what the borders of production capacity actually are (iow: What would you produce if you are ate optimal productivity). After all: you can always try to produce more, but at a certain point you might hit that borderl.. at that point you need to know that you hit the border and should not keep trying to apply new patterns.

Of course, the border itself can always be redefined by altering the parameters of the “triangle”: Time, Money, Quality. By increasing one of the first two.. or even decreasing quality demands you could still produce more. It’s also interesting to know that if you run any project, any one of these variables is interdependent (less time: either give more money, cut down on quality demands, or be screwed etc) [ I personally think quality is sacred, but that’s beside the point now ]

When creating patterns, you/we should try to stick to known theories and best practices as much as possible in my opinion

Here is a great educational link about patterns especially around the requisite components of patterns. http://www.opengroup.org/architecture/togaf8-doc/arch/p4/patterns/patterns.htm#IBM

This concept will accelerate the adoption of GTD beyond comprehension. I first read “A Pattern Language” when we were building our home in 1996; our home has dozens of the patterns from Alexander’s book… this was by accident, not design. People continually comment on how warm our house feels, they never want to leave. This comes from the patterns. The secret though, is the compression of the patterns. If you just stack up a bunch of the patterns when you build a home, and they have no continuity, no integration, then you won’t have the same look/feel—i.e. you won’t have a pattern language.

The pattern language, as explained by Alexander, has a distinct structure to it… you really need to read the book to understand this.

Here’s the kicker. The patterns are instinctive, at least for those who have traveled more than a thousand miles from their home! Once you read an individual pattern, you are struck by how natural it seems.

Okay, what does this have to do with GTD? Everyone is struggling with implementation! If a pattern language could be developed, that leveraged GTD concepts, adoption would be immediate. GTD is difficult for many to implement because it does not “feel” natural. A pattern language would allow individuals to build a workable GTD model, one that fits them, and follows the basic tenets of GTD.

goeth

Here is another interesting read on patterns. http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html

[…] On a completely unrelated note, while I’m traveling, here’s an introduction (link via Merlin) to the great architect/philosopher Christopher Alexander whose A Pattern Language is one of my three or four favorite books of all time. Discussion of how his ideas relate to film to follow. In fact, hey, how about you get it started? […]