GitHub flavored markdown will format a list like this:
1. [X] Dockerfile
2. [ ] Bulk Inference
3. [ ] CLI
4. [ ] Logging
1. Trello with columns for the week, month, and quarter, year.
2. Open notebook next to mouse
2a. Left page: daily todo checklist with pen and paper. (2-3 rows per day)
2b. Right page: scratch, sketches of plots, sticky notes, etc.
3. Typed dev journal to capture research, URLs, papers, thoughts, ideas, progress, and extensions. (every github project has a dev/ folder for these notes, filename yyyymmmdd-n.txt) New file per project per day, as needed.
4. Yellow sticky notes for ad hoc ideas (end up on the bottom of the screen, notebook or whiteboard). Typically maxims to keep me pointed in the right direction for a project (e.g. "no one ever will rtfm")
5. Whiteboard, column per project, printouts + magnets (monthly plots of project progress), sticky notes, ideas for future projects, all kinds of stuff
I try to overcommunicate with my future self. It helps to get my current thoughts straight re expectations, progress, sticking points, etc. I'm the roadblock, not the work. The work is typically paint by numbers after a "hard think" about it.
Working like this solo for 8 years.
Been using a /dev dir and .txt files for live development journal since my PhD days in early '00. Saved my ass countless times (grep).
Oh, and doing the same things every day. Mostly. E.g. customer support, then promote, then writing, then code, then... No thinking required, just do the next thing we do after this...
https://tom.preston-werner.com/2010/08/23/readme-driven-deve...
My project is a suite of programs for managing livestock and rare breed registries. So I have Farm Mobile (Android), Farm Desktop (Python), Registry Web (Flask) and Registry Desktop (Python) apps and the Database schema (SQLite) all as separate GitLab repos.
I now have 3 additional collaborators and we now share the Obsidian vault via Obsidian Sync. My solo system scaled to handle teamwork.
- Monthly goals are very high level and few (e.g. “Make PoC for this”, “Redesign and relaunch blog”)
- Weekly goals are more tangible and limited (e.g. “Settle on approach for calling Rust from Swift code”, or “Finish design and styling of posts”)
- Daily are very concrete (e.g. “Set up UniFFI pipeline to generate Swift bindings” or “Implement new theme across blog pages”)
Sometimes things come up that I discover during implementation, and then I typically shift a daily goal to the next day.
Has worked well so far for giving me focus, and I then pick the daily goals based on the weekly focus from the list of many open tasks/issues I have in my various projects.
I set up each thing I’m working on as a Project in e.g. Linear, and immediately add a priority when I add things, which allows me to easily keep an overview of many smaller or larger projects I might have going on or want to do in the future.
While I do like paper, for me that’s only for ephemeral things. I prefer to keep things digital, allowing me to easily add stuff from my phone in the go when I get an idea while being out-and-about. I also write much faster on a keyboard and use the various tasks as the dumping ground for info while I’m working through something or researching something.
Next time I open the code editor I know exactly what to do.
Each bullet is a goal of the project, and then I split it into sub goals and problems, and keep notes as I go. One thing that really helped was the soft rule of only allowing leaf nodes to be actual tasks, everything else has to be a problem or goal. If it turns out a leaf node needs to be split up further, I gotta re-formulate it as a goal/problem.
Also, I try not to work on anything before I've written it down first. Since I've been doing this, it's easier than ever to come back to a project after not working on it for a while. I've always thought that people write things down to remember them, but for me at least it seems that it helps me forget and free my mind for other things.
It's important to me that the software supports infinite bullet nesting. I use Dynalist but there are other good ones out there, I'd love to switch to RemNote actually.
What's in the file?
<Project Name> Log File
-------------------------------- WORKING ON NOW
<move whatever task you are working on to this space>
-------------------------------- TO DO
- <start each task with a dash>
- <indent related sub-tasks or notes>
-------------------------------- IDEAS
<free-form notes>
-------------------------------- RESOURCES
<free-form resources>
-------------------------------- DONE
<move anything that's done into this section>
<timestamp if desired>
It's a long road, I've hesitated much since for me it was a slow full migration to Emacs and EXWM at the same time than another step moving most of my configs to org-mode notes, tangle-ed from them and finally org-attaching files.
One part still left behind is literate programming though, I do for something, but not for most of the thing, since I tend to disperse myself in lengthy prose, loosing focus on the code and the available tooling inside org-babel blocks are limited/hard to use respect of a direct-code codebase.
Make a list of all the stuff you need to do.
Prioritize it.
Move the top item to the doing list and start working on it.
When you’re done move it to done. Take the next item off the to do list and repeat.
I use other lists on trello to maintain cards for my research or to move features off the to do list that aren’t necessary for v1.
- It's close to the code, so I can easily make notes to self with links to line numbers, copy-pasted code blocks, or linked draft PRs to remember where I left off with something that I'm going to punt on for a while.
- It's super easy to access from any device, so I can quickly create an issue for something on the fly on my phone/non-dev machine when I have an idea or get an email about a bug.
- It's straightforward to bring someone else in and have them working on something right away, when the time is right.
- There's a good API and lots of integrations (like creating issues directly from/linked to an error tracking system)
Reminds me of org-mode in Emacs - overall, I'm really liking the cross-platform sync and Markdown interface out-of-the-box.
I thought that producing a bunch of trello style cards to look at would help and it kind of did, but in practice I don't seem to look at them as often as the raw markdown.
YMMV though, my solo work is a weighted random walk in the direction of things that look interesting, not an optimal shortest path to a product. Which might be the sidetracked you're talking about. E.g. I'm currently writing a regex engine and that's not especially well correlated with where I was a few months ago.
2. A dated piece of paper in front on my desk that tells me what to do right now.
3. A GitHub Projects kanban for software-related tracking.
Github Projects are sufficiently minimally functional, even if strangely broken and unloved. There are a lot of things that you would think would be automated. Things like rolling over to a new sprint with a couple of clicks, instead of having to manually revise all the queries on your scrum board. But you can do what you want to do. And maybe that's better than having to live with the inflexibility of somebody else's idea of what process should be. In some ways, minimality might be an advantage.
A heart, this is a list management problem. And not a very complicated one. And Github Projects do lists perfectly well.
The one thing that recommends Github Projects over a paper-based or card-based task list is that it does provide public visibility to users as to how their bug reports and feature requests are being dealt with. And it's incredibly easy to take something brought up in a discussion board, and flip it over to a bug report, or development task (deferred or active).
Usual scrum rules apply. All bugs are fixed before working on new tasks. And tasks move to done status only when they are fully and completely done.
You need lists. I like sprint structure on top of tasks, because they provide a useful punctuation point for interim updates and continuous releases.
And tagged/prioritize project backlogs
And sane habits/routines :)
[0] https://www.dsebastien.net/tag/personal-knowledge-management...
- A pocket Moleskin notebook keeps track of random thoughts, notes, scratches, diagrams, and more.
- This eventually becomes either "tickets" in my issue tracker, or becomes "wikis" or "wiki updates" on my wiki server.
- This eventually leads to things like: snippets, configuration notes, historical documents, record keeping, runbooks, and more.
Eventually it just became "natural" to keep my documents up-to-date, or as issues are discovered get them thrown into the correct backlog.
So I have a daily template like this:
- Meetings (where I take notes about my meetings)
- Tasks (where I set the daily tasks, if there are unfinished tasks I can move them to the next day, but the idea is to set tasks that can be done in the same day)
- Notes (any quick notes that doesn't deserve a full page, like quick annotations)
Then for more long text I use Notes.app or Bear.
So for example, I might sit down as the overall business leader and decide a strategic direction I want to take. I then put on my product manager hat and decide what to build. I'll then project manage and prioritize those ideas. Then I'll become product manager / designer and spec out the features I prioritized. Then I'll sit down completely separately (usually it's own day) and develop a feature. Once it's released, I'll put on my marketing hat and do any relevant product marketing. That's sort of the lifecycle of developing a single feature.
I think what's dangerous is when you're jumping around all those roles at once. You can spin without being productive. There are times to be strategic, times to be creative, and times to just execute. You need different headspaces for those tasks.
I do all my planning in Notion, using a few different Kanban boards for different purposes.
Mobile app is also very very good which means you can easily update or use it to make tickets while on the go...or in bed.
Everything that needs to be done goes in, no matter how small.
Every now and then I work through and sort it by most important. I also group tasks that are about the same importance and in the same area of code.
Then just work on the task at the top.
I have a separate text file for life and each project. Life comes first, pay bills, buy socks.
Then the text files are in Dropbox so available and editable anywhere.
Lists of projects I'm thinking about doing. Lists of things to do on the current project. Lists of bugs on a project.
Just scratch things off as I'm done. I like this method because I often want to draw a little sketch of something (like a UI element or quick flow chart) inside the list to remind myself of some aspect of the project/bug/etc. The freeform nature of pen + paper helps me remember things, having gone through a physical action of writing. I also find it much easier to go back to another project to look up something, because I remember doing it. I remember drawing something. I know, visually, what I'm looking for and every notepad I ever made is right there, immediately browsable.
"Works for me," as they say.
For example, for one early startup, while I was the only engineer, and operating in a somewhat reactive mode, I used GitLab Issues to track tasks, and their Structured Labels and Board view to give a modified Kanban-ish view.
For a different solo-engineering project, which nevertheless had lots of interdependencies, and needed some estimating, I used a Gantt-based tool (unfortunately not integrated with GitLab Issues, though it really-really should've been).
That's the tools part. What you might be missing is the social part. If that's bothering you, maybe find a way to get some human accountability, team feedback, etc., even if you're the only engineer. (I'm pretty self-motivated, but I'd do things like show the biz people milestones, achievements, funny or cool things, etc.)
In terms of managing the day to do, my project has 4 or 5 modules and each has its own TODO and README in markdown. The README is where I explore the design and the TODO is obvious.
You don’t need fancy tools, what you need is a vision that pulls you along.
Whenever I see something wrong in app I write it on my phone, on note taking app. Note taking apps allow you to have freedom in syntax and style.
Most of the problems, some I would like to communicate to eventual people interested in project, are written as github issues.
There is no prioritization. I do whatever I like. It is a hobby project, not a work project. I daily drive my app, so I know I need to fix it, whenever it breaks.
I do not like paper notebooks, as it would have too many crossed-out points. I like to 'edit' in place.
Small ones just get a todo.org file that I commit with the project.
For medium ones I put a .org file in my "Projects" directory in Dropbox.
For larger ones I put a subdirectory in my "Projects" directory in Dropbox.
I have Linear cycles and create tickets, projects and stories to keep track of things for future reference. It also helps with commit and linking of the tickets to PR.
For notes, use the Documents feature of linear and separate based on the projects
i use obsidian as a dump for things. i use boards in obsidian to track higher level product stuff + capture any fleeting todos/ideas as obsidian notes, then move that to github issues once i do project mgmt time. and i use obsidian for non-dev project management, like marketing/sales/operations stuff. i also use obsidian for todos like "do some project management for X features or whatever"
I don't think you can create that same force pure solo, but can still improve current process. One way could be to have a friend, sibling or virtual assistant that you do the same reporting to every few days. Perhaps pick someone assertive. And as you know, if you bullshit you just fool yourself. Hopefully something like that is a strong enough "forcing function" to snap you out of your tangent and back on track for a few hours/days before the next report.
on desktop i use a cli[1]. on mobile i use homescreen bookmarks to fastmail web.
body is typically empty. subject is the note. first word is the category.
most recent note: game deltas represent discrete positions on the 13bit ratchet
1. https://gist.github.com/nathants/53efd551e5eadfdbf5792b3efc3...
Have a bullet point for your long term goals and/or backlog. Have another for weekly plans. Dump what you need done into the backlog.
Break down the weekly plan into a bullet point per day. Have other bullet points on what you want to do that day.
You can move around bullet points as needed, but try to stick to them and undercommit for the day.
This of course only works at a desk. I've never done work on a laptop so my system is very YMMV.
Trello to track tasks driven by my strategy for each milestone (with some flexibility based on competitor analysis).
Without a strategy you're just drifting on the tide. It should underpin all your decisions and tasks.
I write each task as one line on it (if I need bigger notes I keep those electronically - typically in Apple Notes).
There's something very satisfying about getting to wipe tasks off as they get done :)
Pomodoro has been another thing that works well for me to split up my time/keep getting things done while making sure I'm taking frequent breaks.
I also use inline TODO comments, Excalidraw diagrams, and explanatory log text in release notes.
Organizing that: gitlab issues
* simple specific goals
* obsession with functional imperative architecture and DRY
Todo lines that I remove when done
When you don't need to share information, there's nothing better than a notebook to see all of your ideas spread out and iterated. No need to log into anything. Take it with you anywhere -- sit on a bench and ideate. Go to the gym and jot down ideas.
I can keep my daily goals in a checklist in there and just check them off 1 by 1. No need for GitHub projects or anything like that because there's no need to communicate status with anyone.