Epistemic Status: Reference
A while ago, I read the book Getting Things Done. Like most productivity books and systems, it includes detailed advice that approximately no one will follow. Unlike most productivity books and systems, it has two highly valuable key concepts. The second alone justified the time cost of reading the book. That principles are these:
Keep a record of tasks you’ve decided to do.
If you decide to eventually do a task that requires less than two minutes to do, that can efficiently be done right now, do it right now.
This wording is a refinement of the original concept of applying the two-minute rule during ‘processing time’ only. I think it’s much better to use it any time doing the new task can be done efficiently – it’s not waiting on anything, you have the necessary tools, it wouldn’t interfere too much with your state, with a key short-term deadline, or the need to protect a large or important block of time, etc etc.
Having this simple concept in your head – it’s better, once you notice something that you need to do, to just do it now rather than add it to your stack of things to do – has saved me far more trouble than one might expect.
Two minutes is a placeholder. Some people should use a lower or more often higher time threshold. The threshold should be adjusted based on the situation.
The book also contains a detailed method of how to create and maintain the list of tasks. It seemed annoying and overly complex and not suited to the way I think, and I never gave it a real try. The basic principle of ‘have a system that ensures such tasks are not forgotten’ still seems very strong.
The principle remains, and can be usefully extended further, which I plan to do in additional posts. But better to, by its own principles, write and get this posted now, so I can refer back to it.
Don't Worry About the Vase 
A principle I’ve found useful: never over-engineer the todo process. My reasoning is that if I’m potentially lazy about getting a task done, then I’m going to be even lazier about the meta-task of getting the task done. So if I can get a task done in under 2 minutes, great. If not, my todo items, in increasing levels of process are:
* In my head
* In a line in a text file
* In a row in a spreadsheet
So for a small, fun project, it can all be in my head.
As the project gets larger, it will inevitably contain miscellaneous and not so fun details: these can go in a text file.
If the project gets even larger (> 3 weeks work) I’ll set up a google sheet. This is also obviously very useful when working with others.
When a TODO row in a spreadsheet gets done, there are also increasing levels of process:
* Small project: status changed to DONE
* Medium project: status changed to DONE and moved down sheet
* Large project: status changed to DONE and moved to different sheet
Or to put in another way, my todo process is maximally ad hoc. Any additional process has to pay its rent, by saving me time & reducing mental clutter. I think this is the reason why the enormous number of scheduling tools fail to beat a text file let alone a spreadsheet. A lack of familiarity & universality aside, they over-engineer the todo process, serving as a tax or even a straightjacket to a simpler ad hoc approach.
P.S. Let me know where the “Refine covid mortality calculations” TODO item resides :)
My idea for maintaining a list, which I admit I haven’t tried, is to write a program which suggests things from the task list quasi-randomly. No reminders or deadlines or ceremony, just a bit of sorting where things which haven’t been touched in a while float to the top of the queue.
I haven’t read the book in a while, but I’m reasonably sure it (repeatedly) advises one to develop one’s own idiosyncratic “detailed method”. I did, somewhat briefly, try something pretty close to what is detailed in the book, but have since developed something I like much better.
I agree that the ‘do it now’ principle, and your generalization of it described here, is a very important component.
Three other pieces I’ve found to be personally very helpful:
– Calendar
– Reminders
– Project tracking
Like the task list, a calendar is much more useful if it’s comprehensive. One also has to review it regularly, e.g. every day. I look at mine in the morning.
I’ve found reminders to be extremely helpful for all of the tasks that I either can’t or don’t want to do now. Storing these tasks in a separate system that I trust will show them to me some time in the future has been much more helpful than keeping them in my ‘active’ task/to-do list.
I use GitLab for project tracking and create issues for each project. For big or long-duration projects, I might create multiple issues, in a loose ‘tree’. I keep a big { task list / outline } in the description. I try to maintain a rough history of thoughts, activity, and reference info in the comments. I link the relevant tasks in my task list to the GitLab issues. It’s really helpful for me to be able to maintain the state of projects outside of my task list, and to be able to keep only the ‘next action’ task for each project in my task list too.