My trick for this, which has been working extremely well for me over the past few years, is to make very heavy use of GitHub Issues.
Everything I'm working on, no matter how small, starts as an issue.
I post a continuous stream of comments on that issue as I make progress - documenting what I tried, what failed, what I've figured out, what micro-decisions I've made.
Many of my GitHub repos, both public and private, have issues with dozens of comments, all of which are me just talking to myself.
This is the single best solution I've ever found to the "interruption" problem. If I get interrupted, or distracted, I can read through my issue thread later and pick up where I left off.
I do this same thing, but with a notes app instead of GitHub.
Sometimes I catch myself thinking about progress on a project as the process of moving my notes from one state to another, with the actual work I need to get done being a "side effect."
This (ie. using the github issues on the repo) is great because it co-locates the mental notes breadcrumbs, the todo list and the project itself.
I use org-mode for personal project management, and by design it intermingles notes and todos. But it never fully clicked until I started putting the notes closer and closer to my repo (my workflow pre-dates github, but this approach makes me consider some modernization :))
Interestingly, I actually did the opposite. I started with GitHub Issues as my note taking place, used that for several years. And then eventually moved away from it to Org Notes as a centralized system for all projects. Some of my reasons were:
- it's centralized; sometimes projects are related and being able to search for "all project notes involving LEDs" is useful across repos
- sometimes project work is not solely related to code, and in that case your notes are split between repo-notes and non-repo-notes
- Git issues build up and become huge threads over time, lack hierarchical organization or advanced state/dependency tracking, rely on arbitrary tags, etc.
- Git issues are non-personal, often public-facing - and even on personal repos there is sometimes the thought that you might publish the git repo one day, and now it's littered with your private thoughts.
- During dev, the process often is a bit experimental in nature - this amounts to tons of failed ideas or dead notes that clutter issue db
- Not a lot of support for the note-type distinction between "moonshot"-style rough ideas and actual concrete projects. If you use GitHub Issues for all your notes, you'll have all your wacky ideas mixed in with your actual issues. You'll subconsciously avoid posting the wild ones which means you'll subconsciously damper your creativity.
All of these lead me to suggest sticking with a well-designed centralized project note-taking system, use GitHub Issues to track /issues/ and then /link/ to the issue in your note-taking system (ideally with a little automation glue) or simply avoid GH Issues entirely for your personal issue tracking and work directly off of your notes system.
I've addressed many of those problems with a bunch of different tricks:
- I have a simonw/notes repo which will NEVER be public, which is for me to put issue threads in for things that aren't part of one of my other repos, or that I want to keep private. I sometimes change my mind and transfer issues out into other repos using this trick: https://til.simonwillison.net/github/transfer-issue-private-...
- I frequently run searches across every issue in my "simonw" GitHub profile, which covers both my public and private issue repos
- For tying issues together, I use GitHub Projects - which can contain issues from multiple repos in a single place. I use that for my personal TODO list, and for collaborations with other people that span multiple repos.
- I link issues together a LOT - if you add a "- #123" Markdown bullet point list in a GitHub issue comment it will turn each bullet point into a fully displayed link to the referenced issue, including its open or closed state.
- You can use this for checklists too: "- [ ] #123" will turn into a checkbox which automatically checks itself when the referenced issue is closed.
- I use GitHub labels for things like "Research" to mark issues which are longer running research things as opposed to active bugs or features.
GitHub is nice but starting about a year ago I have been asking myself "what if they lock me out of my account" for online services and there is no good answer.
Obsidian plus a data query plugin can do most of the stuff you've described but my data isn't at the mercy of a 3rd party, so that's what I go with.
Yeah, I worry about that too. I have SO much of my stuff dependent on my GitHub account now.
I'm slightly reassured by how useful their APIs are. I have automated exports of a lot of my GitHub issues, though I really should shore those up and make sure I'm capturing everything.
Everything I'm working on, no matter how small, starts as an issue.
I post a continuous stream of comments on that issue as I make progress - documenting what I tried, what failed, what I've figured out, what micro-decisions I've made.
Many of my GitHub repos, both public and private, have issues with dozens of comments, all of which are me just talking to myself.
This is the single best solution I've ever found to the "interruption" problem. If I get interrupted, or distracted, I can read through my issue thread later and pick up where I left off.
I wrote a bit more about this approach here: https://simonwillison.net/2022/Nov/26/productivity/
A recent example issue: https://github.com/datasette/datasette-enrichments-gpt/issue...