How I record tech notes using the Zettelkasten method

Tech notes work best when they’re built as an interconnected “slip box” of small, single-idea entries—so new information becomes searchable, reusable, and easy to act on without rereading long documents. The Zettelkasten method behind this approach treats notes as tools for thinking: fleeting observations and learning snippets get transformed into permanent notes that link to related concepts, creating multiple entry points into knowledge. That matters in tech work because the bottleneck is rarely collecting information—it’s finding the right context fast enough to debug, onboard, or make consistent decisions.

The system starts with three layers. Fleeting notes capture one small idea immediately—often from reading, watching, or noticing something during work. Literature notes come from learning sources like books, tutorials, or videos; they preserve context and partial insights while the idea is still forming. Permanent notes are the “processed” layer: each entry should capture a single idea, be understandable on its own, and link to other notes to maximize discoverability. The method also uses index notes as top-level entry points that define topic boundaries—useful when someone new needs a map of where things fit (for example, what “React coding guidelines” include, and what they don’t).

In practice, the notes are tailored to real tech tasks. Coding guidelines are used to standardize team decisions without turning them into one-person diktats. When reviewing pull requests, anti-patterns or inconsistencies become prompts for new notes, which then guide future reviews and help new developers learn the project’s conventions—especially when the team uses a stack like React plus TypeScript. DevOps notes break down complex pipelines and infrastructure concepts (Kubernetes, Docker, Jenkins, Nexus, and more) into linked mini-tutorials so people can understand “what depends on what” without getting lost in top-down documentation. Technical playbooks focus on operational entry points: how to debug an app, how backups work, and what to check first when something breaks.

The workflow emphasizes writing for cold readers. Notes assume someone may not know key terms (like Jenkins) and therefore should include short explanations, mini-tutorial steps, and links that point to the most relevant supporting details—such as where credentials are stored (e.g., a Vault) or how to add an admin user. Each note should cover one key goal; “add user” and “remove user” belong in separate entries so the search path matches the question. The approach also discourages heavy folder hierarchies because tech concepts cut across domains (an S3 backup policy might involve IAM, namespaces, and a specific backup system). Instead, a single searchable list plus strong linking keeps knowledge from getting stranded.

For tooling, the workflow centers on Obsidian (local Markdown notes with double-square-bracket linking) and VS Code for coding-focused work, with optional plugins such as Foam for knowledge mapping. Examples show how coding guidelines become index notes with linked sub-notes, while a DevOps “playbook” project uses topic notes and question-driven entries to guide onboarding and troubleshooting. The setup advice is to start small, document one area you need right now, build organically, and leave placeholders for incomplete notes so the system grows as understanding improves—turning scattered learning into an actionable archive.