I use the David Allen Getting Things Done system (GTD for short) to cope with all the many, conflicting, things the world throws at me. I find it especially useful to know when I can not do anything without being in trouble later. (I’ve written about my implementation of GTD here.)

Even so, I like to be able to do many things so that I can feel I’ve made the world a better place. My main obstacle is that my brain is a lazy, scheming bastard that will try to get away with doing less than I need or want it to do. Over time, I’ve learned some tricks which I use to con my brain into actually getting the right things done.

When I plan a project, I write down a description of what the world is like once the project is done: “when this is done, I am very confident that my desktop computer is fully backed up and I verify that by restoring the data monthly”. I don’t phrase the goal as a task (“set up backups”), because my brain is maliciously lazy, and will try to interpret any task in as minimal a way as possible. When I describe a desired state of the world, my brain doesn’t find as many loopholes. This simple trick lets me complete more things to my satisfaction.

When I do write down individual tasks, I write down actions in as much detail as I will understand them later, when my brain is tired and cranky. This way, when it’s time to do the task, I don’t need to think about what needs to done or how to do it, I can just do. Thus, I write “install this backup program and run an initial backup to home file server over SSH”, instead of “set up some backup program and try it out”. If I need to first do some research before I can choose a backup program to install, that’s a separate task. Not having to think makes it easier to do. I also try to plan tasks so that they are very concrete, physical actions and as short as I can reasonably make them. Thus, I might actually have a task to just “install this program from the package in Debian”, as that’s a single command. It’s easier to start doing a task that I can expect to only take me minutes than one that will take an hour. Otherwise my brain will say “this is going to take a long time, so it doesn’t matter if I start a bit later”.

A related aspect is that I try to phrase things in a way to make it as easy for my little brain to cope. As an example, when keeping track of issues in my software, I try to report the issue, not the task or the steps to take to fix the issue. Thus, the issue is “backups aren’t encrypted” instead of “implement encrypted backups”. This is not just easier to understand, but also means that when it’s time to evaluate if a ticket can be closed, I evaluate if the actual issue is solved, not whether the task initially written down as a solution is finished. Sometimes the task is incomplete, or entirely wrong. I find I achieve better results if I don’t start planning work when reporting an issue.

Whatever I write down, I assume that future me has a brain that’s been affected by the kind of mild memory loss brought on by debugging late into the night, excessive tea drinking, and other such vices. Thus, I try to include sufficient context and supporting information in an issue or task, rather than writing down just enough to trigger a recall of the salient information. In short, I’m writing for a future me that only has the memories of yesterday’s me.

None of this is works all the time. Sometimes my brain is alert enough to realize that I’m trying to trick it to do thing in the future, and sabotages my best efforts. But my tricks work well enough that some of the time I can actually complete things and that’s enough for me.