How I use todo lists

By Brian Tomasik

First published: . Last nontrivial update: .

Summary

This page describes my personal approach to using todo lists to keep track of tasks, ideas, and reminders for myself.

Contents

My history

My first introduction to todo lists may have been in middle school, when students were given "assignment notebooks" in which to record the due dates of homework assignments. These notebooks were basically calendars for the school year. If I recall correctly, the expectation was that you would write down an assignment on the day it was due, but I always found this insufficient, since if you only look at the next day's items when doing your homework, you'll only work on assignments the night before they're due. So I think I copied assignments onto all days until the due date, which gave an overview of all the things I could be working on on any given night.

Similar notebooks were also given out in high school. (The high-school notebooks were smaller in size than the middle-school ones, even though presumably high schoolers have more todo items than middle schoolers.) In college, there were no formal assignment notebooks, so I made notes of assignments in my regular notebooks instead.

During school, most of my tasks concerned homework. Tasks about other things (such as applying for internships or setting up a doctor visit) I think I did in ad hoc ways, such as by jotting them down in text files.

In the years after college, I tried out a number of software tools for task management, often because other people I was working with used them. I've also browsed a number of additional software tools to see if any look particularly useful. In the end, I've always come to the conclusion that the best way of recording my own todo items is simply to write them down in plain text.

I haven't yet read any of the famous books on task management, and perhaps my style would change if I did.

Why I use plain text

Here are some reasons why I prefer text-based todo lists over todo-list web applications:

A reader pointed me to the "todo.txt format", which has a similar philosophy regarding text files (Karbassi 2017):

Plain text is software and operating system agnostic. It's searchable, portable, lightweight, and easily manipulated. It's unstructured. It works when someone else's web server is down or your Outlook .PST file is corrupt. There's no exporting and importing, no databases or tags or flags or stars or prioritizing or insert company name here-induced rules on what you can and can't do with it.

One feature that text documents lack is a calendar and reminder alerts. However, I actually prefer for most of my todo items not to have reminders. I find that when I set reminders for todo items, I usually end up delaying them because I'm busy with other things, and the constant reminders just make me feel guilty about not getting to whatever the reminders are for. Plus, it wastes some time to delay the reminders to a future date. The only case where reminders are useful is for actual appointments, like doctor visits or scheduled Skype calls, and for these I can use a calendar application. I see my todo lists as more of a repository of ideas for things I hope to do sooner or later, rather than tasks I need to get done by some specific deadline. This is my preferred working style, though I suppose that if I had more specific deadlines set by a boss, then creating scheduled reminders might make more sense.

Calendar todo list?

Successful By Design (2015) suggests (at 3m10s into the video) scheduling todo-list items onto your calendar. When you do this, "You start getting more in control. You start getting a better idea of what it is that you need to do, when you need to do it, how much time it's going to take you" (3m44s).

Different strokes for different folks, but this is very different from how I work. I don't like to schedule my activities; instead, I prefer to do whatever I'm in the mood for at a given moment. By analogy, I don't schedule all my meals for the day in advance, because this might mean I'm hungry at some times and eat when I'm full at other times. I'd rather do exactly what my body and mind want to do at a given time in order enjoy and perform well at that task, rather than wishing I were doing something else.

When I have willpower and mental alertness, I often do a relatively difficult task from my todo list, before that mental state wears off. And when I'm tired or not able to concentrate, I pick a relatively easy and low-stakes task from my todo list. If I scheduled my tasks ahead of time, I might try to do a difficult task when I'm tired, or I might waste a period of mental alertness on something relatively easy.

Unfortunately, if you work at a job where your manager requires doing particular things at particular times, you don't have the luxury of matching your activities with your current mood.

Treating todo lists as priority queues

Years ago, when I first began creating a todo list, I imagined that I would eventually finish the items on it. However, I soon observed that for every todo item I completed from my list, I tended to add two more items in the intervening time. Gradually, my todo list ballooned in size. Eventually, it got so big that I decided to create a new list for the more recent and urgent items that—"this time for sure"—I would aim to actually complete. Of course, this list also followed the same pattern, ballooning in size until I moved to yet another list that would be more manageable in size.

Man reading todo list.By this point I've obviously given up the illusion that I'll ever finish everything on my todo lists. I've discovered that "my eyes are bigger than my stomach" in the realm of things I want to do, meaning that I desire to complete many more tasks than I'll ever have time for. This realization forces me to take a new perspective on todo lists. Rather than seeing them as tasks that I have to complete in order to make my work "perfect", I see them as friendly suggestions of things that would be good to do if I can find the time. If I can't complete everything (as I certainly can't), I can live with that, and I should be happy about what I can get done. If I recall correctly, Cenk Uygur has made a similar observation, comparing himself to someone with a bucket trying to catch a waterfall, and noting that you should feel satisfied about what you can catch in the bucket rather than regretting what you can't.

School teaches the wrong approach to todo lists, since in school, the specific tasks that you're assigned as homework are very important to complete, and everything else is basically worthless from the perspective of your grade. Real life doesn't work that way. Even if you have a small todo list and finish everything on it, that's a fiction, because if you thought more about what things you could do, you would keep adding to your list. The fact that a particular task hasn't occurred to you to write down doesn't mean that there aren't tasks out there that would be valuable to work on. So todo lists are really sort of like notes that you take regarding the almost infinite variety of things that you could be working on.

Except for a few items that you absolutely have to do, such as completing your taxes on time, I find it helpful to think of a todo list as a priority queue—a collection of items with varying importance, on which you can call pull_highest_priority_element when picking what next to work on. Or, more realistically, you might choose what next to work on based on a combination of your current mood, what project you're in the middle of, and what the intrinsic importance of the task is.

Thinking of todo lists as priority queues means that when it feels like you have too much to do, you don't have to feel stressed out about it. Sort the items by priority, do the most important ones, and don't worry too much when you don't get to everything. On the other hand, if you finish your todo list, you're not really done; you should go off and brainstorm more items to add to the queue.

Spreadsheet todo list?

For a few months I tried creating an actual priority queue for my tasks. Rather than using a regular text file to store todo items, I created a spreadsheet in which one column stored the todo item's priority and the other column stored a description of the task. Periodically, I could sort the spreadsheet on the priority column so that highest-priority tasks would come to the top.

I eventually abandoned this for a few reasons.

  1. Spreadsheets take longer to open than text documents, and when a todo list gets long, this extra loading time becomes tedious.
  2. I found it cognitively burdensome to think of the exact priority for my tasks, especially the more trivial ones.
  3. I have a tendency to assign unduly high priority to tasks that happen to grab my attention at the moment, even though I'll later decide that these tasks should be downgraded in priority. So the priority scores I assigned weren't necessarily stable over time.

Instead I've returned to an unprioritized todo list where I basically assume that more recent items higher on the list are more important, and if an item is clearly low-priority, I can deliberately put it lower in my list. To select an item to work on, I can browse through the list and pick something that seems in line with my current mood and degree of mental acuity at a given moment.

List format

Here's a fictional example of how I might format a plain-text todo list:

Hear Horton's Who.

Teleport to [Mars](https://en.wikipedia.org/wiki/Mars).

Follow up on [this](https://en.wikipedia.org/wiki/Spiropyran#Structure): "The second ring, the replaced one, is usually heterocyclic but there are exceptions.    When the spiropyran is in a solution with polar solvents or when it receives heating (thermochromism) or radiation (photochromism) it becomes coloured".

I write my lists with one task per line and a blank line between tasks. I try to keep tasks all on one line, and I may use four spaces to indicate a new paragraph while keeping the text all on the same line (as shown with the "spiropyran" example above). Keeping one task per line is helpful in case I ever want to do processing on the file. For example:

Any urls I need to reference are written as bare urls, or using Markdown syntax, rather than turning them into clickable hyperlinks, because if I later copy-paste the todo-list text somewhere else or export it as raw text, I want the url information to be retained.

For long todo items, I might add a short summary at the beginning to allow me to quickly tell what the todo item is about, although I avoid spending too much cognitive effort coming up with a description if doing so doesn't seem worthwhile. You could write a description in {curly braces} like this:

{spiropyran} Follow up on [this](https://en.wikipedia.org/wiki/Spiropyran#Structure): "The second ring, the replaced one, is usually heterocyclic but there are exceptions.    When the spiropyran is in a solution with polar solvents or when it receives heating (thermochromism) or radiation (photochromism) it becomes coloured".

Curly braces avoid confusion with [square brackets], which are part of Markdown syntax, as well as with (parentheses), which are common in natural-language text.

Sometimes I mix Markdown with HTML syntax. For example, when pasting in a several-paragraph-long quote, it may be easier to write <blockquote> ... </blockquote> around it than to write a series of > 's on each line. Also, when striking through some text, I might want to add an explanation for why the text is being deprecated. Using a slight abuse of HTML syntax, I can do that with the cite attribute of the <del> tag. For example:

{buy rocks} Regularly buy some metamorphic <del cite="In July 2005, we switched rock types for price reasons.">igneous</del> rocks.

Categorized todo lists?

Historically I've tended to put most of my generic todo items into a single list, at least until the list gets too big and I need to spill over into a fresh new list. However, recently I've begun experimenting with putting more todo items into separate lists by category. Given that my todo lists will never be completed and will always follow me around as reminders, I figure I may as well make the lists more organized. Separating items by category is one way to organically avoid building monstrous, 100-page todo lists that are unwieldy to open and navigate.

Organized lists can also be helpful if particular tasks are appropriate at particular times. For example, I created a list for "mindless" tasks—i.e., repetitive tasks that don't require much thought and that I can do while listening to music. I usually save up these tasks until I'm in the mood to listen to music, so it's helpful to have them all in one place.

It's also useful to be able to store all the todo items for a particular project in their own todo list, to ensure that the todo items don't get scattered, and so that I can know that all the todo items for that project are in fact finished when I close out that particular todo list. If the todo items for a given project P are written among lots of other items for other projects in a giant todo list, it's harder to figure out if I've finished all the items for P.

Grouping todo items by category is also useful for more easily noticing duplicate todo items, because during grouping, similar todo items are put near one another on a relatively short list. For me, duplicates tend to occur either if I think of a todo item on two separate occasions and note it down each time, or if I write myself a temporary reminder about an existing todo item, but then that reminder itself gets buried in the todo list. Duplicates are particularly annoying in a situation where I see one of the todo items, complete the task, remove the todo item from my list, later find the other duplicate todo item, and then can't remember if I've already finished it, which means I have to go back and check if it's done.

The main concern I have with maintaining many categorized todo lists is that I have to remember to check back on all these lists periodically rather than letting them fall by the wayside. I'm nervous that it might take a while until I circle back to a given list. I suppose it'd be useful to keep at least one todo list for a small number of high-priority items that I don't want to allow myself to forget about.

In ZionsBank (2013), David Allen recommends using "more than just one list. You want to be able to create different categories of lists. [...] And all of that of course dies a sure death if you don't step back and review these things on some consistent basis" (41m11s).

Even when having categorized todo lists to organize medium-term or long-term projects, I still use a single text file as my "immediate scratchpad", to jot down new thoughts and remind myself about things to do very soon (e.g., "call the doctor" or "buy a new toothbrush"). Since I can finish and cross off these items quickly, it's not worth the effort to move them to categorized todo lists, which would make them harder to remember to do anyway, because they would no longer all be together. If an item remains on the immediate-scratchpad list for a while without getting done, then I can move it "into storage" by migrating it to a categorized todo list. When moving a todo item from the immediate scratchpad to a longer-term todo list, I often rewrite the todo item to make it more clear, so that I can still understand what it means a few years later, in case it takes that long to return to it.

Todos vs. reminders

Often I have recurring reminders for myself in addition to todo items. A todo item can be completed, while a reminder sticks around perhaps indefinitely. One way to organize these is to have a "Todos" section of your list and also a "Reminders" section. For example, suppose you have a todo-list document related to your Wikipedia contributions. Here's an example of how this list could look if it has two todo items and one reminder:

# Todos

Revise my Wikipedia article on extraterrestrial tax codes so that footnotes appear [after every sentence](https://briantomasik.com/writing-style/#Citations_after_every_sentence).

Find and upload a public-domain image of the Extraterrestrial Revenue Service.

# Reminders

When writing Wikipedia articles, put footnotes [after every sentence](https://briantomasik.com/writing-style/#Citations_after_every_sentence).

You could consider adding a line saying something like "Last reviewed: 2018 Aug 9" under the "Reminders" heading if you want to keep track of whether the reminders in a given todo-list file haven't been reviewed in a long time.

Indicating priority among many todo lists

Suppose you have a folder of 25 different todo lists that each contain todo items on their own topics. Is there a way you can indicate to yourself which of those lists you should prioritize first?

One possible solution is to add a prefix to the title of each list to indicate priority, such as med-pri_Mars-spaceship-todos.txt or HIGH-PRI_rock-collection-tasks.txt. What if, as is probably the case, a todo list contains both high-priority and low-priority tasks? You could set the priority prefix as the maximum priority of any task in the list. For example, if a list contains any high-priority tasks, mark it as HIGH-PRI. If you complete the high-priority tasks and are left with only low-priority ones, then change the prefix to low-pri.

If you use words like HIGH-PRI, med-pri, and low-pri to indicate priority, then an alphabetical sort of your todo lists will be out of order of priority, since H comes before l, but l comes before m. To solve this problem, you could instead use numbers: pri1, pri2, and pri3. This way, an alphabetical sort will be in the proper order. Using numbers also allows for the possibility of assigning more than three different priority levels, though I find it cognitively burdensome to try to assign priority more precisely than among three possible choices.

Todos vs. reference material

David Allen uses the term "reference material" to denote information that you might need in the future but that isn't a todo action. Should you store reference material separate from your todos? And if so, how do you decide what material goes in which location?

It seems likely to me that I should separate todos from reference material, so that my todo documents can be the go-to place for looking at what I need to work on. If I stored todos and reference material together, then todos would be scattered throughout lots of my files, and it would be harder to systematically review my todo items.

However, separating todos from reference material has the unfortunate property that information about the same topic may be siloed between two different locations. As an example, suppose you have a todo document related to applying to jobs, and you get the business card for someone you want to contact to talk about possibly working at her company. Do you store the person's contact information in your todo doc directly, or in a "reference material" location such as an address book? In the short term, it may be more convenient to store the information directly in the todo document, so that it's right at your fingertips while you're simultaneously looking at your todo item to "Contact Susy about working at Acme Corp."

Navigating the line between todos vs. reference material is something I'm still figuring out. I think one plausible approach is that it's ok to keep reference material in a todo document as long as it's still being actively used. For example, you can keep the business-card data in a todo document while you're still talking with that person, and then when you're done, you can either get rid of the info or move it to reference material for storage. The todo document would be like the active "working face" of a landfill, where trash is being handled and compacted, until it's finally covered up for storage.

Combining todos with reference material?

As of late 2018, I'm contemplating the strategy of combining todos and reference material together into the same folders and documents. For example, a text file could contain one section for "Todos", one section for "Reminders", and additional sections below for "Reference information" or "What I've done so far" or whatever. The main advantage of this approach is that you can just organize your files by content (what they're about) rather than also making additional distinctions based on non-content factors like whether the item is a todo vs. reference material. When you want to retrieve information about your rock collection, there's exactly one place in your files to look; you don't have to check both the "todos" folder and the "reference material" folder to find what you're looking for. Since the todo items are at the top of any documents you create, it shouldn't be that hard to skim them by quickly browsing through the files in the relevant folder.

In many cases it may not make sense to put todos and reference material into the same file, especially if there's a lot of reference material. But you can still keep todos and reference material close together within the same folder. For example, if you have a rock-collection/ folder, you can have a todo.txt file in it alongside reference material like igneous-prices.txt or history-of-rock-collecting.pdf. This seems plausibly less confusing than the alternative approach of having one high-level todo/ folder that contains all your todos at once (such as rock-collection.txt and Mars-taxes.txt) and another high-level reference-material/ folder that contains all your reference material (such as rock-collection/ and Mars-taxes/). However, burying todos within reference-material folders does require that you periodically scan or search through all those folders to find remaining todo items.

Searching todos that are mixed with reference material

A big downside of combining todos with non-todo information is that it becomes much harder to search through your todos. When all your todo documents are in a single todos/ folder, you can just search in that folder. However, if todos are scattered throughout your files, then when you search for keywords, a lot of irrelevant stuff from non-todo documents will clutter up the search results. And if you search using grep through a series of folders that contain large images or videos, then grep will take a long time to return results unless you only search certain file types.

You could ameliorate these problems with two steps. First, grep through only .txt files. Doing this is shown in the following command, which searches the current directory and all subdirectories for the keyword "igneous":

grep -rin --include \*.txt igneous .

However, this will still return lines from non-todo parts of text files. To fix that, you could maintain a policy of always writing "todo: " in front of every line that contains a todo item. For example, instead of writing just "Organize my igneous rock collection in descending order of potassium content", you would write "todo: Organize my igneous rock collection in descending order of potassium content". With this prefix convention in place, you can then filter down search results like this:

grep -rin --include \*.txt igneous . | grep "todo:"

You could convert this command into a Bash function with a variable search keyword if you plan to run it a lot. A main downside is that it requires a lot of discipline to always write "todo: " in front of every todo item, and you might have lots of old todo items for which you haven't done this.

A benefit of the "todo: " prefix convention is that once it's in place, you can list all your todo items across all your files within a folder using the command

grep -rin --include \*.txt "todo:" .

This could help to combat the problem of not being able to find all your todo items if they're scattered throughout a large number of files. You could similarly adopt the convention of prefixing all reminders with "reminder: " (or maybe something shorter, like "remr: ") so that you can then list all reminders across all your files.

One could also argue that if your files are organized well enough by category, then you won't need to search for todos as often, because they should all be grouped together already. However, perfect organization can be hard to achieve, and even the best organization system will still sometimes require searches, if you're searching for something that cuts across the categories you've set up. For example, both your rock-collection/ and Mars-taxes/ folders may contain todo items that match the keyword "expenses".

Inventing your own terminology

One thing I like about taking notes in text files is that I have complete freedom to invent my own conventions, terms, and abbreviations to indicate particular things. One example I already mentioned was the idea of prefixing all long-term reminders to yourself with remr: so that you can quickly identify that a given line of text is a reminder and so that you can use grep to list all your reminders if you want.

One benefit of abbreviations for concepts is that they're shorter to write than explaining the full concept in words, which is nice if you write the concept a lot, or if you're trying to include it in file names without being too verbose. Even if you don't write a concept extremely often, standardizing on a given notation is helpful for other reasons. It allows for more easily searching for all instances where the notation is being used, and therefore, it also makes it easier to automate changes to your organizational system later on if you ever do end up changing things. There's a reason that people in all sorts of communities create new words for concepts; it helps make communication easier and clearer. This same principle can apply to communication with yourself across time in your notes. Of course, you'll want to write down in a central location what all your abbreviations mean, to avoid forgetting later and then being unable to comprehend what you wrote.

Following are some more examples of conventions I made up.

antimatter

Suppose you write down a todo item:

todo: Pick up rocks #82 and #163 at the rock store.

A few weeks later, you do pick up the rocks at the store. When you get home, you remember that you had a todo item about this on your list, and this item is now done, but due to busyness, tiredness, or laziness, you don't want to right away look for the todo item on your list in order to remove it. However, you do want to eventually remove the todo item from your list so that you won't mistakenly later think that you haven't done the item yet. One solution can be to write a new item on your todo list:

antimatter: I bought rocks #82 and #163 on 2018-03-12.

This new todo item means you should look for the old todo item about this topic and remove it because it's now done. I use the label "antimatter" because once this line meets the original todo item's line, the two annihilate each other, i.e., they can both be deleted.

dval

This stands for "date known to be valid". As an example, suppose your acquaintance Bob gives you his phone number (say, 123-456-7890) on the 21st of June 2018. If you save it to your records, you could write it like this:

Bob 123-456-7890 dval:2018-06-21

Why might it be useful to include a date? Imagine that in 2023 you come back to this phone number and wonder whether it's still correct. If it's only 5 years old, it's more likely to still work than if it's 15 years old.

In general, writing foo dval:bar means "I know that foo is accurate or up-to-date at least as of date bar. (It may still be true more recently than date bar , but I either haven't checked or haven't bothered to write down that fact here.)" This can apply to any kind of foo , including general statements like "My cousin currently has my green bike. dval:2013-04".

lwlo

This abbreviation stands for "location where I left off". For example, suppose you have this folder on your computer:

rock-collecting/
  Rocks-Manual_212-pages-long.pdf
  Famous-Rocks-of-the-World_92-minutes-long.mp4

You're reading through the long PDF and watching the long video, but you don't finish all in one sitting. To remember where you left off, you could create a lwlo.txt file in the folder:

rock-collecting/
  Rocks-Manual_212-pages-long.pdf
  Famous-Rocks-of-the-World_92-minutes-long.mp4
  lwlo.txt

The file's contents could look like this:

Rocks-Manual_212-pages-long.pdf p. 24 dval:2019-04-18
Famous-Rocks-of-the-World_92-minutes-long.mp4 35:04 dval:2019-04-20

If you're reading a document that doesn't have page numbers, you could instead copy-paste a snippet of text from where you left off, so that you can Ctrl+f to find that spot upon reopening the file.

Including dval stamps is optional. One reason you might want to include them is if there's a chance you'll forget to update the lwlo.txt file. For example, suppose you read up to page 24 as of 2019-04-18 and record this in the lwlo.txt file. Then on 2019-05-29, you read up to page 44, but you forget to update the lwlo.txt file to reflect that fact. If you check back on the lwlo.txt file on, say, 2019-06-12, you would see that you're apparently only on page 24. But noticing that the dval value is from all the way back in April, you might realize, "Oh, that's probably stale information."

The lwlo.txt file plays the same role that bookmarks do when people read physical books.

If you read out of order, your lwlo.txt file could give the range of page numbers that you've read (for example, "pp. 5-12, 33-45") rather than just listing a single location where you left off. In the 1990s and early 2000s, I read physical books more often than I do now in 2019. When I read physical books out of order, I would sometimes have several bookmarks in different places due to skipping around, and it could be confusing to figure out what parts I had and hadn't read. A lwlo.txt file can be more descriptive than a physical bookmark, helping to reduce this confusion.

You could also use the lwlo convention within your todo lists rather than creating a separate .txt file to store the information. For example, you might have this todo item:

todo: Finish reading https://en.wikipedia.org/wiki/Amateur_geology (lwlo:"Avid rock collectors often use their specimens" dval:2019-08-31)

eom

When writing emails, people sometimes use the abbreviation "EOM", standing for "end of message". You can add "EOM" to the end of an email's subject to indicate that the subject contains the entire message, and the reader needn't check the body of the email.

Extending this idea, I add _eom to the end of a file name if the file is empty, and I'm only using the file name itself to convey a message.

One case where this is useful is if you want to create a quick-and-dirty todo reminder to yourself without opening a text editor. For example, suppose you have a folder containing a document that needs reviewing. Rather than adding this todo item to your regular todo list, an alternative can be to create a dummy .txt file right next to the document, where the name of the .txt file carries the todo message. In Terminal, if you're currently in the directory that contains the document to review, you can just type this:

touch todo_finish-checking-the-document-here_eom.txt

The _eom flag implies that when you're done with this todo item, you can just delete this dummy text file without checking to see if it contains anything in need of saving (since it doesn't contain anything at all).

This method of writing todo reminders only works if you expect to navigate to the relevant folder from time to time already, so that you'll see the todo message. If you never visit the folder, the todo item may be forgotten.

Using a text file as a calendar

One of the features that text files generally lack is the ability to schedule reminders of upcoming tasks or appointments. For this reason, you could use text files to store most regular todo items but continue using a special calendar program or web application for appointments.

However, I've discovered that I can even do my calendar with a plain old text file, rather than using a special application. I simply write down a sorted list of the dates of upcoming appointments, calls, events, etc. I briefly review this list every few days to refresh my mental picture of what's coming up. And when an event passes, I remove it from the list.

I like this method better than using a specialized application because it's simpler in various ways. To create an event, I need only write down a line or two in a text file, rather than selecting a number of fields in a calendar application and skipping over a bunch of other fields that I don't need to fill out. Since I personally have relatively few appointments, a text file allows me to preview many months ahead of time all in one screen, rather than needing to scroll through several months of a relatively sparse calendar. And as with using text files for todo lists, using a text file for a calendar makes it maximally simple to back up my data. I don't need to specially export the data from my calendar for backup, since my calendar is already just one file in my collection of files.

One thing that's missing from a text-file-based calendar is the ability to create recurring events; if you have a lot of those, you might prefer to stick with a calendar application. A simple way to handle recurring events in a text file is to write a note that "This event recurs every X days/weeks/months", and when you finish one instance of the event, while crossing it off, also write down the date of the next instance of the event. You could alternatively write down a bunch of future instances of the event at once, but if things slide forward by a day or a week, then you'd have to change all those future dates at once, which you don't have to do if you just write down the single next date of the event at a time.

Case study: prescription reminders

I have a prescription that requires manual renewal every month. (Let's round up and say a month is always 31 days.) I put reminders about renewing it on my calendar. Originally when I started using a text-file calendar, I planned to pregenerate a bunch of dates when I would do the renewals and paste them all into my calendar. I created this Python script to help calculate these dates.

However, what happens in practice is that I often slide a day or three forward from the planned renewal date, either because the planned date falls on a weekend or just because I'm slow and don't get around to doing the renewal on the planned date. Since there has to be a minimum of 31 days between each renewal, if one renewal slides forward a few days, they all have to. So if you precomputed, say, 10 different renewal dates, you'd have to adjust the 9 remaining renewal dates after you slide a few days past the first one.

A much easier system is to write a single calendar item like this:

Sep 25: renew prescription (cwb_31days)

cwb_31days is my abbreviation for "continue writing this below 31 days forward". So when Sep 25 rolls around and I finish the renewal for that month, I cut (i.e., Ctrl+x) that line from my calendar, paste it in late Oct, and edit it to say this:

Oct 26: renew prescription (cwb_31days)

Sliding a few days forward is arguably easier using this method than it would be even with a real calendar application, since with a real calendar application you'd have to edit the recurring event and adjust the date forward each time.

Cognitive vs emotional tasks

My brain transitions through various moods and degrees of engagement with various things, somewhat at random and somewhat predictably. I try to match what I work on at a given time with my current brain state.

One simplistic dimension along which to characterize my brain states is how "on the ball" I am at a given time: how much I'm awake, alert, engaged, motivated, etc. However, I think we can actually break this apart into two dimensions of being "on the ball": cognitive and emotional.

Being cognitively engaged means that I'm able to do tasks without making lots of stupid mistakes or forgetting important instructions. For example, I'm less likely to write a nonsense sentence or overlook a step in a checklist. I find that being cognitively engaged is important if I'm doing computer tasks that involve writing or editing data, because I want to avoid messing things up, such as running the wrong Terminal command or accidentally deleting a todo item that I haven't finished. Conversely, when I'm cognitively unengaged, it's best if I either stay away from the computer entirely or at least only do simple, low-stakes tasks like browsing the web.

Being emotionally engaged means that I'm in a mood to think about interesting issues without finding them dull or unmotivating. This is the kind of brain state that's important for social interaction, reading non-technical material, reflecting on life, and so on. Being emotionally unengaged is a somewhat more anhedonic state.

Following are some examples of tasks that make sense in each of the four quadrants of engagement.

Cognitively engaged + emotionally engaged: writing almost anything (website content, emails, notes to myself, computer code), or doing other "ambitious" tasks like moving my website away from using WordPress.

Cognitively engaged + emotionally unengaged: organizing my todo lists, checking my credit-card and bank transactions, doing a backup of my data, fixing small syntax issues in HTML on my website. In general, these tasks are various digital "chores" that don't require big-picture thinking.

Cognitively unengaged + emotionally engaged: reading or watching interesting content where attention to detail isn't essential.

Cognitively unengaged + emotionally unengaged: physical tasks like showering, preparing food, shaving, exercising. Also low-difficulty digital "chores" like finding a new toothbrush on Amazon. Being both cognitively and emotionally unengaged at once is most common when I'm tired due to not sleeping well.

I dislike the traditional way of doing "work" where you go to an office from 9 to 5 and then go home. One of many reasons why this doesn't suit me is that it doesn't allow for matching tasks with brain states. You artificially have to be "on the ball" at work and then don't have to be afterward. But that's not how I am; my degree of engagement with things has a life of its own. It sucks to be forced to work on important, attention-requiring tasks like writing when you're tired, but this is what traditional workplaces and school classrooms do. Perhaps this is why some people find caffeine so important: it's a way to force your brain to enter a productive state now, rather than waiting for the productive state to arrive at its own pace. I dislike project deadlines and schedules for the same reason: they force you to work on some particular tasks now, even if your current brain state makes you better suited to work on something else now.