💾 Archived View for mediocregopher.com › posts › todos.gmi captured on 2023-06-16 at 16:19:42. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-03-20)

➡️ Next capture (2023-09-08)

-=-=-=-=-=-=-

This post has been translated from it's original markdown format, if it seems busted it might appear better over HTTP:

https://mediocregopher.com/posts/todos

My TODO System

A single text file is all I need.

There's a lot going on in my day job. I triage bugs, answer questions, ask questions, write tickets, propose changes, and occasionally even get to write code.

As you could guess, this involves a *lot* of juggling. Sometimes I can deal with one of these tasks synchronously when it comes up, but usually I can't, and so I need a system for tracking and prioritizing tasks.

To complicate things, tasks can come from different places. Direct messages, group threads, emails, tickets, automated health checking, manual systems analysis, and random ideas which appear in my head out of nowhere are all likely sources of "shit I gotta deal with" throughout my day.

We have a company-wide system for task management, wherein users create tickets and those tickets get assigned and completed and signed off. This system is fine for high-level task management, and is used mostly to manage code changes across the team. But it's far too cumbersome for things like "ask Person about Thing" and "debug issue which was brought up in group chat". And it *definitely* doesn't work for tasks like "write ticket to make Change".

I've developed an extremely simple and effective system for these smaller tasks, and I wanted to share it. It's probably not new (nothing is), but a blog must have content, so here we go!

---

My system is called... a text file!

In general, the contents of the file look like this:

### SOON (TM)

- figure out how to do Big Change
- refactor Annoying Code
- get rid of Useless Feature

### AFTER <NOTABLE EVENT>

- unpause Broken Alert which will now have been fixed
- ask Person if Feature is ready yet
- write ticket to clean up old database data

### NEXT

- write tickets for Thing
- debug Issue
- follow up on PR with Person
- respond to DM from Other Person
- respond to questions in Ticket

### Done

- do a thing
- something else

I keep this file open at basically all times, and save it whenever I make a change. The line items are written by me manually, and are usually about as terse as you see here in this example.

The items are roughly listed in priority ascending order, where lower items need to get done sooner than later items. As items get done I move them into Done. This step is purely optional, but it takes negligibly more time compared to just deleting the item, and helps me know what I've spent my time on when it comes time to give progress updates at standup.

New items get inserted without a ton of thought, just a super rough estimation of priority compared to other things. Once I've triaged all incoming tasks (I'll describe that process next) I work my way from the bottom up. If something isn't quite do-able at the moment I might actually move it up the list, or I'll just skip to the next thing and re-evaluate the skipped item the next time I need a task to do.

As mentioned in the intro, incoming tasks can come from different places. I'll begin my day by checking my DMs. If someone's DM can be answered immediately, I'll do that. If not, I add a line to my list. Either way I mark the message as read. Next I check group messages. If my response is needed somewhere and I can do it immediately, I do that. If not, I add a line to my list. Either way my group messages get marked as read. Next I check email. If an email can get dealt with immediately, I do that. If not, I add a line to my list. Either way I archive the email.

You can see the pattern. For every incoming task I either deal with it immediately or add it to my list, but I mark the task's source as read at its origin. If there's unread messages of some sort later in the day I know that something new has come up, while also being confident that nothing I saw previously has been lost.

---

I think this system works well for me because the friction to using it is so low. It's just a text file, something I'm very well equipped to interact with. Because there's no external system or tool being used I'm very free to make on-the-fly judgements, as well as give myself wiggle room to break the rules when needed. Because it's completely private to me I don't have to be super descriptive in my messages, just enough to spark a memory in myself. And because it's just a local file it's fast and reliable; no network outages or syncing times.

If you're reading this thinking to yourself "my system is way better, this is crap" then... great! I'm happy you have something that works for you. But if you're not *happy* with your system, or you've never even considered that you *have* a system, I hope this gives you something to think about. We don't need big fancy tools to manage complex flows, a simple text file can be enough.

================================================================================

Published 2022-07-25 by mediocregopher

Browse all posts

RSS feed

================================================================================

Home

Source

License for all content, if you must have one