As promised in my previous posts about organization, I will now go into some detail about my own organizational system. But before I start talking about it, and how I came to develop it, I’d like to emphasize a few points, or more specifically, three caveats, lest Zeus strike me down with a thunderbolt for my hubris:

• Caveat the First: My system is a work in progress. Even though it is overall very helpful, it’s always falling apart a little bit. Some parts of it work better than others, and it’s constantly evolving as I try to shore up the parts that fall apart more easily. Sometimes, it’s in a better state than others.
• Caveat the Second: What works for me might well not work for you, dear reader. I reckon you and I have very different brains. Even if a psychiatrist would categorize me and you with all the same formally recognized traits, we still have literally different brains, and literally different histories, cultural backgrounds, and personal struggles.
• Caveat the Third: Nothing in this system is particularly novel. It is however very tweaked to my own personality. I present this not to claim that I’ve developed anything new, but as a worked example of applying existing practices to my own life, in hopes that it will be useful to you.

And it is indeed a very personal system and a continuously evolving system. I am sensitive to minor issues. If a TODO list system is insufficiently ergonomic for me, I’ll get overwhelmed by it, or intimidated by it, disheartened, blocked out by my personal “Wall of Awful”, and I will default to not using any organizational system at all, and simply relying on my natural faculties – my naturally poor prospective memory – to make sure I do the things I need to do.

This has predictably terrible results, so I keep trying to use the system, but it involves a lot of tweaking, a lot of tricking myself, occasionally changing up the system in some ways, not necessarily because the improvements help – though sometimes they do – but also because changing the system makes it more interesting and more engaging and gives me another reason to look at the TODO items as I re-sort them into new categories rather than just idly reading through them.

Some parts of the system also work better than others, and so sometimes I’ll just use the parts of the system that work the best for me on their own for a few days, and the other parts of the system, the parts that work less well, can take a few days off before I am up to using them again. And that’s OK – that’s part of the design. It’s sort of become part of the organizational pattern – making a task out of re-organization.

So with these caveats out of the way, let’s begin the tour. Each section will go over a feature of the organizational system, describe where I got the idea from, and discuss how it fits into my dynamic.

E-Mail: Let me write that down real quick#

TODO tasks can come at any time, in any situation. Whether you abruptly remember something that you have to do, but didn’t write down, or someone tries to create a plan with you where you have to check the calendar, or you get an e-mail you have to respond to or else lose an important account, TODO tasks are not things that happen when you have your computer out and are ready to use your Fully Realized Personal Organizational System (TM).

This is perhaps the most important part of any TODO system: How do new tasks enter it? For those who use apps with phone versions, this might be that you actually put the task where it “actually goes” right away. But in my experience, this is too tedious. The version of the task when fully considered and put in the appropriate spot is different from the version you got it in, and converting it, and finding the right spot, is itself a mini-task you might be tempted to procrastinate. And God forbid you decide that, really, it should be in a completely new category, and other things should be moved to that category too!

No, new tasks belong in their own lightweight place, and then a separate habit should be developed of draining that place, later, when not trying to make conversation with someone, and organizing those tasks.

This is a core tenet of the Getting Things Done productivity methodology, and one I happen to agree with – and realized on my own a long time ago in my battles with JIRA. Recording tasks as they come up, and organizing tasks so that you can plan to do them, are fundamentally different things, and require different systems. The burdens of “organization” should not interfere with the lightweightness of “collection” – especially when “organization” is as arcane and heavyweight as JIRA is.

For my “collection” step, I use e-mail, and send myself quick subject-only e-mails to cover tasks I unexpectedly learn about. I marked all my e-mail as read in one heroic step late 2021, and ever since then, I’ve actually been an “Inbox Zero” person. Or rather, the type of person who regularly reads all my e-mails. This allows me to use unread e-mails as a repository for tasks, which is good because sometimes tasks from other people or organizations come in this way. I can mark e-mails unread as well, if they are both messages and tasks, an advantage text messages don’t have, so e-mail is better than texting in that way.

And then, there is a habit that comes with this: Every once in a while, ideally every day but at least every other day, I have to have a little session where I sit down, go through the e-mails, and either do the things or copy the TODO items into another place, within my real organizational system, which is in text files on my computer.

Of course, it also entails aggressively checking my e-mail multiple times a day, and in the biggest change, actually deleting or marking as read the “real” e-mails from companies that I’m not going to read, rather than just letting them pile up. So here I am, in my 30’s, finally a practitioner of Inbox Zero, which is honestly a bit of a pain. But the ability to use the e-mail Inbox as a TODO list has, so far, been worth it.

And I also know if I used a dedicated TODO app as my TODO list, instead of e-mails, I know that I’d (a) let them live there forever and (b) eventually stop looking at the app. The point is that these items don’t live in my e-mail – they just stay there as scratch space, for collection purposes. I get them into my real TODO system as fast as I can and they get deleted. The real TODO system, where items live, is much more sophisticated, and that’s what I’ll get into next.

Hierarchical Plain Text Files#

So, first of all, rather than use any sort of structured app, or spreadsheets, I use plain text files. I edit them in vim, my preferred text editor for programming, as I am very used to it. The commands, such as dd for delete line, p to paste in the line you just deleted, o for write a line above the current one, are all in my fingers’ muscle memory. This is the easiest way I can move content around and reorganize it, from file to file and within a file.

As I am using a programmers’ text editor to do my organizational system (and to do my writing), often when I’m working on blogging or just figuring out what to put on my TODO list, I look like I’m programming. People come up to me at bars and coffee shops to tell me that they’re impressed with the programming I’m doing:

But, as you can see if you read the words on the left, this is my blogging TODO list, not my work at all.

It’s very important to me that the items are hierarchical. I have a lot of ideas that flow out of my mind, and I like feeling like I can write them down so that I can eventually actually follow through on them. If I wrote all the ideas in list form – ever – there simply would be too little structure, and I would never find ideas that went together.

This is somewhat obvious for the planning for a blog post: Of course elements of a blog post go together, under a heading for that blog post, and of course pre-writing can be done in the form of a hierarchical outline.

But other tasks are hierarchical as well, even those we normally write lists for. I find that I do better when I express the hierarchy, and re-adapt the hierarchy for various phases of the planning.

For example, grocery lists. As a grocery list is being generated, it is hierarchical by planned meal (or non-meal category like “snacks”), and I type it out accordingly:

* Grocery shop
    * Snacks
        * Chips and salsa
            * Hot salsa
            * Mild salsa for guests
        * Bread and hummus
            * Challah bread
            * Potato rolls
    * Planned meals
        * Chili
            * Beans (I may have this already)
            * Tomatoes
            * Onions
            * Spices
                * Check online recipe
                * Confirm that I have them
        * Veggie Carbonara
            * Shiitake mushrooms
...
...

Notice that many of the TODO items are actually little research items to improve the hierarchy. I have to go check whether I have beans, and once I do, I can edit it. This same “Planned Meals” section can also be duplicated from the grocery shopping section to a separate section that tells me to actually make the meal.

If I do my shopping through a delivery system, the shopping list can stay in this format as I enter it into their app. But if I need to go shopping in person, I can restructure this shopping list to be by section of the grocery store, rather than by meal. The act of restructuring the list also helps me solidify the list in my memory, and gives me opportunities to realize I’ve missed things:

* Grocery shopping, buy:
    * Produce
        * Green onions
        * Peppers
            * Traffic light (red, yellow, green)
        * Mushrooms
            * Shiitake
            * Cremini
    * Canned food
        * Beans
        * Diced tomatoes
        * Hot salsa
        * Mild salsa

My TODO lists can be very long, as I can see by running the wc -l command to show how many lines they have:

[jim@palatinate:~]$ wc -l Log/TASKS Log/CALENDAR Log/WRITING.md Log/TECH_WRITING
  353 Log/TASKS
   95 Log/CALENDAR
 1022 Log/WRITING.md
  719 Log/TECH_WRITING
 2189 total

If I didn’t use some level of hierarchicalization, they would be completely impossible to read.

I am, of course, not the first person to use hierarchical plain text files as an organizational system. I use vim as my text editor, but in the Church of emacs, where emacs is considered the one true text editor, there is a long tradition of using Org Mode, a special file format that emacs specifically supports for such hierarchial organizational text. I have had colleagues use Org Mode in the past, and it was definitely an inspiration for my current system.

My files are not valid org mode files – they use the markdown style of hierarchical bullet points – but I sometimes consider making them org mode files, as that format is supported by multiple iPhone apps and then I could use my phone to access and update my organization files.

I also use Dropbox to keep these files synced between computers, because I am unfortunately no stranger to losing my laptop – because I forget to take my bag back with me when I’ve left it in a place.

Task-Specific File Formats#

But the fact that I use hierarchical plain text files is not enough to constitute a system. It’s more information than just “write it down”; it’s “write it down in plain text in a specific style of bullet points in a known location on my laptop and in Dropbox.” We’re closer to a system, but we’re not the whole way there yet.

This reminds me of the OSI model of networking layers. Indulge my nerdiness for a second: computer networking is systematized in multiple layers. The difference between Ethernet, Wi-Fi, and cable is one layer. At another more abstract layer, it’s all “the Internet,” using a family of protocols called TCP/IP. At a still higher layer, there’s a different “protocols” between browsing the web, your WhatsApp messages, your Zoom call, and each of them is layered on top of “Internet” or TCP/IP, and each of them is layered on top of either Wi-Fi, Ethernet, Cable, 5G, or carrier pigeon.

A simpler analogy: On your phone, you have different apps. It’s the same phone with the same hardware, but the apps are different.

Similarly, we have defined a few layers of my system:

• English
• Writing
• On my laptop and in DropBox
• Plain text files
  • With hierarchies of bullet points
    • To organize information
      • Inspired by “org” mode

But in order to actually use the system to organize my life, I am now at the point where I need different details for different parts of my life – where I have to do different things in my different apps. What works for one part of my life might not work in others.

Calendar: What to do each day#

I’ll talk about my calendar first. I use it absolutely every day, and it is the part of my organizational system that I absolutely couldn’t function without. My use of this organizational system waxes and wanes, as do my general organizational skills, but the presence of this system definitely elevates the waxing and waning so that my lowest lows are still more functional than my normal days before I had it. The calendar provides this baseline level, and is one of the parts that still functions when I’m too busy or too exhausted or simply too frazzled to use the other parts.

I won’t post screenshots of my calendar because it’s, ahem, obviously very private, but my main calendar is not Google Calendar on my phone (which I do not use), nor a calendar on the wall (which my parents always used to great effect), but it is actually one of these hierarchical text files.

If you send me a Google calendar invite, it won’t actually happen unless I integrate it into my personal calendar.

Fine, here’s a screenshot, but it’s scrolled down because I plan very far in advance (wink):

Each day has its own little entry. They can be as short or as long as they need, though if they get too long, I take this as a sign that I’m expecting too much of myself for that day. The actual items are a bit of a hodgepodge: It includes absolutely mandatory appointments (with times), things I must get done that day or else suffer greatly, or just tasks I know I need to do at some point and figure this is a good day for them. Some of it’s super time sensitive, but a lot of it is a near-term TODO list straddled along a few days of calendar, or moved from day to day as I literally procrastinate (pro cras being Latin for “for tomorrow”). For some items, the day it’s listed under doesn’t really mean much of anything at all, besides a promise to myself to think about that task on that day, and also an anxiety-relieving reassurance that I don’t have to think about it before then, because it’s written on a later day, which is the designated time for that obligation to resurface in my life, and no sooner.

(As a result, if an event needs preparation, I often need to write the preparation separately from the event, as when I’m in my less-functional modes I might not look ahead on the calendar.)

I don’t really distinguish these things in the calendar file; I keep track of what’s urgent and what’s not in my head. In spite of my sometimes over-enthusiastic over-wrought hierarchical notes, I actually only need a little reminder to not forget the thing at all. Once I’m reminded, my more normal-functioning retrospective memory kicks in, and I know all the details of why I have to do the thing and how urgent and/or important it actually is.

Like all parts of this organizational system, the calendar comes with some habits, which form the core of any organizational system. For the calendar, the habit is that every day, before I actually go about the tasks of my day, I look at the calendar to see what all I have to do that day. Often, I have leftover material from the previous day or days, from what I did (or at least, what I was supposed to do) yesterday.

I take those bullet points from previous days and respond appropriately. If it’s something I did, I’ll remove it. If it’s something I didn’t do, and should do, I move it to another day. And if it’s something I didn’t do, and it’s too late to do now, I can schedule apologies and other damage control for today or another day.

Perhaps just as important but less likely to actually happen is looking the previous night about what I have to do the next day. This ensures I actually get up on time to do things that are in the morning. Fortunately, such things are normally social in nature and my excitement for a social opportunity helps glue it in my memory – sometimes.

The other habit that comes with the calendar file is for when things get added to it. I don’t commit to anything until it’s hit my calendar and written the thing into the calendar. If I know I’m free, I might commit after having written myself an e-mail to add something to my calendar, but even then, I write the e-mail while I’m still having the conversation, and don’t actually agree to do the thing until I’ve sent it. This goes for work events and doctors appointments as well as personal events.

The Work File#

Though the calendar will contain some amount of day-to-day life TODOs, it generally doesn’t include work. If it’s a weekday, I start work, but I don’t write “get a day’s worth of job work done” on every entry (which is probably how I’d phrase it if I were to). I’ll put specific work meetings on it, because otherwise I might miss them, but my work is not heavy on concrete deadlines, and to the extent that it is, that goes in a separate work organizational system, in its own hierarchical text file.

I keep my organizational files open in GVim windows – panes, really, since I use XMonad – on virtual desktop #5 on my laptop. I generally have at least one organizational file open when I’m using the computer, depending on what I’m doing, and sometimes more than one. If I’m doing something else on another screen, writing code or reading Wikipedia, I always have my organizational files available at a moment’s tap of the buttons.

My work organizational file is open if and only if I’m working. It’s state of being open defines the concept of “being at work,” and reifies it in my mind. One hierarchical file contains all my personal work organization.

“All my personal work organization” doesn’t necessarily mean all my work organization overall: Ticketing systems and documentation and project plans that might have to be shared with others live in separate places, in formats preferred by the teams and companies I work for. But I always keep track of where they are (so long as they are relevant and so long as I have to make sure not to forget about them entirely) in the work file itself. If it doesn’t exist in the work file, I might forget about it, and likely will. This implies that if I shouldn’t forget about something, it should be referenced in the work file.

Therefore, one thing that is in my work file, and goes near the top, is a series of links to shared organizational pages. What tickets am I currently working on and responsible for updating, even if the actual work is done and I just have to answer questions or follow up on QA (quality assurance) at this point? What code have I written in the form of a merge request that I need to make sure my colleagues review and actually integrate with the code, even if I’ve written all the code I have to and I’ve theoretically handed it off? What issues have I filed on GitHub with open source projects that I need to follow up on to see if their maintainers have gotten back to me? Programming requires a surprising amount of following up with other people and reminding them of things, and that requires a list of things that are pending so I don’t forget a whole thing to follow up on.

Also at the top of the file I include my current TODO list. Oftentimes, I get a torrent of tasks at once, like when I think I have something simple to do (like fill out a JIRA ticket) but it turns out to have several side-quests (like researching which versions are supposed to support which features and who maintains them, and creating a secondary JIRA ticket to make sure the code eventually gets QA’d). Instead of trying to rely on my prospective memory, I spill them into the “immediate TODO” location. If they are not in fact the things I should do next, or if I find them overwhelming, I then sort them properly into projects.

Projects are the majority of the file, each in its own little cluster, analagous to dates in the calendar file. Usually, at any given point for my job, I have 1-3 projects that I’m actively working on. I prefer having at least one major project and one minor project: I work well when switching between multiple projects and I can use the minor project to take a break from the major project.

But my work file always has more than 1-3 projects. Often, I know what projects I will have to do after I’m done with the current project. Sometimes, I have started a project, and it might or might not come up again – and I have my notes for it in case it does. Sometimes, I have an idea for a future project, but it’s not really relevant now, and I write up how to do it. In any case, they’re all ready to consider when I’ve finished my current project, or to thaw out if someone tells me they’ve increased in priority or urgency.

The TODO/project dichotomy might seem a little complicated, but it’s necessary. Sometimes, the TODO items involve writing project summaries for a project. Sometimes, it includes communicating with other people about the project. Usually, the project summary itself contains the actual steps needed to get the project done as a programming project, whereas the TODO includes things like communicating to other people’s day-to-day messages about them.

And a programming job can easily gear up to that level of complexity. I get tasks on a 1-2 week time scale that I then have to break down into subtasks myself, sometimes even on a timescale of months. Only a small part of the job is actually changing the code. Most of it is figuring out how the existing code worked, figuring out why that doesn’t meet the needs, and then making sure the modified code actually gets into the finished product. People who ask for help often are stuck because they’ve made a false assumption, or misunderstood what the problem even is. And often problems straddle many unrelated systems – code testing and deployment almost always does.

So here are the habits that come with the work file: This means that whenever I find myself at work and not sure what I’m doing, I go read the top TODO item. If there is none, I go grab some items from the current project. If I do know what to do, but it isn’t written down in either of those two places, well, I write it down before I do it, in case I get distracted and forget. Meanwhile, meetings and time-based TODO items, as I said before, go in the same calendar along with everything else.

Other Files#

I have other hierarchical files in my system. Besides my work file for my job, I also have files in a similar structure for programming as a hobby (including technical blog posts), writing as a hobby (including non-technical blog posts), finances, and my social life. But for the most part, they just follow the same structure: a section for each project, in hierarchical format, with an immediate TODO list at the top.

Conclusion#

This system overall works well for me, but I’m always ready for improvements. Please share in the comments things that work well for you, and maybe I can learn something!