> solidify the mental model into a concrete branching of possibilities that is tightly coupled to the specific problem. Your work becomes traversal and mutation of this tree.
It's low-tech, but I've been using notebooks (not too thick, stapled usually). I write a header for each day when I start and then a line or two as I work on tasks and I try to note each time I switch tasks.
I keep the notebooks but rarely look at them once they are filled. Maybe once or twice as I switch to a new notebook and then once again when it comes to yearly review time. A couple of times I have rifled through old ones looking for command line flags but most of the time reading through the notes is enough to jog my memory.
A real notebook and pen are the perfect tools for this. Its the only one I know that works, long term.
append only log works, but skimming through 2 months of logs for a specific thing is poor and slow but very useful. I don't do that often but when i do need it sometimes and especially fast, like on a call, with no lead time. Its a superpower.
I now organize my notebook a with a few conventions that make it more useful.
I limit myself to using only the right side of a page for logs from whole week. Each new week gets a new page, always on the right side. Put the date as the page header. Makes skimming easier. Put any important tasks / targets for the week right after.
Further Split right page into 3 columns. First 2 for work logs, third column for recurring weekly/biweekly meeting stuff. Very easy to go back to what was discussed 2 months ago. All logs are usually 1-3 words. Just cues. but everything has a topic subheader.
Left page is free form for detailed stuff. Things i discover, design, 1:1 meeting notes, questions i need answers to, philosophy, anything new on HN, etc. Right page serves as context.
I also do an index on the first page of the book pointing to anything that i find repeatedly useful. Could do page numbers but i put the date as its naturally ordered by the dates on the right page.
Been doing this a while and works perfect. I have everything I need in one notebook, i can carry it with me. a $1 composition book with 50 pages lasts well over six months.
For me, Sublime Text works well because I am researching and copy/pasting URLs, data, snippets etc into it which would slow down as "scratch" memory on paper
True for me too. The only advantages of digital notes (for me) have been searchability and shareability. One thing I keep occasionally going back to is Notion - for LaTeX support (I tend to use a lot of math. symbols) and now diagramming support using mermaid (since 2022, but I discovered that only a few months ago, and I find myself spending a little more time in Notion now).
If you're into notion I wanna recommend obsidian. It's got support for both of those and it's way more lightweight. If you use the tables and images a lot I will say notion is simpler to use there, the same is possible in obsidian but it's more work for sure, but when I was using it it started to feel bloated and even though I love it I wanted something smoother and obsidian has been exactly that. Plus local storage as markdown for reliable access even if obsidian ends up shutting down or something is nice, and unbeatable for searchability since you can ripgrep through it all with ease.
I have a nice setup with notebooks, on one page I put down the date and my meetings for the day, then i list the tasks i want to get done for the day. I start crossing things off once they are done per project. Went to standup? ok cool cross it off, new task comes in, add it to the list to priortize for the next day. I can go back and see what i've done on every single day and which days i've been in meetings most days. Having a nice pen/pencil really helps.
Also a note taker - the physical aspect acts as a kind of cementing the thought. I never look at my old notes either and discard them when the book is complete, it's just an excerise in helping me manage complexity.
I currently use a TODO text file in the root of each project I'm working on, which I update right before I stop working. The lists are hierarchical, so each task I'm focused on has a parent item, which helps me remind of the bigger picture.
Usually, ths simplest solution is best and your approach exemplifies it: no need for a special application, simply open the text file and then go to work.
I have found, and advise teams I lead or work with, that the tool absolutely does not matter because it is the discipline to use the tool consistently that makes a difference.
Now, having said that, shoving jira down peoples throats with all kinds of rules around tagging and whatever wears people out.
So, yes, a text file, a google doc, linear or a few post-its on the wall.
This is very true. I guess I was thinking about all the times new people join a team and want to make changes to the team to fit the tools they prefer (including when a "big org" person rolls in wanting JIRA).
Toil and friction are killers.
In "Secrets of Productive People" Mark talks about building systems and that the lower level / background things should be reliable and without friction.
"Good systems for simple administration will free your mind for more productive work. Ideally you shouldn’t need to have to think about the lower-level stuff at all. Thinking needs to be kept for the high-level systems, which will be designed to fit each particular case. But even then the aim of designing a high-level system is to avoid eventually having to think about that system too."
Logseq is one of the only tools I feel different about.
The per item line entry combined with a basic plugin to auto tag based on the words you type and existing tags, has been a game changer. I can simultaneously tag one line to multiple things without having to go the point of filing or adding them to each.
I run it without any modifications from the default and it has been working quite well tbh. I'm pretty far from being a "power user" of obsidian though, it's literally only a note taking tool for me.
> Usually, ths simplest solution is best and your approach exemplifies it: no need for a special application, simply open the text file and then go to work.
I agree. The "tool" I have simply maintains text files and provides a streamlined way to display/edit the current one, switch to some previous one and switch back.
I made it to manage context switches. IOW, it's not to serve as a journal, it's to serve as a swap partition for my brain.
Mineis called README.md or notes.txt I use a similar hierarchical format - I use tabs for the hierarchy. I use markdown for most notes, but I find it somewhat incompatible with the tab-based note-taking that I prefer.
I share this in case there are others out there who work the same way. Let's band together to establish a tab-friendly Markdown variant!
and a tool to squash or expand the hierarchy helps alot. jEdit can fold/unfold based on indentation. along with simple prefixes : '-' for info, '>' for todo, '= {date}' for done, etc
If someone wants to try a similar flow but cannot run the above for any reason, git can be used to achieve something similar. You can also make use of existing tooling around git for shell integration like PS1 and gui.
1. Your main/master branch is your root frame.
2. Child Branches + branch commits themselves are messages.
3. Pop is hard reset of branch to parent or branch switch
The main idea is your log resides in commit messages and not the commit data itself. You can try using commit data too but limit that for shared contextual information.
Wrapping it up(to generate phony changes and running git) in shell aliases or functions should be easy.
I wouldn't see that as a way to plan work, but rather to keep track of what you did or where you were.
In general, I like the idea of ruthlessly tracking what I've done like this. But I think that it is still missing the context of the environment... meaning, if you are editing a file, it would be nice to not only know that you edited file A, but also that you changed line N to X.
I've spent a decent amount of time thinking about this over the years and haven't fully figured out a good solution. I was a wet lab scientist for a long time and we have the tradition/requirement of keeping a lab notebook. This is something that is incredibly helpful where you keep track of what you've done and what you're planning to do. I've missed this when I switched over to mainly computational work. In the past, I've thought about maybe having a loopback FUSE-ish mounted directory to track changes to files would work. But I think something akin to working in a git tracked repository (with these intermittent commits per command) might make this work better!
One. In your experience of using it for a while now, what is a typical tree size? What’s the highest it’s ever been?
Two. Why did you write it in C? Several other languages would surely make it much easier to implement that program. Not a critique at all, just curious. (I’m actually glad you wrote it in C. It’s a nice, reasonably sized piece of code to peruse.)
> One. In your experience of using it for a while now, what is a typical tree size? What’s the highest it’s ever been?
For me, the deepest node has ~ 25 ancestors. I don't know the largest depth it has ever been.
> Two. Why did you write it in C? Several other languages would surely make it much easier to implement that program.
I'm competent enough in C that it didn't matter to me, and the important thing was being able to call the library from any other language. Easy FFI made it quick to make a GUI for it (I primarily use the GUI now).
The library is in C, so others can make GUIs and wrappers in whatever language they want to, which is something I would like to encourage.
Love the sound of this tool! Seems a bit of a shame to permanently delete anything that's been completed, sometimes it's really useful to have a record of what you've been working on.
> Love the sound of this tool! Seems a bit of a shame to permanently delete anything that's been completed, sometimes it's really useful to have a record of what you've been working on.
I did originally have that; it lowered the signal:noise ratio.
I've found that there's isn't a need to keep around any frames of context for things that I have completed: generally there's already an artifact from that frame of context anyway (write this function, call that person, design that foobar, etc).
I wrote a program (used from a CLI, but I mostly use the GUI I developed for it) to do something similar for my own use: https://github.com/lelanthran/frame/blob/master/docs/FrameIn...
I use it daily.