Getting things done after Getting Things Done
I first looked into Getting Things Done my first year out of university. Though I suppose having some sense of personal organization and time management would have been nice to have in the seventeen years of study prior, my new state as an employee sent me searching for something more than excuses and a general habit of procrastination.
I'm the kind of person who visits a bookstore just to hang out. (If I ever conquer my own commercialism I'll hopefully transform into a library patron.) It was at one of my many trips to the local Barnes & Noble that I saw a copy of David Allen's book. Though I had heard of the book before, but the simple cover, pleasing proportions, and unassuming title shone through my initial cynicism. I picked up paperback, and made short order.
Soon my life was awash in contexts… lists… habits… projects… actions. I had a little paper notebook that contained everything I needed to not have to remember; I had 43 folders in my desk and in my reader, and even more manilla in a box full of files; I had an other box full of "stuff" that kept the stuff out of sight; and I was trying (mostly failing) to have weekly reviews about what I had done, what I was doing, and what I needed to do next.
This actually worked pretty well. I spent less time worrying about forgetting things, because if I needed to remember it, I just wrote it down. I spent less time trying to spin up to productivity because I already had "next actions" for all of my "projects."
I even had an empty email inbox.
…but all of this new headroom gave me the freedom to notice seams between David Allen's proposed system and my own requirements. First was in the sense of contexts: though, in a corporate office, simple things like "@phone" or "@desk" or "@home" effectively partition a task space into appreciable chunks, I work in computers. The vast majority of my tasks are "@computer" or, at the very most, "@Internet." That doesn't do much to calm the mind when you're staring at a long to–do list.
I liked the ubiquity and tactility of paper, but the medium has its faults. Completed tasks clutter up the page, and to clear them you have to transcribe any remaining items to a new page. Reorganizing items into different contexts bring the same problem. There's no way to archive (let alone audit) task history without even more transcription, since tasks for different projects are physically intermingled. Most damningly, separating tasks from the notes that go with them is both a mental and physical context–switch that plagues every non-trivial task.
For its faults, GTD had actually taught me a lot of really good lessons:
The brain is way better at thinking than remembering.
The less you have to remember, the more you can think.
The more you need to think, the less you want to think.
Don't waste time making the same decision twice.
Lists add a sense of progression to otherwise intangible work.
There is too much to do to consider all at once.
All existing GTD software was powerless to placate a sysadmin's sensibilities. It's all point–and–clicky, high–friction, and, worst case, web-based. I did the only thing I could do: I moved all my lists to text files, added one project ("write command-line GTD software" and one action ("brainstorm requirements for GTD software").
That project didn't go so well; but it's ok, because since then I've migrated to Emacs Org-Mode.
Rather than being a software environment that I had to re–factor my workflow into, Org–Mode provides a rich set of (extensible and seemingly–infinitely–configurable) functions to manipulate my text lists–cum–text–files as I see fit. All of that on top of a mature <strike>text editor</strike>lisp runtime (albeit one with which I had no experience).
First off, I configured Org–Mode with some familiar list item types:
(setq org-todo-keywords '((type "ACTION(a!)" "|" "DONE(d!)") (type "PROJECT(p!)" "|" "DONE(d!)") (type "WAITING(w!)" "|" "DONE(d!)") (type "SOMEDAY(s)" "MAYBE(m)" "|") (type "|" "DELEGATED(g@)" "CANCELLED(x@)")))
…then configured some simple logging:
(setq org-log-into-drawer t) (setq org-log-reschedule 'note) (setq org-log-redeadline t) (setq org-log-done 'time)
Suddenly my lists grew automatic logging in the form of the LOGBOOK drawer:
* PROJECT make a new first post on civilfritz :LOGBOOK: - State "PROJECT" from "" [2011-08-15 Mon 21:04] :END: ** DONE figure out the post sorting problem CLOSED: [2011-08-16 Tue 20:35] :LOGBOOK: - State "DONE" from "PROJECT" [2011-08-16 Tue 20:35] - State "PROJECT" from "ACTION" [2011-08-16 Tue 08:04] - State "ACTION" from "" [2011-08-15 Mon 22:31] :END: ** ACTION write about getting things done after getting things done SCHEDULED: <2011-08-16 Tue> :LOGBOOK: - State "ACTION" from "" [2011-08-16 Tue 21:09] :END:
Of course, that's a lot of clutter, too; but that's just what's physically stored in the file. Org–Mode provides a flexible view of the outline. For example:
* PROJECT make a new first post on civilfritz :LOGBOOK:... * DONE figure out the post sorting problem... * ACTION write about getting things done after getting things done SCHEDULED: <2011-08-16 Tue> :LOGBOOK:...
That's much easier to look at. In Emacs, color is used to make the content even clearer.
As simple as these little bits of text are, the triviality of their automation means that they can be parsed by other parts of Org–Mode. Most notably, by the agenda.
(defun org-find-agenda-files () (find-lisp-find-files "~/agenda" "\.org$")) (setq org-agenda-files (org-find-agenda-files)) (setq org-agenda-start-on-weekday 6) (setq org-agenda-skip-scheduled-if-done t) (setq org-agenda-skip-deadline-if-done t) (setq org-agenda-custom-commands '(("S" "Unscheduled actions" tags-todo "TODO=\"ACTION\"+SCHEDULED=\"\"") ("D" "Undefined deadlines" tags-todo "TODO=\"WAITING\"+DEADLINE=\"\""))) (setq org-stuck-projects '("TODO=\"PROJECT\"" ("ACTION" "WAITING") nil nil))
The agenda serves the same function as the context "next action" lists from GTD; except where contexts are static, the agenda is dynamic, built on-demand and filtered by arbitrary tags (which replace contexts themselves). Further, the "stuck projects," "unscheduled actions," and "undefined deadlines" lists make it easy to find orphaned tasks (now a part of my weekly review).
* ACTION [#A] weekly review :work:home: SCHEDULED: <2011-08-20 Sat ++1w> :LOGBOOK:... :PROPERTIES:... - Review stuck projects (C-c a #) - Review unscheduled tasks to be done this week. (C-c a S) - Review waiting items with no specified deadlines. (C-c a D) - Review someday/maybe items. (C-c a t 5 r, C-c a t 6 r) - Review the past week's accomplishments. (C-c a a l v w b) - Review the upcomming week's actions. (C-c a a v w)
All of the historical logbook data is pulled together in the global logbook view, which I can now inspect separately (again, as part of my weekly review).
I use Org–Mode to record virtually everything that I do or need to do, either at work or at home. It really has become my post-GTD, and I have yet to find a requirement that surpasses it. On the contrary, I often find new solutions just as streamlining reveals deeper bottlenecks.
I'll post more of my .emacs and workflow in the future, I'm
sure. Until then, feel free to send any questions or comments my way.