5 ms·

> solidify the mental model into a concrete branching of possibilities that is tightly coupled to the specific problem. Your work becomes traversal and mutation

• dhc02 2y ago
  This is really interesting. Thanks for sharing.
• ravetcofx 2y ago
  That is one of those novel once in a generation kind of tools and concepts I feel. Outstanding
• tarruda 2y ago
  Interesting tool. 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.
  • slyfox125 2y ago
    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.
    • leetrout 2y ago
      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.
      • rpdillon 2y ago
        > because it is the discipline to use the tool consistently that makes a difference. Agree, though I advise folks that tooling matters tremendously, because a bad tool requires more discipline to continue using than a streamlined tool.
        • leetrout 2y ago
          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."
      • greggsy 2y ago
        Obsidian in a nutshell. Too many bells a whistles to tweak, and isn’t conducive to consistency.
        • WJW 2y ago
          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.
      • j45 2y ago
        This is generally true. 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.
    • lelanthran 2y ago
      > 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.
  • was8309 2y ago
    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
  • hallman76 2y ago
    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!
• kwakubiney 2y ago
  Really cool tool. Starred
• aggrrrh 2y ago
  It’s great. You should do a separate hn post
• johtso 2y ago
  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.
  • lelanthran 2y ago
    > 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).
• devsda 2y ago
  Not a comment about the project itself. 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.
  • epolanski 2y ago
    But how do you use that flow to _plan_ your work?
    • mbreese 2y ago
      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!
• cmiles74 2y ago
  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.
  • telesilla 2y ago
    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.
  • gofreddygo 2y ago
    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.
• tra3 2y ago
  This is really cool. How do you reorder frames? If you’re working on a particularly complex frame, how do you maintain context?
  • lelanthran 2y ago
    > This is really cool. How do you reorder frames? 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.
• gsinclair 2y ago
  Love it. Just two questions from curiosity. 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.)
  • lelanthran 2y ago
    > 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.