I’ve started using TODOs not only in my code. Now I find them very useful in this new context. E.g. they can be a hint to prioritize and to postpone less important tasks.

What is a TODO?

A TODO is just a comment in the code describing a way to improve a given bit of code (basically what should or could be done later).

There can be various reasons to add a TODO, e.g.:

  • the thing it describes is blocked on some other work (e.g. refactoring)
  • currently the author does not have time for this much better approach described in a TODO, while the current approach is good enough for now, but could be improved later.

TODO accomplishes number of functions, e.g.:

  • helping the author not to forget to do something
  • informing the reader that
    • a given bit can be improved
    • the author knew about this better way, but for some reason decided not to do it yet.

TODOs outside of code

Once I started using TODOs in my code, I naturally started adding them in other areas of my life as well.

Whenever you do a large enough project (e.g. writing a large blog post or trying to plan a large event), you have a lot of tasks and can feel overwhelmed. Often there are just to many of them and some can even pull more further work. As a result, if one is a perfectionist, one can easily get stuck already at the first task by going too deep into it and producing very little utility for the entire project.

As an example, imagine you are doing some website to test a new idea. You could setup its backend perfectly, including, for example, plenty of tests, easy one click scalability and super powerful servers. However, very soon in the process this stops helping much with your original goal - to test an idea. Perhaps the idea won’t work for some other reasons and all this hard work will be then even wasted. On the other hand, it can be hard to just say “ok, I will do poor quality work here” and setup the backend in a poor fashion (especially when one is a perfectionist).

Here come TODOs (or you could call this “prioritization”, but TODOs sound more exciting). One can accept that the backend setup could be improved, evaluate the relative benefits and if in doubt just leave a TODO to do this a bit later (if later ever comes). Basically, instead of saying “I did shitty job here”, one says “yeap, this is not my best masterpiece, but, hey, I know how to improve it and if it ever becomes a problem, I will do that”. If later does indeed come, one can reread the list of TODOs and reprioritize them based on the new state of the world (new knowledge, demand). If later does not come, one has just saved plenty of time not by doing that TODO. Hooray!

As a funny fact, I have a comment with a TODO right above this line to add a link to a post about importance of time. The post does not exist yet, but once it does I can search for all TODOs and replace this one with a link.

Happy productive and well-prioritized work!