GTD (Getting things done)

From Pexels

David Allen the consultant and author (sadly not Dave Allen the comedian) promotes a management system in his book “Getting Things Done: The Art of Stress Free Productivity”. In my opinion, there are two key features to this system. The first is learning to use a tracking system rather than carrying things in your head. The second is taking the time to review, prioritize and delete actions from this tracking system. So it isn’t just writing to-do lists because, because once you trust the process you don’t look at the to-do list - you only need to look at your schedule for a day. Less stress and worry, focus on finding flow for what is in front of you. If you trust your scheduling abilities, the only stress comes when you do your regular review, and delete, reschedule or add work to the system. There are some obvious overlaps with Agile and Waterfall, and it is no accident that Emacs has back-ends that allow org-mode to integrate with GitHub, BitBucket and GitLab to support a “Getting Things Done” workflow. And indeed, “Getting Things Done” encourages you in the review sessions to focus on what get a task done rather than adding tasks because you wish to enter a Stakhanovite competition for the world’s longest to-do list. “Getting Things Done” is sufficiently well established that there are numerous smartphone apps, such as “Don’t Forget the Milk” which go some way towards implementing it.

However, to my mind there are some real bonus features you get when using Emacs org-mode to manage “Getting Things Done”. The first is time tracking. You can estimate the effort needed to complete a task, and clocking into a task is as simple as ctrl-x-i while clocking out is ctrl-x-o. This means as well as effort estimates, you can actually record the time spent on a task. I haven’t been quite so particular about this, but it is noticeable that the time tracking element certainly translated from Emacs to BitBucket if using Emacs org-mode to manage BitBucket tickets locally. I still find accurate time estimation difficult, and find it useful to be able to have a reasonably accurate measure of the time I have spent on tasks.

The one aspect I’m currently finding more difficult in “Getting Things Done” is that ad hoc tasks are now a more substantial part of my job. So this blog post will be rewritten over time as I get more comfortable developing a set of useful capture templates. The first things with any ad hoc activity I hit ctrl-c c which automatically clocks me into the capture task until I hit ctrl-c ctrl-c which takes the clock back to whatever I was doing before. So I have minimal administrative (time recording) interruptions to my original task, I just beam back when finished. The entry that I generate for this spontaneous ad hoc activity is stored in a dedicated file.

setq org-default-notes-file "~/.gtd/refile.org")
(setq org-capture-templates
      (quote (("r" "respond" entry (file "~/git/org/refile.org")
               "* NEXT Respond to %:from on %:subject\nSCHEDULED: %t\n%U\n%a\n" :clock-in t :clock-resume t :immediate-finish t)
              ("m" "Meeting" entry (file "~/git/org/refile.org")
               "* MEETING with %? :MEETING:\n%U" :clock-in t :clock-resume t)
              ("p" "Phone call" entry (file "~/git/org/refile.org")
               "* PHONE %? :PHONE:\n%U" :clock-in t :clock-resume t))))

If I wish to have a holistic understanding of where my work time goes, I will next need to set up some refile mechanism to move activities from this refile.org into more relevant files. At the moment, I’m guessing that these spontaneous activities will cost little time and I won’t wish to spend any more time categorizing them. But if particular patterns emerge, I will need to look into how refile works in org-mode. Again, this is largely about planning. Instead of trying to write a comprehensive scheduler, I can leave some carefully chosen generic templates and trust that my capture system will record enough information to be useful.