path: root/index.mdwn

[Bullet journal]: https://bulletjournal.com/
[GTD]: https://en.wikipedia.org/wiki/Getting_Things_Done
[Inbox Zero]: https://en.wikipedia.org/wiki/Merlin_Mann#Writing
[Zettelkasten]: https://en.wikipedia.org/wiki/Zettelkasten
[ikiwiki]: http://ikiwiki.info/


# Introduction

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.


# On productivity

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:

* I have written down some personal values and goals. I feel I live
  according to my values, and either reach my goals, or feel that I
  make progress on reaching them.
  - I am in a loving, caring, fulfilling, mutually supportive
    relationship with my wife.
  - I have a list of software projects that I develop and maintain as
    a hobby. I implement new features, fix bugs, publish new releases,
    etc.
  - I do things that improve the world in my opinion.
* Professionally, I make a comfortable living, and my employer or
  client is happy with what I do for them.
  - I do work that I feel is ethical, worthwhile, and meaningful.
  - I meet the goals agreed to with my employer or client.
  - I learn new things and become better at what I do, professionally.
  - I help others become better, too.

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.


# A terse summary of GTD

This is the shortest summary of GTD I have come up with:

* Messages, notifications, communications, physical things,
  interruptions, etc, that come to you, are either dealt with
  immediately, if necessary, or go into one of a defined set of
  inboxes.
* When you have time and desire, you process one or all items in one
  or all inboxes. When you process an item, you remove it from the
  inbox.
* Processing means you decide to do something about the item, discard
  it, delegate it to someone else, or defer it until later.
  * Do: whatever the item requires you to do, if it's quick, do it at
    once. I limit this to things that take at most a couple of
    minutes.
  * Defer: make a note to do whatever needs doing, somewhere you will
    check later.
  * Delegate: ask someone or something else to do it.
  * Discard: delete the email, recycle the paper, whatever is
    appropriate to remove it from your life.
* Occasionally, possibly regularly, review your entire GTD system and
  make sure everything is in good shape. This means processing
  everything in all inboxes, checking on delegated things, and
  checking your notes on deferred tasks.

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.

# GTD in more words

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:

* one or more inboxes
* several lists
* a calendar
* a filing system
* a waste basket, trash can, or recycling bin

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:

* next actions
* active projects
* what you're waiting for to happen or for someone else to do
* what you may want to do some day, but not now

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.

## Inboxes

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.

* a markdown file called `inbox.mdwn`
* a note taking application on my phone
* a couple of email accounts
* several chat systems
* notifications on social media or phone apps
* several ticketing systems
* the desk in my home office (for snail mail)
* the couch in my home office (for clean laundry to fold and put away)

The 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.

## Next actions

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:

* Draft an outline for a rewrite of "Getting Things Done for Hackers".
  - note "draft" rather than "write": a draft can be incomplete, and
    may need further work
* Write a list of at least three ideas of birthday presents for my
  wife.
  - note how three is a small number, but it's enough to get me
    started, and once I'm going, I can go on
  - also note how this is about collecting ideas, not choosing a
    present

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 _physical_ action ("write", not "think about")
    * thinking is part of planning!
    * but "draft outline of a plan for..." is an action
  * it's clear what I need to do (which widget to crank)
  * duration at most 15 minutes, preferably, or at least less than 60,
    definitely
  * I'm committed to doing it
  * does not depend on anything, can be done immediately
  * it's clear when it's done
  * it's clear which projects the action belongs to, if any

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.


## Projects

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.

## Waiting for

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.

## Some day, maybe

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](https://en.wikipedia.org/wiki/Gu%C3%A9delon_Castle). 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.


## Calendar

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.

## Filing system

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.

## Pending and support

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.

## The review

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):

  * Write a journal entry summarising the past iteration.
  * Review, and dump any thoughts into an inbox:
    - journal entries for the past iteration
    - calendar for the past iteration
    - calendar for the next month
    - waiting-for:
      - in GTD files
      - personal email
      - work email
    - pending-and-support:
      - personal email
      - work email
    - review someday/maybe
    - empty head of things: any pressing thoughts or worries that
      haven't yet been captured into the GTD system
  * Process all inboxes: do, delete, delegate, defer, discard.
  * Review projects. Make sure each has at least one next action.
  * Review next actions list. Are they all of good quality?
  * Re-process all inboxes: do, delete, delegate, defer, discard.
    - new things keep arriving

This isn't the perfect review process, but it works well enough for
me.


# Higher level GTD

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:

* what's your purpose in life? what are your principles?
  - why do you exist?
  - who are you?
* what is your vision for the medium to long term future?
  - what does success look like for you, in the long term?
* what areas of your life are you particularly focused on?
  - what parts of your life do you need to maintain, or improve, or
    pay attention to?
* what are you goals for the next year or two?
  - these generate projects, which are shorter

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.

# Advice

Here I give some advice about implementing a GTD system.

* Don't use software, or write your own software, as part of your GTD
  implementation, until after you've been doing it manually for a
  while, and have a deep understanding how you want your system to
  work.
  - I did not write two outline applications, or a ticketing system,
    or a thing to nag me about things. You can't prove I did.
  - software is usually inflexible, and a GTD system will have corner
    cases, edge cases, and special cases that require flexibility
  - start with pen and paper
  - after various other software approaches I have ended up with
    markdown files in git, edited with Emacs; this seems to be
    convenient and low-tech for me
  - git helps me keep my GTD system in sync between work and personal
    laptops, and helps guard against catastrophic editing mistakes
* It can, however, be helpful to automate aspects of your life or GTD
  system. Having recurring calendar entries is helpful. Having a
  monitoring system to remind you about inboxes you've not touched may
  be overkill.
* Use checklists for things you need to remember, or do repeatedly, or
  that you may need to do in a hurry under great stress.
* Consider building a [personal knowledge
  base](https://en.wikipedia.org/wiki/Personal_knowledge_base), or at
  least keep a journal.
* You can start big, or small. You can start applying GTD to only part
  of you life, and expand that as you get comfortable with the system.
  Or you can pile all your incomplete stuff onto a desk and let GTD
  take over your life.


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.

![My first inbox: my kitchen table](first-inbox.jpg)\ 

# Acknowledgments {.unnumbered}

Thank you to Greg Grossmeier, Heiko Schäfer, and CloudyFrankfurt for
feedback on this document.

# Copyright {.unnumbered}

Copyright 2023  Lars Wirzenius

This text is released under the [Creative Commons CC BY-SA 4.0
International](https://creativecommons.org/licenses/by-sa/4.0/)
license.

You can contact Lars via <https://liw.fi>.