Zettelkasten for Engineers: Why and How I Use It
Niklas Luhmann published 70 books and 400 articles in 30 years using a paper filing cabinet. That fact gets repeated so often it has lost its edge, so here is the part that matters: the Zettelkasten was not an organizing system. It was a thinking system. Luhmann described working with it as "a conversation with the archive."
For engineers, the problem was never a shortage of information. The problem is that technical knowledge decays.
Three problems at once
Engineers carry three knowledge problems simultaneously, and they compound.
Decay. What you learned about Kafka consumer groups and their rebalancing edge cases in 2023 has evaporated by 2025. Without indexing, it is as if it never happened.
Re-invention. With no record of why we discarded that approach, the same decision gets made again eight months later — often arriving at the same conclusion by the same expensive route.
Fragmentation. Knowledge scatters across Slack, Confluence, PR comments, and the heads of specific people. No navigable source of truth.
What a Zettelkasten actually is
Each note is one atomic idea, written in complete prose, connected to other notes. Categories emerge from the connections instead of being decided in advance.
The distinction that separates it from conventional filing: you do not archive information in a Zettelkasten. You restate it in your own words, connect it to other ideas, and let the emergent links guide your thinking. The effort of restating is where the learning happens — which is exactly why copy-paste produces nothing.
Why Logseq
I evaluated the obvious alternatives before settling.
- Obsidian — excellent, but critical plugins sit behind paid Sync, and the native query story is weaker.
- Roam Research — the precursor to outline-based ZK, but expensive and your data isn't on the filesystem, which limits portability.
- Notion — a great hierarchical wiki, and the hierarchy is precisely the problem. It isn't built for emergent connections, and it locks you in.
I chose Logseq because it is outline-based, so every block is linkable; it has a native graph view and Datalog queries; and it stores plain .md files on the filesystem, which means git-versionable, portable, no lock-in, free and open source.
Zettelkasten vs. wiki — the difference that matters
A wiki asks you to choose the category before you write. The structure is top-down, and it tends to become a dead archive the moment the project shifts. You search it, which requires already knowing what you're looking for.
A Zettelkasten lets categories emerge from connections after you write. The structure is bottom-up and each note stands alone. You navigate it, and you discover links you didn't know were there.
Both are worth having. Wikis are good for project documentation — READMEs, ADRs, runbooks. A Zettelkasten is for accumulated personal knowledge that outlives any single project. Confluence answers "what does the system do." The Zettelkasten answers "what have I learned about systems."
The four note types
- Fleeting — quick capture in the daily journal. Raw ideas, links, fragments. Disposable. Does not need to be correct.
- Literature — knowledge extracted from a source, always with a
source::. Summarized in your own words, never pasted. - Permanent — one atomic idea in complete prose, comprehensible with no external context. This is the heart of it. Slower to write, lasts years.
- Structure (MOC) — a map of content. Not a content note but an index: it lists the notes in a cluster rather than explaining the topic itself.
Four rules that keep it alive
- One idea per note. If a note covers two distinct concepts, it is two notes. The test: the title should capture the whole idea in a single sentence.
- Write as if the reader has no context. The note must make sense without knowing where you came from. This forces clarity of thought more than any other rule.
- Add at least two connections to every permanent note. Connections are the actual product. A note with none is isolated knowledge.
- The journal is capture; the permanent note is distillation. Never promote a draft without reformulating it.
What you gain and what it costs
You get a navigable technical memory that does not decay, emergent patterns that hierarchical wikis hide, and — a pleasant side effect — articles that write themselves, because every permanent note is already a draft.
You pay for it with 10–20 minutes per permanent note, and with the persistent feeling that you should be coding, not writing. Without discipline the journal grows and the permanent notes never get written.
How it fails
"The ZK became an inbox." The journal fills up and permanent notes never appear. Symptom: many fleeting notes, few permanent ones. Fix: process the journal weekly — convert or discard.
Notes that are too long. A note with twenty bullets under "key ideas" is probably five notes. Any idea that deserves two or more distinct connections deserves its own note.
Stale MOCs. The structure note stops reflecting the cluster. Fix: update it as part of closing out each session.
What I actually learned
The best permanent notes come from questions, not statements. "Why Proxmox and not VMware?" produces a better note than "Proxmox features."
And the graph tells the truth about what you know. Dense clusters are real domains. Isolated nodes are information, not knowledge.