The benefit of journaling is not just reentry, but that you begin to 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. Several benefits accrue: you begin to see gaps in the tree, and can fill them in. You begin to have confidence in your mental model, recovering the time you used to spend going over the same nodes again and again in a haphazard way. In distributed systems in particular, the work is often detailed, manual, error prone and high latency - with a solid mental model you can get through a checklist of steps with minimum difficulty and high confidence that you didn't miss anything. This ability to take something abstract and make it more concrete on the fly is a critical skill.
Perhaps the greatest barrier to using it is akin to envy. We see others who apparently do this without written materials, in their head. I think we see this as evidence of intellectual superiority and harbor the doubt that using an aid like a journal means we are somehow lacking in skill or ability. This is wrong. Using an aid to map out complex problems isn't a failure, it's essential, especially for problems in systems you've never used before. Over time you may yourself build up your expertise such that you no longer need the aid, but that doesn't signal anything about your intelligence or ability either, only your experience.
> 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.
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.
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.
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.)
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.
If I'm working on something particularly complex I basically just do the journaling in a code comment adjacent to what I'm working on. So the first commit may be three lines of code and a huge long winded rambling comment of what I've already tried or thought about. By the time the task is done I've pared away the more speculative/rambling elements of what I wrote, and what's left is typically some extremely well commented code. I think this method results in higher quality code produced faster than if you just try to keep everything in your head. No one's complained yet...!
I like that. There are other ways of capturing work in progress adjacent to the code, instead of writing a journal. One of my favourites is to write a failing test - pretty much impossible to overlook or misunderstand on "re-entry" to the task.
Another is to write a temporary commit log, with "WIP" in the first line and a TODO list in the rest of the log. This is good for ephemeral information that would just clutter up the code.
If I do need something like a journal, I have occasionally just written a private gist and put that in a tab on my browser.
> Perhaps the greatest barrier to using it is akin to envy. We see others who apparently do this without written materials, in their head. I think we see this as evidence of intellectual superiority and harbor the doubt that using an aid like a journal means we are somehow lacking in skill or ability.
To add to your "this is wrong": These others may have themselves solved the problems we are now trying to solve, likely even using a journal. They no longer need a journal since they know how to navigate it, and it appears as superior to us.
This was the biggest revelation in grad school for me, I think.
The professors were in fact not gods of problem solving, they just had the answers. Not just of the problems they brought along (obviously). But also of the handful of problems we’d tend to invent. Of course, if you really catch them flat-footed, they can provide circumspect and sagely advice, and then quickly check Wikipedia to see if anyone has solved your problem.
I mitigate this "problem" somewhat by taking pride in specialized yet (hopefully) readable notations and sometimes even creative tool usage. Like using a project planning tool with a Gantt chart feature to speed up a boot process with many dependencies.
Of course, sometimes an existing tool or notation used for its original purpose is what you need. Maybe manually remove the stuff that doesn't matter.
I write a lot of notes in fact I write more than I read. It helps. However I have some issues:
1. How much commentary should I write? I try to write not too many notes because I write code, and some say code should be self-documenting. So it's the same old question of how many comments should there be along the code.
2. How do I retrieve a note I've written earlier? I can use tags and search for them but it is not easy to come up with a perfect tag which I would remember later.
3. I have so many notes and by now many of them are out-of-date. I don't want to spend time updating my notes. But if I don't they can become misleading.
There needs to be a balance between "Just do it" and "Write about it". I'm not sure I have the correct balance between those two.
I can see an alternate approach which would be a FORUM where co-workers discuss what they are doing or plan to, or have done . But there too the retrieval might be a problem. However the FORUM-tool would automatically keep track of when something was written and by whom. NOTE: You might benefit from other people's notes just as you can from your own.
> 1. How much commentary should I write? I try to write not too many notes because I write code, and some say code should be self-documenting. So it's the same old question of how many comments should there be along the code.
I think the best I've heard this was by a friend who said something akin to this;
Programming is the art of solving problems by codifying complexity. Generally, the self documenting part is the 'defining the problem' portion of the code. But in every problem, there's a certain amount of irreducible complexity, or it wouldn't be a problem.
There's going to be some part of the code where you wish you could make it simpler, or you wish you understood it better, or you wish you could break it down into smaller components but there's no 'good way' to do it in the system you're working in. Or, the way you have working is 'good enough' and it's not worth the investment from some (business needs angle) in making it any better.
This is the portion of the code you should comment, and document, and do so liberally and in detail.
It is just folders and markdown so it is ultra portable, but the obsidian editor has tons of useful features like a graph view, autolinking, and a plugin in for anything you can think of.
There are tons of YouTube videos and articles describing different organizing systems and ways to use it.
I write but never reread. The act of writing helps me organize my thoughts. Maybe I'll reread the last page when coming back to something but that's it.
So my advice is to write when you have a lot on your mind so that you can get it out of your mind. That's it.
Don't mess around with forums. That's for a different problem.
Keep a pen and paper handy always. There can be no barrier to entry or it breaks the flow.
It really depends on your work. If you're doing mundane work, keeping notes is just busywork and doesn't really have a payoff.
But if you're constantly trying to solve novel problems, and have episodic ideas that are half-baked, writing notes -- without trying to organize them first -- can be really powerful. For me, I just write them in Logseq and tag them with a few hashtags like #topic1 #topic2 #topic3. It doesn't have to be a perfect tag, just tag it with all the topics you think are relevant.
From time to timeI click a hashtag and revisit all my half-baked ideas -- periodic revisits and curation is key -- I surprise myself when some peripherally connected notes coalesce into a real idea. (Logseq makes this easy because each note is bullet point that can be tagged, and clicking on a tag is like running a query)
This is called the Fieldstone method. (conceptualized by Gerard Weinberg). It's a very useful approach for writers because it recognizes that the best ideas are episodic and don't all come at once, you have to gather the "stones" over a long time before something gels.
Keep trying. Try different methods. What works for me debugging and refactoring distributed systems may not work for you. The thing I tend to drive toward is a single page mind-map-like artifact that is monotonically increasing in density with a focus on system-of-record and data flow. I tend to keep notes about individual tech and important systems in whatever tools are handy, either locally or in a form that are accessible to the team. Often this takes the form of a JIRA page per topic, or an nvAlt note per topic. Tickets aren't great for this because they are ephemeral. These notes are where code snippets, error messages, anything searchable, go. I have something like the Zettlekasten[1] method in the back of my mind when deciding on scope of these support notes. However I may also start from a simple local text file, not committed to the repository, or even attached as a note to a ticket or other ephemeral trigger. But the thing that ties it all together, for me, is that mind map. Once I have that I can truly reason about the system.
> a balance between "Just do it" and "Write about it"
This is the key point - capturing, organizing and retrieving notes has a cost. And I find myself always paying for notes out of my "just do it" budget. Especially when virtually all of the things I'm working on (notebooks, libraries, applications, planning documents) are themselves a form of writing, having yet another place to scatter my thoughts is not helpful at all. It's much more productive to take that thought and put it directly into the project documentation where everyone can benefit. More README, less journal.
I think you need to have a clear separation on what you're trying to achieve. From what you've written, I get the sense that you're combining documentation, wiki and your personal notes together.
For example, code documentation is very subjective. I'd combine code comments with readmes and potentially a separate wiki. All depending on the complexity of it.
For personal notes like reminders or thoughts, there's no need to keep it up to date. It's ordered by date. And when I need it, I roughly remember when I wrote it. If something needs to be updated? Write a new entry today. I use pen and paper for this. This is also where I sketch one-off diagrams and the like.
Separately, I also have a personal wiki for things I learn or teach among other things. Since these are limited in numbers and are quite important, keeping them up to date is not a big task
> 2. How do I retrieve a note I've written earlier? I can use tags and search for them but it is not easy to come up with a perfect tag which I would remember later.
I’ve been seriously considering using Logseq for this reason.
When I first started with Obsidian I used it that way, but the more I put in it the more I started organizing everything. It became less of a journal and more of a repository for long form stuff.
I’m thinking about using both just so I have a dedicated tool just for the journaling side of things.
I use Emacs Org Mode with Org Roam for journaling. I’ve customized it extensively to fit my workflow, but there is a risk. Unlike paper, in Emacs there’s a potential distraction lurking around every thought, every entry, even every keystone. I’ve tried going to paper many times to mitigate the risk, but it never sticks. I’m too far down the hole and habituated to change. But if I were starting over, I would choose paper and stay with it. When journaling, you want no distractions. Nothing beats paper.
Same here. I began using Obsidian when looking for something to drop my collection of Markdown notes into, which was somewhat of an improvement due to the quick search, tags and links, but not life-changing. I tried the Kanban plugin but gave up after a while. Then I read about the MOC concept[0] and started with topic-based index pages using the `dataview` plugin for generating lists of backlinks. Haven't looked back (yet)!
You could also create an index of MOC pages with the same plugin and making sure each MOC have a `#moc` tag, for example by using templates. Then write a query that lists all pages with the `#moc` tag.
For pure TODO lists, I'm a happy user of Taskwarrior since more than a decade.
I use different editors for different purposes, e.g., Obsidian for long form and planning, OneNote for meetings.
I wouldn't overthink it, though, and just use the simplest tools available. I use Sublime Text 3 with a few shortcuts to add the current timestamp, etc. and log everything in a long file. I was too ambitious in the past and wanted to learn how to use Emacs for everything, but it just held me back, and I ended up without any notes.
I believe it cuts both ways. Writing things down allows you to dump state so that you can make other complex calculations with your working memory. Then, learning to hold more complexity in your head increases your mental bandwidth using the same amount of external state available. Rinse and repeat.
Experience looks like intelligence to us because we didn’t see the hours our favorite instructors and mentors spent banging their heads against their own notebooks, haha.
It is the rare instructor or mentor that takes pains to NOT show off their expertise, and model the expected behavior, tools, and techniques of the learner where they are at. It is the classic problem of telling someone the goal, but not how to get there. A common error-mode is repeating "the magic" over and over again, expecting it to sink in; it takes extra effort to decompose the magic into teachable, practicable parts. This teaching effort requires meta-cognition and empathy orthogonal to the effort required to become an expert, which is why expert teachers are a rare and precious gift.
I sometimes write to document my thoughts - but just as often I write in order to discover what I think. Sometimes it's like the writing is the thinking.
Also, I love Obsidian. It became more useful when learned to stop overdoing it with exploring the endless plugin options, settled on a favorite few, and now mostly write in the daily note, occasionally extracting things to dedicated devnotes which in turn have chronological timestamped entries (and bidirectional links to the corresponding DNs). Highest possible recommendation to find a tool / workflow that suits you, and leverage it.
By clearly visualizing your mental model, you can more easily identify and address any gaps or missing elements, leading to a more complete understanding.
What finally got this to stick for me was abandoning all notion of structure and organization (and formal concepts like “logging” and “journaling”) and optimizing fully for capture over retrieval, then relying on search tools and proximity for the latter.
I have the OneNote icon in the notification area configured to create a new quick note and use it liberally. Occasionally I look through all the pages, especially the recent ones, aggregate and reorganize some, move others to an “archive” tab, and that’s it.
The faintest - and most disorganized - ink is more powerful than the strongest memory.
I’ve found a lot of success going one step further giving up on retrieval all together. I use either a new text file every time (which I never open again) or a physical notebook page (which I never refer back to). I get so much value from the act of writing itself.
Same. I just bought a scanner which I intend to use to scan and OCR my notes so that I can finally shred the mountain of paper I have. But I know I won't read the digital copy either so I'm not sure why I'm bothering. I guess it's the next step to putting it completely out of mind.
It took me a couple years to realize this too. For the past five years I abandoned all structure. I use a literal log file. Chronological from top to bottom, with paragraph breaks for each workday. Higher than necessary verbosity, no points taken away for spelling or grammar mistakes.
I basically do this, too. One big text file. My twist that makes it work for me is a slightly modified text editor that I only use to edit this file.
That way I’ve got a dedicated dock icon and context just for writing notes, but no other overhead. It’s important to me that it not feel like a product, and search works effortlessly (although subject to typo misses).
My only tweak on the text editor is a shortcut to insert a timestamp and a chunk of new lines, which I do periodically so I can separate moments in time and see what I was working on when, how I fixed something, etc.
I used obsidian for a while, but for my purposes it felt like work to organize and get “right”. I ended up writing a script to join all the files into one.
I use something like this too, I will say it's helpful to have some simple command to append text to it so you can do it automatically, and then an extra little bit so if it's your first append of the day it adds the date. Sometimes I know something happened on a date and if you're just using paragraph breaks to separate it's harder to find but if you know it was related to this meeting on that date a few months ago you can go straight to it.
I've also been doing this for ~30 years. My current job's journal is 17,581 lines long. It's just a file I edit in screen (so I can attach to it from multiple machines) with a line with the date on it and then a sentence for every thing I've done that day.
It is super helpful when we notice something strange has been going on since a specific date. I give my coworkers access to it and we will regularly refer back to it to try to figure out what was going on on a particular date. I also use it monthly to summarize for my 1:1 meeting with my boss.
I also have a Kindle Scribe e-notebook that I use for my daily todo list. The writing experience with the Kindle is very good, in that it's very paper like, but the access and retrieval is pretty meh. I described it to my coworkers as: It's exactly like paper, only more expensive. I'm basically doing bullet journaling of my tasks, things I need to circle back with coworkers about, and stuff to chat about over lunch or shows people have recommended.
> abandoning all notion of structure and organization ... optimizing fully for capture over retrieval, then relying on search tools and proximity
I did this too - obsidian's daily note feature is fantastic, and you can extract out pages from it if you want/need to dedicate a document for a specific thing. Since it's just markdown, search is quick - and being able to use regex if I need to is awesome. The graph view, showing connections between notes is great if you create notes on specific subjects, and link them together, or pull sections out to explain more in depth - but it's not really that necessary unless you're building your own knowledgebase, which like all documentation suffers from rot over time.
As long as your note-ing tool supports a good enough search that you can find things again, then I think it doesn't really matter what you use - as you said, writing it down is the important part.
I decided to use ChatGPT as my journal when they made it so they wouldn't be training on my data. Was talking to it all the time anyway, now I can pull the export whenever and just vectorize the whole thing... timestamps and all.
i never read the change logs, so just found out the concept of daily notes it looks pretty cool and might be what i need. Do you use any other templates?
I use the Obsidian TimeStamper plugin with a nice shortcut (Ctrl + .), and then just have an append-only log of thoughts that each start with a timestamp on its own line. I'll throw in a tag or two if I'm motivated (#tickets/DEV-1234) and create a new file every month (e.g. 2024-07).
It makes it very easy and fast to just switch to Obsidian and do a brain dump before lunch / end of day, or any time a thought hits me.
This is the way. I’ve used zettelkasten, which is similar philosophy. Dump a thought and tag it for retrieval later. I prefer making this work with simple files and markdown. I have a colleague who uses email drafts well. My problem with OneNote and similar is the bloat of it. But, having images alongside text, when needed, is super nice.
I use GitHub Issues threads for this and it works amazingly well.
Any task I'm working on has a GitHub issue - in a public repo for my open source work, or a private repo for other tasks (including personal research).
As I figure things out, I add comments. These might have copy pasted fragments of code, links to things I found useful, quoted chunks of text, screenshots or references to other issues.
I often end up with dozens of comments on an issue, all from me. They provide a detailed record of my process and also mean that if I get interrupted or switch to something else I can quickly pick up where I left off.
I tried following this idea from simon (first via discord channels) about 8-9 months ago and now zulip, I used zulip "streams" as the "github issue" here. Worked very nicely for me.
I use it for everything and not only work journal, this creates a small problem.Since I dump both future references and worklogs, and I have ~50 channels, it's very easy to not get back to things and only get back to it when needed(which is the idea mentioned by OP). It seems like a feature than a bug at first but after capture, one round of review after some time interval really helps. It took a while but slowly seeing the benefits.
For that I plan to write some bot to re-organize the worklogs and the reference/other things dump to my own email at the end of the week and then I can create something like https://simonwillison.net/tags/weeknotes/ for myself(private) to go though at the end of the week. I think it would be perfect for me.
That's interesting, but aren't you concerned about using a proprietary service for this? I would hesitate to be at the mercy of a corporation for such a personal workflow.
I do worry about that. I've been meaning to setup an automated export of my issues to protect against that situation.
My protection for now is nepotism: I know enough people at GitHub that I'm confident I could use back channels to recover my account if I ever need to.
It's surprising how many devs are trying to overoptimize for productivity with various fancy tools and techniques, when it actually comes down to simple basics.
Here is what I rely on as a founder who does a lot of context switching:
- a never-ending text file for todos and work journal [0]
For the never-ending text file for todos and work journal, I've found great success with org-mode, especially since deadlines automatically end up in my calendar with org-agenda. The outline format of org-mode is quite nice and it took all of 1 day to learn the key commands for making / manipulating the outline, creating links, and cycling through TODO states (using Doom emacs made the start super easy since I already know vi and didn't have to also learn the text editing commands).
I've also found the concept of an "inbox" from the Zettelkasten method very helpful. Anytime something comes up that's not yet in my system, I add it to the inbox for later processing (org-capture on my computer, and beorg on my phone). This way, note entry doesn't require a full context switch. I then just make sure to regularly drain my inbox.
I don't use emacs currently for anything but org-mode but I'm far happier with this than I was with a never ending `.md` file.
I just use a editor plugin to make marking tasks as done/cancelled easier and rotate the files every month to keep things a little organized (and scoping the keyword search) and it has been the most effective form of project management/journalling for me for many years.
How do/would you use it over various systems? What's the best way to cloud sync this? One might have to use it on work machine with restrictions around installing apps.
As long as auto-revert-mode is on (so the editor notices synced changes from other devices), you can sync it using any file storage service: Dropbox, iCloud Drive, Resilio Sync, etc.
I like having a "devlog.md" file for each project/repo.
The log is jut a reverse chronological order of comments/todos/rants.
I have mapped on VSCode cmd+shift+I to write a timestamp. Whenever I want to write something I just insert a timestamp at the beginning of the bullet-point list and write it out. This is stored alongside the repo.
It is particularly useful for recovering in the morning where I was the night before.
Along the same lines, I also find it useful to have a text log for each sizeable task I undertake. This could contain anything, notes of module structure, code & data snippets for testing, everything!
Like one of the top comments mentions, it acts as a node of knowledge within a wider system (graph) and I end up revisiting these logs more often than you would expect! It only gets better as you explore/document more and edges form.
Yea, for me what really helped is once I interned at a hydraulic engineering company and I was tasked with debugging a custom software for pump modeling/optimization in GIS.
I had no background in C++ or the GIS I was dealing with and this was a one-off thing that was built for a project, but not maintained or documented at all.
The lead eng that wrote the software also had a long and detailed personal log of what he was working on. He just gave me that.
It helped a lot to understand not only how the software worked, but also the design decisions.
To me the hardest part of journaling (or Pomodoro, or whatever work-related methodology/hack) is to stick with it. I have a work journal. I abandoned it and came back, then abandoned it and came back again. It's an endless back-and-forth.
To those who keep doing this for a longer period: Any tips would be appreciated.
We often need consistency and time to build up habits that stick.
I do everything including my own personal side projects in a work journal with time tracking for everything, but I had to work up to it being a natural part of my workflow.
Here's my suggested path to gaining these habits:
1. Initially just try to make sure you are taking SOME notes at the start or end of every day
- it doesn't matter where they are or how they are formatted just always take some notes at the start or end of your day
2. Once you have gotten into the habit of taking daily notes, start figuring what kinds of things you need notes for most often and take those before or during those activities
- for example if you often find yourself having to look back at work tickets to retrieve some important information, start adding that information to your notes
3. By the time you are taking daily notes and adding things you know you need notes for you probably have a lot of notes so start worrying about structure and formatting
- for example maybe you decide text files with homegrown markup aren't going to scale and you look into something like Obsidian with Markdown or Emacs with Org-mode
4. Repeat iterations of using your chosen note taking methods daily, building good habits, and improving your note taking system for you
- if it feels like something is taking more time than it is worth change how you are doing it so it takes less time or just stop doing it
I have my journal available within my editor, so it's easily accessible. I find that once I've seen how useful past-notes have been its very apparent I need to update.
I keep a standard set of headers for each new entry:
I copy/paste that header to the end of the file, and just fill out stuff as I go. I used to have my editor auto-open the diary on startup, but took that away in the end.
I had the same problem because it was serving no purpose.
What really worked for me is to make it a primary tool of work. Rather than sometimes writing what I did today, whenever I work on something somewhat involved, I immediately write my approach about it ("I need to do X so I started Y").
Accept that that is how it works for you. Like, maybe you do different types of work and subconsciously find it useful only for some of them. That's OK.
Consider it a tool you sometimes use, and think of using journaling as an option when you're frustrated with something.
My forcing function was external. I was getting randomized by a lot of tasks and I felt I wasn't getting anything done. So I started to break down my day into 30 minute chunks. This got the feedback loop of seeing things get done going.
I also started to take notes about projects, other teams' working, notes from internal documentation etc. This has allowed me to retrieve some things super quickly to the point my teammates have been amazed. Another way to get the dopamine hit going.
Long story short: my brain is a primate, it needs dopamine hits, find a way to make your intended behavior give you dopamine hits.
Gustave Flaubert said, "be regular and orderly in your life, so that you may be violent and original in your work." Perhaps we who strive to be regular and orderly in our work should accept a little chaos in our life.
On the other hand, perhaps we simply need better external anchors for our habits. I have been journaling on-and-off for years. Environments change, people change, and my schedule changes. What got me back into it this time was joining a Shut Up and Write™ meetup. That broke the seal, and I've been sporadically journaling to de-frag in the weeks since.
I think you need to go past this common thinking to "just focus on consistency/habits/discipline". You need to get clear about how/why you decide in the present moment. I assume this takes varying amount of time/effort for different people.
I think one needs to unravel our inner state and psychology ... we cannot simply turn on and off. But then, once we understand our inner state/psychology it makes it easier to turn on/off.
I have a cron job that opens my note app - a few times every day. The app is focused in the foreground, opened on the top of a journaling note, pre-filled with the today's date. All that's left for me is to write.
The technique of journaling as you work is sometimes called “interstitial journaling” and I became a big fan of it as a way to help focus as well as keeping track of what I was working on.
I made a tool to associate those notes with a color coded project and timestamp:
It ended up being unintentionally similar to an invoicing time tracking tool a freelancer might use but the use case Im interested in is more personal productivity.
Can’t say the project has generated much interest outside my own personal use but I find it very nice to track notes as I go and then easily see how much time I spent on a given project. You can also add a #hashtag in the notes and then filter by that hashtag in the calendar view.
Completely free in case anyone else finds it helpful!
Readit News
Perhaps the greatest barrier to using it is akin to envy. We see others who apparently do this without written materials, in their head. I think we see this as evidence of intellectual superiority and harbor the doubt that using an aid like a journal means we are somehow lacking in skill or ability. This is wrong. Using an aid to map out complex problems isn't a failure, it's essential, especially for problems in systems you've never used before. Over time you may yourself build up your expertise such that you no longer need the aid, but that doesn't signal anything about your intelligence or ability either, only your experience.
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.
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.
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.
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.)
If you’re working on a particularly complex frame, how do you maintain context?
Another is to write a temporary commit log, with "WIP" in the first line and a TODO list in the rest of the log. This is good for ephemeral information that would just clutter up the code.
If I do need something like a journal, I have occasionally just written a private gist and put that in a tab on my browser.
To add to your "this is wrong": These others may have themselves solved the problems we are now trying to solve, likely even using a journal. They no longer need a journal since they know how to navigate it, and it appears as superior to us.
The professors were in fact not gods of problem solving, they just had the answers. Not just of the problems they brought along (obviously). But also of the handful of problems we’d tend to invent. Of course, if you really catch them flat-footed, they can provide circumspect and sagely advice, and then quickly check Wikipedia to see if anyone has solved your problem.
Of course, sometimes an existing tool or notation used for its original purpose is what you need. Maybe manually remove the stuff that doesn't matter.
1. How much commentary should I write? I try to write not too many notes because I write code, and some say code should be self-documenting. So it's the same old question of how many comments should there be along the code.
2. How do I retrieve a note I've written earlier? I can use tags and search for them but it is not easy to come up with a perfect tag which I would remember later.
3. I have so many notes and by now many of them are out-of-date. I don't want to spend time updating my notes. But if I don't they can become misleading.
There needs to be a balance between "Just do it" and "Write about it". I'm not sure I have the correct balance between those two.
I can see an alternate approach which would be a FORUM where co-workers discuss what they are doing or plan to, or have done . But there too the retrieval might be a problem. However the FORUM-tool would automatically keep track of when something was written and by whom. NOTE: You might benefit from other people's notes just as you can from your own.
I think the best I've heard this was by a friend who said something akin to this;
Programming is the art of solving problems by codifying complexity. Generally, the self documenting part is the 'defining the problem' portion of the code. But in every problem, there's a certain amount of irreducible complexity, or it wouldn't be a problem.
There's going to be some part of the code where you wish you could make it simpler, or you wish you understood it better, or you wish you could break it down into smaller components but there's no 'good way' to do it in the system you're working in. Or, the way you have working is 'good enough' and it's not worth the investment from some (business needs angle) in making it any better.
This is the portion of the code you should comment, and document, and do so liberally and in detail.
It is just folders and markdown so it is ultra portable, but the obsidian editor has tons of useful features like a graph view, autolinking, and a plugin in for anything you can think of.
There are tons of YouTube videos and articles describing different organizing systems and ways to use it.
So my advice is to write when you have a lot on your mind so that you can get it out of your mind. That's it.
Don't mess around with forums. That's for a different problem.
Keep a pen and paper handy always. There can be no barrier to entry or it breaks the flow.
But if you're constantly trying to solve novel problems, and have episodic ideas that are half-baked, writing notes -- without trying to organize them first -- can be really powerful. For me, I just write them in Logseq and tag them with a few hashtags like #topic1 #topic2 #topic3. It doesn't have to be a perfect tag, just tag it with all the topics you think are relevant.
From time to timeI click a hashtag and revisit all my half-baked ideas -- periodic revisits and curation is key -- I surprise myself when some peripherally connected notes coalesce into a real idea. (Logseq makes this easy because each note is bullet point that can be tagged, and clicking on a tag is like running a query)
This is called the Fieldstone method. (conceptualized by Gerard Weinberg). It's a very useful approach for writers because it recognizes that the best ideas are episodic and don't all come at once, you have to gather the "stones" over a long time before something gels.
https://www.amazon.com/Weinberg-Writing-Fieldstone-Gerald-M/...
I've used it with great success over the years (both at work and in my writing).
1 - https://zettelkasten.de/introduction/
This is the key point - capturing, organizing and retrieving notes has a cost. And I find myself always paying for notes out of my "just do it" budget. Especially when virtually all of the things I'm working on (notebooks, libraries, applications, planning documents) are themselves a form of writing, having yet another place to scatter my thoughts is not helpful at all. It's much more productive to take that thought and put it directly into the project documentation where everyone can benefit. More README, less journal.
For example, code documentation is very subjective. I'd combine code comments with readmes and potentially a separate wiki. All depending on the complexity of it.
For personal notes like reminders or thoughts, there's no need to keep it up to date. It's ordered by date. And when I need it, I roughly remember when I wrote it. If something needs to be updated? Write a new entry today. I use pen and paper for this. This is also where I sketch one-off diagrams and the like.
Separately, I also have a personal wiki for things I learn or teach among other things. Since these are limited in numbers and are quite important, keeping them up to date is not a big task
Dead Comment
Feed them all to an LLM?
When I first started with Obsidian I used it that way, but the more I put in it the more I started organizing everything. It became less of a journal and more of a repository for long form stuff.
I’m thinking about using both just so I have a dedicated tool just for the journaling side of things.
You could also create an index of MOC pages with the same plugin and making sure each MOC have a `#moc` tag, for example by using templates. Then write a query that lists all pages with the `#moc` tag.
For pure TODO lists, I'm a happy user of Taskwarrior since more than a decade.
[0] https://obsidian.rocks/quick-tip-quickly-organize-notes-in-o...
I wouldn't overthink it, though, and just use the simplest tools available. I use Sublime Text 3 with a few shortcuts to add the current timestamp, etc. and log everything in a long file. I was too ambitious in the past and wanted to learn how to use Emacs for everything, but it just held me back, and I ended up without any notes.
Also, my unfortunately named thread from 2022: https://news.ycombinator.com/item?id=33359329
Also, I love Obsidian. It became more useful when learned to stop overdoing it with exploring the endless plugin options, settled on a favorite few, and now mostly write in the daily note, occasionally extracting things to dedicated devnotes which in turn have chronological timestamped entries (and bidirectional links to the corresponding DNs). Highest possible recommendation to find a tool / workflow that suits you, and leverage it.
Creating and maintaining the taxonomy is another thing but not too bad.
Dead Comment
I have the OneNote icon in the notification area configured to create a new quick note and use it liberally. Occasionally I look through all the pages, especially the recent ones, aggregate and reorganize some, move others to an “archive” tab, and that’s it.
The faintest - and most disorganized - ink is more powerful than the strongest memory.
That way I’ve got a dedicated dock icon and context just for writing notes, but no other overhead. It’s important to me that it not feel like a product, and search works effortlessly (although subject to typo misses).
My only tweak on the text editor is a shortcut to insert a timestamp and a chunk of new lines, which I do periodically so I can separate moments in time and see what I was working on when, how I fixed something, etc.
I used obsidian for a while, but for my purposes it felt like work to organize and get “right”. I ended up writing a script to join all the files into one.
It is super helpful when we notice something strange has been going on since a specific date. I give my coworkers access to it and we will regularly refer back to it to try to figure out what was going on on a particular date. I also use it monthly to summarize for my 1:1 meeting with my boss.
I also have a Kindle Scribe e-notebook that I use for my daily todo list. The writing experience with the Kindle is very good, in that it's very paper like, but the access and retrieval is pretty meh. I described it to my coworkers as: It's exactly like paper, only more expensive. I'm basically doing bullet journaling of my tasks, things I need to circle back with coworkers about, and stuff to chat about over lunch or shows people have recommended.
I did this too - obsidian's daily note feature is fantastic, and you can extract out pages from it if you want/need to dedicate a document for a specific thing. Since it's just markdown, search is quick - and being able to use regex if I need to is awesome. The graph view, showing connections between notes is great if you create notes on specific subjects, and link them together, or pull sections out to explain more in depth - but it's not really that necessary unless you're building your own knowledgebase, which like all documentation suffers from rot over time.
As long as your note-ing tool supports a good enough search that you can find things again, then I think it doesn't really matter what you use - as you said, writing it down is the important part.
I use the Obsidian TimeStamper plugin with a nice shortcut (Ctrl + .), and then just have an append-only log of thoughts that each start with a timestamp on its own line. I'll throw in a tag or two if I'm motivated (#tickets/DEV-1234) and create a new file every month (e.g. 2024-07).
It makes it very easy and fast to just switch to Obsidian and do a brain dump before lunch / end of day, or any time a thought hits me.
Very true words. Thank you.
Any task I'm working on has a GitHub issue - in a public repo for my open source work, or a private repo for other tasks (including personal research).
As I figure things out, I add comments. These might have copy pasted fragments of code, links to things I found useful, quoted chunks of text, screenshots or references to other issues.
I often end up with dozens of comments on an issue, all from me. They provide a detailed record of my process and also mean that if I get interrupted or switch to something else I can quickly pick up where I left off.
Here's a public example of one of my more involved research threads: https://github.com/simonw/public-notes/issues/1
I also create a new issue every day to plan the work I intend to get done and keep random notes in. I wrote about how that works here: https://til.simonwillison.net/github-actions/daily-planner
I use it for everything and not only work journal, this creates a small problem.Since I dump both future references and worklogs, and I have ~50 channels, it's very easy to not get back to things and only get back to it when needed(which is the idea mentioned by OP). It seems like a feature than a bug at first but after capture, one round of review after some time interval really helps. It took a while but slowly seeing the benefits.
For that I plan to write some bot to re-organize the worklogs and the reference/other things dump to my own email at the end of the week and then I can create something like https://simonwillison.net/tags/weeknotes/ for myself(private) to go though at the end of the week. I think it would be perfect for me.
https://GitHub.com/irthomasthomas/undecidability/issues
The code that runs it is here:
https://GitHub.com/irthomasthomas/label-maker (how it started/how it's going:)
There’s usually a lot more issue comments than commits as I just add a comment to the issue while I “work it out”.
New problem? New issue.
New insight on that problem? Comment.
And so on…
My protection for now is nepotism: I know enough people at GitHub that I'm confident I could use back channels to recover my account if I ever need to.
Here is what I rely on as a founder who does a lot of context switching:
- a never-ending text file for todos and work journal [0]
- calendar for planning (and blocking focus time)
- website blocker
- turned off notifications
[0] https://news.ycombinator.com/item?id=39432876
I've also found the concept of an "inbox" from the Zettelkasten method very helpful. Anytime something comes up that's not yet in my system, I add it to the inbox for later processing (org-capture on my computer, and beorg on my phone). This way, note entry doesn't require a full context switch. I then just make sure to regularly drain my inbox.
I don't use emacs currently for anything but org-mode but I'm far happier with this than I was with a never ending `.md` file.
I just use a editor plugin to make marking tasks as done/cancelled easier and rotate the files every month to keep things a little organized (and scoping the keyword search) and it has been the most effective form of project management/journalling for me for many years.
The log is jut a reverse chronological order of comments/todos/rants.
I have mapped on VSCode cmd+shift+I to write a timestamp. Whenever I want to write something I just insert a timestamp at the beginning of the bullet-point list and write it out. This is stored alongside the repo.
It is particularly useful for recovering in the morning where I was the night before.
Like one of the top comments mentions, it acts as a node of knowledge within a wider system (graph) and I end up revisiting these logs more often than you would expect! It only gets better as you explore/document more and edges form.
I had no background in C++ or the GIS I was dealing with and this was a one-off thing that was built for a project, but not maintained or documented at all.
The lead eng that wrote the software also had a long and detailed personal log of what he was working on. He just gave me that.
It helped a lot to understand not only how the software worked, but also the design decisions.
To those who keep doing this for a longer period: Any tips would be appreciated.
I do everything including my own personal side projects in a work journal with time tracking for everything, but I had to work up to it being a natural part of my workflow.
Here's my suggested path to gaining these habits:
1. Initially just try to make sure you are taking SOME notes at the start or end of every day
2. Once you have gotten into the habit of taking daily notes, start figuring what kinds of things you need notes for most often and take those before or during those activities 3. By the time you are taking daily notes and adding things you know you need notes for you probably have a lot of notes so start worrying about structure and formatting 4. Repeat iterations of using your chosen note taking methods daily, building good habits, and improving your note taking system for youI keep a standard set of headers for each new entry:
I copy/paste that header to the end of the file, and just fill out stuff as I go. I used to have my editor auto-open the diary on startup, but took that away in the end.What really worked for me is to make it a primary tool of work. Rather than sometimes writing what I did today, whenever I work on something somewhat involved, I immediately write my approach about it ("I need to do X so I started Y").
Consider it a tool you sometimes use, and think of using journaling as an option when you're frustrated with something.
I also started to take notes about projects, other teams' working, notes from internal documentation etc. This has allowed me to retrieve some things super quickly to the point my teammates have been amazed. Another way to get the dopamine hit going.
Long story short: my brain is a primate, it needs dopamine hits, find a way to make your intended behavior give you dopamine hits.
On the other hand, perhaps we simply need better external anchors for our habits. I have been journaling on-and-off for years. Environments change, people change, and my schedule changes. What got me back into it this time was joining a Shut Up and Write™ meetup. That broke the seal, and I've been sporadically journaling to de-frag in the weeks since.
I think one needs to unravel our inner state and psychology ... we cannot simply turn on and off. But then, once we understand our inner state/psychology it makes it easier to turn on/off.
I have a cron job that opens my note app - a few times every day. The app is focused in the foreground, opened on the top of a journaling note, pre-filled with the today's date. All that's left for me is to write.
One of the checklist items may be to journal.
The randomness is so that I actually follow through on the checklist and don’t gloss over it.
I made a tool to associate those notes with a color coded project and timestamp:
https://interstitch.app
It ended up being unintentionally similar to an invoicing time tracking tool a freelancer might use but the use case Im interested in is more personal productivity.
Can’t say the project has generated much interest outside my own personal use but I find it very nice to track notes as I go and then easily see how much time I spent on a given project. You can also add a #hashtag in the notes and then filter by that hashtag in the calendar view.
Completely free in case anyone else finds it helpful!
I've been using this prompt on myself, on and off, for years, but I keep on hallucinating and losing focus and going off track.