I recently started doing this with my todo list. I wrote a few bash functions and aliases:

todo: Open my list in an editor

todo [thing]: Add a thing to the bottom of my list.

next: Show me only my next most important task.

mark: Mark my current task done.

There are a few more, but you get the idea.

I loved this idea ! I decided to develop a cli that reproduces these commands here for those interested: https://github.com/sahbic/todo-cli It can synchronize tasks on github, and I can use a telegram bot to list and add tasks to the list from my mobile phone.

Do you have them publicly available somewhere? I'd be interested in that, especially your `next` function telling you which to-do is coming up next without you having to look at _all_ tasks again.

Still a Linux noob, but I'm recently learning that you can do simple things like this in bash and the fact that it just... works is incredible. Thanks for the suggestion, I think I'll try this one

Similar workflow, except I have 3 lists: TODO, Pending and Done.

"TODO" is actionable items. It's a reorderable stack of work I need to do. Same: interruption pushes a task to the stack, when I finish a task I pop it from the stack, etc. So I always know what to do next.

"Pending" is an unordered list of things I'm awaiting. Say, I asked someone to do something, and they promised they'd get back to me in a few hours (or "by July 20"). I occasionally scan this list to see if some of the items got resolved and I need to continue working in those areas because I'm unblocked.

"Done" is a list of items I completed for the day, all finished items go there. I then copy the entire list to the time tracker (for the PMs) at the end of the day.

However, I organize files by day, not by task. Each day I create a new file for the day by copying the lists of the previous day's file minus the DONE list. I don't modify lists for previous days, so it's kind of an append-only log so I can see what was the state for any particular day. 1 file per day is easy to see as a whole as it mostly fits in one screen (and inside my working memory). I use plain text files because I found it much simpler to use, I don't have to install any software, it just works, and it's easily searchable.

I've been using this system for the last 6 years now and it served me well.

I started this a few months ago and find that my TODO grows faster than it depletes. My TODO items are both professional items (i.e. implement feature x) and personal (i.e. fix bike chain). The list is items that will take some non-trivial effort.

I now find that when I have a moment to do something, I pick it off of the TODO list and complete it. Prior to this technique, I did not have a list of this nature and some items never got completed.

I feel incredibly productive with my current setup. However, I don't feel as though my previous system was unproductive and am concerned that I'm "spinning my wheels" by feeling like I need to complete these tasks that went unfinished before.

Have you experienced this? Do you know how to best think about what is optimal?

> However, I organize files by day, not by task. Each day I create a new file for the day by copying the lists of the previous day's file minus the DONE list. I don't modify lists for previous days, so it's kind of an append-only log so I can see what was the state for any particular day. 1 file per day is easy to see as a whole as it mostly fits in one screen (and inside my working memory). I use plain text files because I found it much simpler to use, I don't have to install any software, it just works, and it's easily searchable.

For my working files I use a similar system except I separate at least Months, often Weeks, and sometimes Days into subheadings for easy time tracking of tasks on various time partitions.

So when I need to start a new heading for a new day, I just move all the incomplete TODO items into it, similar to you moving them into a new file.

Occasionally I manually archive the completed tasks into files by year with headings by month only when I no longer need their full granularity.

Yes, stack is much better than long-long log. After some time you're log becomes too big and if it contains some points you want to return to, then they are just lost. And if you lose something in it you stop trusting it and do not use it. At least this is my story.

This is pretty similar workflow to mine. I have a sideproject that implements it in a terminal that's been sitting on a shelf for awhile, maybe I should pick that one back up

How do you organize the journal? Do you grow an index from one side and tasks from the other?

I wrote myself a python cli tool that manages the stack by updating a sqlite database, and one of the commands creates a text file associated with the task (if it doesn't already exist) and opens it in Emacs. The text files are stored in a hard-coded directory and an anacron job does a git commit once a day.

I can tell what I worked on each day by querying the git commit history, and I can grep the entire directory for keywords.

It's a little janky but it works pretty well for me.

Ahh, I was expecting "journal" to refer to a physical book for some reason!

This makes a lot of sense. Why not simply store the task with the sqlite database? I'm assuming ease of editing + the ability to manage the stack separately from the log of text entries, which presumably need no maintenance nor will ever be deleted?

Pretty much what you said, yeah. I thought that a git repo of text files was easier to work with then storing them as blobs inside sqlite.

I do insert completed tasks into a "completed task" append-only table when I pop them off the stack, so I do have a record of completed tasks in sqlite. (I find that useful for remembering what I did recently for standups and 1:1's)