I don't find fixing things hard. I just hate fixing the same thing again.
Lately, I've been thinking about fixing the same in my personality. I seem to miss deadlines a lot, and I'm quite lazy. A simple habit tracker + log (a markdown file, lets say) would solve most of that. But I'd have to actually stick to it.
Despite my riff-raff introduction to what's called a personal knowledge base; it can be very powerful. It's more about the thing helping me not forget stuff, than about productivity or optimizing my daily schedule.
Why developers need this
Most knowledge management advice is written for writers or students. Capture your thoughts. Link your ideas. Build a second brain.
That's fine but developers have a more specific problem. You're switching contexts constantly — different projects, different stacks, different clients. You debug something at 11pm, write a one-line fix, commit, move on. A week later you need that fix again and have zero memory of how you fixed it.
The problem is very real. I spend days figuring out how to implement failure links for Aho-corasick, and somehow forgot how Aho-corasick worked in an interview. Happens to the best of us.
Things that disappear without a system:
- weird postgres query that solved N+1 problem on that one project
- commands to get a local SSL cert working
- why you made an architectural decision that now looks insane
- environment setup for a stack you revisit every few months
- deadlines (I've missed MCA proposal dates twice already!)
None of this is hard. It's just stuff that gets lost because you didn't write it anywhere.
What to actually capture
Don't log what you ate for lunch or what you were wearing when you did squats. That's how you end up building a system that feels like chores. You won't stick to it for a week.
Capture things in three categories:
Solutions to problems you hit more than once. If you googled something twice, write it down. CLI commands, config snippets, error messages with their fixes. The bar is: "would I be annoyed to look this up again?"
Decisions and their reasons. Why did you pick this library? Why did you structure the project this way? Future you — or a collaborator — will ask this. The code doesn't explain it, a comment doesn't survive a refactor, a Slack message disappears. A note survives.
Things you want to understand better. Papers, articles, concepts you half-understood. Not full summaries — just enough to remember what it was and why it seemed worth returning to.
That's it. You don't need to capture meetings, todos, or shower thoughts in the same place. Keep it technical and keep it searchable.
Obsidian (most common)
Obsidian stores everything as plain markdown files on your local machine. That's the whole pitch, really. No vendor lock-in, works offline, you own your data, it's fast.
Once you have lots of notes, you can link them to form Zettelkasten. It looks impressive. Has a fancy name. I don't use it.
What's actually useful in Obsidian:
- Quick switcher (Cmd/Ctrl + O): Jump to any note instantly by name. This is how you find things day-to-day.
- Backlinks: See every note that references the current one. Useful when a concept appears across multiple projects.
- Templates: Set up a blank template for code snippets, TILs, or debugging notes so you don't think about structure when you're in a hurry.
- Free forever for personal use. The paid Sync service is optional — you can just use Git or iCloud.
Plugins worth installing: Templater (better templates), Dataview (query your notes like a database if you want to get fancy), and Natural Language Dates. That's enough. Don't spend an afternoon installing plugins.
Frankly, I just use markdown and search within VS code. The repo is synced to github. That's all it takes.
Logseq
Logseq is similar to Obsidian but everything is structured as an outline — bullet points all the way down. Some find this more natural for daily notes and journaling alongside their reference notes.
The main difference: Logseq is block-based. You link to individual bullets, not just pages. This makes it very good for daily logs where you capture things in context ("on the Stripe integration, discovered that...") and want those to resurface when you open the Stripe page later.
It's also fully local and open source. The downside: it can feel slow on large vaults, and the UI is less polished than Obsidian.
Good choice if you want daily journaling and reference notes in one place. I found it too tedious. I see the value in this, but I'm too lazy to stick to it.
Foam (VS Code)
Foam is a VS Code extension that turns your editor into a lightweight wiki. You write markdown notes, link between them with [[wikilinks]], and it builds a graph — all inside the editor you're already in.
You never leave VS Code. Notes live next to your code. For a quick TIL or a project-specific note, this has very low friction.
The downside: it's minimal. There's no mobile app, searching across notes is just VS Code search, and it hasn't been maintained as actively as Obsidian.
Best for: developers who want something dead simple inside their existing setup, and don't care about accessing notes on mobile. I don't really care about the graph, so I don't use it either.
What about Notion?
Notion is great for shared documentation, project wikis, and anything collaborative. For a personal knowledge base, it's overkill. It's slower than a local tool, you need the internet, and the free tier has limits that become annoying.
If you're already a Notion user and your team is on it, there's no reason to add another tool. Just keep personal notes in a private section. But if you're starting fresh, a local-first tool is simpler.
You might love Notion. I don't.
A folder structure that actually works
You don't need a taxonomy before you have any notes.
Start flat. One folder. Everything goes in. After a month, patterns emerge and you can organize around what you actually have.
When you do add structure, something like this works:
/notes
/til ← today I Learned: short, atomic, one thing per note
/projects ← one folder per project or codebase
/references ← tools, libraries, languages — reference material
/inbox ← temporary, half-formed, stuff to revisit
Tags are better than folders for cross-cutting concerns. A note about a Postgres performance fix can live in /references/postgres but be tagged #debugging and #performance — that way it surfaces in multiple contexts.
Stick to: filename as the title, lowercase, hyphen-separated. postgres-n-plus-one-fix.md not Postgres N+1 fix (2024) FINAL.md. Or any format you want. It's better than hoping fuzzy search finds your note later.
Linking to your actual workflow
The system only works if adding to it has near-zero friction. If you have to open a separate app, navigate somewhere, think about where it goes — you won't do it.
A few things that help:
A daily note as the inbox. Most PKM tools support this natively. Every day starts with a blank note dated today. Anything you want to capture goes there first, unorganized. At the end of the day (or week) you move things that deserve a permanent home. This keeps the barrier to capture low.
Personally, I don't keep a daily note. Not within the technical capture system at least. I keep a paper notebook for journaling.
A template for code snippets. Something like:
## Problem
## Solution
## Source
## Tags
Muscle memory kicks in after a while and you stop thinking about the structure.
Git for backup. If you're on Obsidian or Foam, your notes are just files. A private GitHub repo means they're versioned, backed up, and accessible from any machine. The Obsidian Git plugin automates commits on a timer.
Final thoughts
I've tried a few systems. I built a habit tracker in C at one point — complete with deadlines, goals, todo lists, workouts. I used it for like a week. I use a notebook for journaling now and loose paper for todo lists.
The lesson: I'm lazy. I might find knowledge graphs fancy but keeping logs feels like a chore to me. I just stick to my notebook for collecting thoughts. Markdown for technical logs.
Whatever works for you is fine.
All tools mentioned are free for basic/ personal use.