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.
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.
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.
Lots of space to lay out your ideas and get a great overview just not very pocketable.
I use a lot of diagrams / sketches / arrows between things / etc, so doing it all in text on a computer is too cumbersome.
Of course, with paper, looking up something from the past is a pain sometimes.
Just fyi in case it helps : - )
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.
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.
Agree, though I advise folks that tooling matters tremendously, because a bad tool requires more discipline to continue using than a streamlined tool.
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."
Too many bells a whistles to tweak, and isn’t conducive to consistency.
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 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.
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!
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.
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.)
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.
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).
If you’re working on a particularly complex frame, how do you maintain context?
Since each frame is a subdirectory directory in ~/.framedb/root, I can simply `mv` them. TBH, I've never yet found a need to rearrange them.
> If you’re working on a particularly complex frame, how do you maintain context?
I create child frames using whatever context was written into the current frame.