Getting Things Done for Hackers
Getting Things Done, or GTD, is a personal productivity system originally developed by David Allen, and now maintained by the company he founded. In 2001 Allen published a book, also called “Getting Things Done”, to describe the system, and it was an Internet sensation, enough to be called a cult.
This document is a description of my personal implementation of GTD, based on the books by Allen, and tons of online discussions. If it helps the reader, great, but I primarily write this to clarify my own thinking.
The GTD system is one of many. Other well known ones include the Bullet journal, Inbox Zero (“GTD, but for email only”), and Zettelkasten (good for researchers). It doesn’t matter what system you use, or that you use any system. The only thing that matters is that you’re happy. For me, GTD helps.
I started using GTD in the summer of 2006, while I was working as an independent consultant, and found it hard to keep the commitments I’d made to others, and do all the things I needed to do to run my business. I would sometimes wake up in the middle of the night in panic, wondering if I’d paid this bill or done that thing a customer had requested. I felt that I was juggling too many eggs, and that the floor was getting messy.
After doing some research online, I happened to find out about GTD. I read more, including the first edition of the book. I hesitated a little, it seemed like a lot of work, but I took the plunge and started implementing it for my life. It has been worth it.
To be honest, applying GTD to your life is indeed quite a bit of work. Less than I feared, but it does require an effort to get started, and to keep it up, but it has helped me get my life under control. I haven’t woken up in panic thinking I’d forgotten to do something important any more.
Will GTD make your life better? Maybe. It might not. You know yourself and your life better than I do, and it’s your decision to make. You won’t lose much if you try, though.
Productivity is whatever you say it is. GTD is a personal system, after all. You decide.
For me, to be productive means that I do all the things I need to do to feel happy, satisfied, and fulfilled, and to achieve my personal and professional goals. That’s very wishy-washy, but let me break it down in concrete statements:
That’s my list. Yours might be different. You might not care about productivity at work. You might measure everything using money. Your decision. Whatever you decide is OK.
To me, being productive is important because it helps me be happy. For me, work is a big part of my life, and so “being productive at work” is important to me. Again, you might be different, and that’s OK.
An important measure of being productive, for me, and being in control of my life and commitments, is how easy it is for me to not do things, and feel OK about that. Can I drop everything and go for a walk? Can I go have lunch or dinner or watch a movie with my wife? I can do those things when I know what I’ve committed to and what I need in the near future. If I’m very tired during the day, I take a nap, because it helps me be more awake later, but I sleep better if I worry less.
I feel most productive when I can just do the things. In online discussions, this is sometimes described as “cranking the widget”. I know what I need to do, and I know how to do it, and I merely need to do it. It might be writing a code module, writing a section in an outline for a document, or filling the dishwasher.
I find that one of the things I get from GTD is the idea of separating the planning from the doing. First I plan: “I need to write this program, what does it need to do exactly? What’s the next concrete thing I can do to make that happen?” Later, when I’m ready to actually start doing, I do the concrete thing, whatever it happens to be. By separating the planning and the doing I can concentrate on one thing at a time. I don’t need to think about, or worry, about all the other things I could be doing. This helps me concentrate, and if I can concentrate on only the one thing at hand, I get it done faster, with less total effort, and with fewer errors.
If I feel like watching a movie, instead, I know what I need to get done in the near future, and if there’s nothing urgent, I can immerse myself in the movie. That, too, is easier if I don’t need to worry about other things.
This is the shortest summary of GTD I have come up with:
Of these, the review is probably the most important part. It’s what keeps the system together. I certainly am not diligent and disciplined enough to get every detail right every time. Things fall through cracks, and a review (I do it about weekly) helps me find things, and also to patch up cracks that things fall into often.
In this chapter I describe the basics of the GTD system in enough detail that if you want to implement it for yourself, you can start doing that.
The core elements of GTD are:
I won’t go into detail on how to discard things, as I’m certain you know about that already. From a GTD point of view, the only important aspect is that you actually remove from your life things that you don’t need or want to store.
The core lists in GTD are:
You can implement the lists in whatever way you like. I use text files in git. Actually they’re markdown, so that ikiwiki can render a web site from them, but that’s not actually important. You can use pen and paper, a generic list management application, a GTD application specifically, a ticketing system, a whiteboard. Whatever works for you is fine.
An inbox is where incoming things land. An email mailbox where new mail arrives automatically is a prime example. You can also have a physical box where you dump snail mail, or anything someone hands you, or post-its you write to remember to do something.
Not everything has to go into an inbox. Sometimes things are urgent, or you have the time and energy to deal with them immediately, and you can just deal with them as they arrive. If there’s a fire in the kitchen, you deal with that immediately. If someone asks you what time it is, you answer at once. If you get offered a cup of tea, you either drink it then, or refuse it. There’s no point in putting a cup of tea in an inbox to be processed a few days later.
I process items in an inbox several times a day (email), once a day (snail mail), or when I do my GTD review (most things). I sometimes process just one or two items, when that’s all I have time for.
In online discussions, some people are quite strict about inbox processing. They may say that you have to always process everything in an inbox, and you must do it every day. I have not found it necessary, or useful, to be that strict. Whatever works for you is fine.
I have a bunch of inboxes.
inbox.mdwnThe exact list is not important here, but I do need to make sure I remember to check all of them. It’s OK to have many inboxes, as long as you know what they are.
I treat ticketing systems as inboxes. I check all open tickets from time to time, to see if there have been any changes, and I treat each change as being in an inbox. This is, of course, easier for systems that send me email, but it’s workable for any ticketing system.
Sometimes an open ticket not having changed is something I need to do
something about. That’s usually obvious when I review the ticket, and
then I add the thing I need to do to inbox.mdwn, to be
processed later. Or I add a reference to the ticket to the inbox, if I
need to think about what to do. I capture the need to do something in my
system.
From a life management point of view, it’s important to realize that an inbox is not permission for others to tell you what to do. If it’s your employer, or your spouse, they may have that power, but in general, anything that lands in your inbox is best treated as a suggestion that you consider if something needs to be done.
Even that can be too much. If you, say, have an open source project with many users, they may each separately feel they have a right to ask you do consider something. If that happens rarely, that’s fine. If you get many such requests a day, the cumulative load on you is excessive. It’s OK to filter what gets into your inbox, in whatever way works for you. Maybe an email filter, or a trusted party. Your time and your attention are yours, and you should decide how you spend them. Arrange things so that you are in control.
When I’ve decided that I will do something, but can’t do it at once, because it takes too long, I add it to the list of next actions. Later, when I’m actually doing things, I pick a item from the list, and do that.
For this to work well, I describe the action in sufficient detail that I remember everything relevant, possibly days later. I find it helps to write the next action for a future me who has just returned from a short, but extremely exciting adventure, and needs a little help to remember the mundane aspects of my life. I don’t need to write an essay, but I do include enough context to trigger my brain to remember the rest.
I also find it helps me do things if I write a sentence that starts with a verb representing a concrete physical action, but also only describes how to start doing, rather than describing a complete, polished, perfect end result. Perfection is scary and de-motivating.
Good examples:
I find that an action needs to be possible to complete in one sitting. Thus, “write a novel” is way too big, but “draft a list of five ideas for names for characters in a novel” is fine.
It’s also necessary for me that a next action is ready to be done. It can’t depend on something else that needs to happen first. I can’t format a new hard drive until I’ve bought it, and I can’t buy it until I’ve researched current hard drive reliability statistics. The first action is to find those statistics.
I use the following check list to make sure my next actions are well formed:
A list of next actions can be as short or long as you like. I find it works best for me if it’s long enough to have at least one item for each active project, but short enough that it’s easy to pick something to do. By the time I need to use regexps to search for something, I’ve gone overboard.
In practice, less than one hundred items works for me, but less than twenty is better. A list longer than about ten is long enough that I tend to want break it into sub-lists, to make it easier to navigate. In GTD parlance this means assigning next actions into contexts. The original David Allen GTD book has contexts such as “at phone” and “at computer”, which make no sense to me. That was a simpler time.
You can use whatever contexts you like, and you can vary them as needed. Some of the contexts I use include “working”, “hobby time”, “out and about, running errands”, “home alone”, and “zombie”. The “home alone” context is for doing things to our home network, or home servers, when my wife’s work isn’t disturbed by me, say, reinstalling the home router. The zombie context is for when I don’t need to be particularly awake or alert or able to think clearly, but need to do things like taking out the trash, doing dishes or laundry, or checking my spam folder for legitimate mails.
One extra context I have is “started” for things that take a long time. As an example, “run the automated test suite 1000 times in a row” might take all day, but not require my attention except to occasionally check the test suite is still running.
In GTD, a project is anything that requires more than one action to achieve, but is very likely possible to finish in less than 12 months. This is a simple, clear definition, and usually meshes well with other contexts.
I find it useful to describe a project goal by starting it with “when this is done” and describing the world after the project has ended. I have learned, from others and from my own experience, that this aligns my brain to think about the project end goal, rather than the process of getting there.
I further find it useful to describe acceptance criteria for deciding that the project is finished. This is the difference between “stay at my mother-in-law’s overnight” and “drive north for six hours, then take a left, and knock on the door”. By concentrating on “what”, it’s easier to re-think the “how” when something doesn’t go as planned.
Example:
When this is done: I have written a novel, and at least three of my close friends have read it and not suggested character or plot changes.
When planning what to actually do to advance a project, to choose next actions, I find it useful to think about the next few steps only. These are usually fairly obvious, but that depends on the project. A project to buy a new hard drive is easy; a project to construct a new Zeppelin is not. The harder a project is, the more things it contains that you’ve never done before, the more careful planning of each action, and the route to the end, needs to be.
For projects requiring specialist knowledge, consult specialists.
Also remember that when you set a goal for yourself, you get to adjust it as you like along the way. Maybe a goal to write a novel turns into a producing a play. That’s allowed.
I add an item to my “waiting for” list when I ask someone else to do something. I also add to the list when I’m expecting something to happen. I have two “waiting for” lists: one is a markdown file, the other is an email folder. When I order something online, to be delivered, I move the order confirmation email in my “waiting for” folder. This makes it easy to check that it actually arrives.
Effectively delegating tasks to others requires keeping track of what, to whom, and checking that they do them. Even the most competent people can misunderstand what is requested, or make mistakes, take longer than intended, fall ill, or suffer from the loss of a loved one. Checking on progress helps everyone collaborate better: if the task turns out to be too big, help can be recruited; if someone is ill, a substitute can be arranged.
This turns out to be particularly effective when you delegate upward in a hierarchy, by asking your manager to do something. Managers, too, appreciate help in remembering their commitments, as long as it’s done politely.
I have many things I may want to do, but not right now. So many things. For example, I might want to learn French some day, or write a novel, or visit Guédelon. Some of these are so desirable to me that I’m unlikely to ever forget, but for most things, it helps to write them in their own list, the “someday/maybe” list.
The “someday/maybe” list can be just a wish list. It can also contain things others have asked you to do, when you have time. It can contain things that someone has hinted they’d really like to get as a gift. Mine also has ideas for programs I might want to write, or features to add to existing programs.
This list runs the risk of growing too large. At its largest mine
grew to over 7000 items. grep is helped, but that’s too
large to be useful. (“Learn French” was there three times.) I find it
helpful to trim it down if it grows too large. Trimming is helpful not
just to make it easier to find anything, or to get rid of duplicates,
but also because the longer the list is, the heavier a psychological
weight it is. After all, learning every language and visiting every
castle in France is quite a long list, and not likely to ever shorten
much. It might be freeing to have just one language and one castle.
Things that should happen on a particular day, or at a particular time on that day, go into a calendar. Calendars are a magnificent invention to help ensure you don’t commit to doing two things at the same time. (Calendar software is a manifestation of an elder evil who sucks your soul dry.)
You can use calendar software, or a paper calendar, a handwritten list, or whatever works for you.
I used to live a very simple life, with few time based commitments. I kept everything in my head, except birthdays. This ended when I started having meetings or other interactions at work. I cannot recommend ending up in a situation where you have to explain that you forgot a meeting, or remembered its time wrong.
Inevitably, I need to keep, and retrieve, documents for a long time: receipts, invoices, contracts, pay slips, manuals, etc. Some of these have an expiry date, but it might be far in the future. Anything tax related I need to keep for about a decade. A manual I need only as long as I have the hardware.
Filing systems are traditionally an area where many geeks who start using GTD go overboard. Hanging folders? Manila folders? What size? Filing cabinets? Archival document boxes? Label makers? Alphabetical or date order, or some classification system? The possibilities are endless.
I keep my paper filing system simple. I have a few archival boxes
that I label with the kind of document they contain. I use a label
maker, because my handwriting is illegible. For digital files, I have a
folder Archive2 where each file is named with an ISO 8601
date, and some keywords to hint at the contents. (It’s
Archive2, because the original, Archive,
turned out to be hard to organize. It had an intricate sub-folder
structure.)
Once again, whatever works for you is fine. Start simple, and when your GTD system is working otherwise, if you feel like it, spend the necessary effort to implement the perfect filing system. Make Miss Lemon proud.
It’s awkward and tiresome to fetch documents from the main filing system, and return them, for things you need often because they’re relevant to your active projects. I have a separate stash for such documents, which I call “pending and support”. I have an email folder with that name, and I use my work desk surface for physical documents, and my home directory for digital files. It’s messy, but it works for me.
For me, clearly the most important, the most energizing, the most meta-productive part of using GTD is the review. I try to do one every week, but that varies. If I skip the review for a month I get angst, and have difficulty concentrating. My brain loses all confidence that I can support it by keeping track of things externally and tries to remember everything without help.
The purpose of the review is to make sure I haven’t forgotten to process any inbox items, that I’ve made progress on all projects, and that I have a clear set of things I can do in the near future. In short, that everything is in order, and nothing is neglected. The review is also a time of contemplation, thinking, planning, and envisioning a bright future.
Doing a review tends to calm my subconscious, and make me feel energetic. If I do my review in the morning, I am often in my most productive mode the rest of that day. This is why I avoid doing it on, say, a Friday evening, as the temporary energy boost would be lost while I sleep.
My review sometimes takes many hours, but I tend to take breaks to have tea on the balcony with my wife, and do other important and urgent things. If I’m feeling it is urgent, I can usually do a reasonably thorough review in a couple of hours if it’s not been more than a couple of weeks since the previous one.
My checklist for conducting a GTD review is (“iteration” is the interval between reviews):
This isn’t the perfect review process, but it works well enough for me.
The full GTD system described by David Allen covers life management at higher levels than the mundane “do these things to achieve these goals”. I’m not describing the higher levels in detail, but in short:
These make sense to review annually. However, you should probably not worry about these until your everyday is under control.
The second edition of Allen’s GTD book describes these better than the first one.
Here I give some advice about implementing a GTD system.
Finally, productivity hacking your life, and improving your GTD system, is a fun hobby. It does not seem to be a way to be significantly more productive, and it can prevent you from having tea on the balcony. I recommend only hacking your life for increased productivity when it improves your life.
Below is an image of my first inbox, when I first started implementing a GTD system for myself.
Thank you to Greg Grossmeier, Heiko Schäfer, and CloudyFrankfurt for feedback on this document.
Copyright 2023 Lars Wirzenius
This text is released under the Creative Commons CC BY-SA 4.0 International license.
You can contact Lars via https://liw.fi.