The Note-Taking System That Survives Contact With a Busy Week

You have probably done this cycle: read about a note system, spend a weekend setting it up, feel excellent about it for eleven days, then hit a week with three deadlines and never open it again.

That is not a discipline failure. It is a design failure. Most systems are designed for the version of you with a calm Tuesday afternoon, and they break under the version of you with forty minutes between meetings.

Why the popular systems fail

Elaborate folder hierarchies fail because filing requires a decision, and decisions cost energy you do not have when you are busy. Any system where saving a note requires choosing between six plausible locations will be abandoned under load.

Pure tagging fails in the other direction. With no structure at all, you get a pile. Tags are excellent for retrieval and terrible as the only organising principle, because you will tag inconsistently across months and never notice.

Daily notes alone fail because everything becomes chronological. Chronology is great for capture and useless for "what do I know about Postgres indexes?"

Systems requiring daily review fail for the obvious reason. Any maintenance ritual that must happen every day will be skipped, and once you skip three days the backlog becomes an obstacle instead of a habit.

The structure that holds

Four places. That is it.

inbox/      — everything lands here, no decisions required
notes/      — one file per idea, flat, no subfolders
projects/   — one file per active thing with a deadline
archive/    — things that are done or dead

The thing that makes this work is that capture requires zero decisions. Everything goes to inbox. You never think about where something belongs at the moment you are writing it, because that is exactly when you have the least capacity to decide.

notes/ is flat on purpose. You will want subfolders. Resist it. The moment you have notes/tech/databases/postgres/, you have reintroduced the filing decision, and you have guaranteed that half your Postgres notes end up in the wrong branch. Flat plus search plus links beats hierarchy at every scale below roughly ten thousand notes, which you will not reach.

Filenames do most of the work

The single highest-leverage habit is writing the filename as a claim, not a topic.

Bad: postgres-indexes.md Good: partial-indexes-beat-full-indexes-for-soft-deletes.md

A topic filename tells you a note exists. A claim filename tells you what it says. When you are scanning forty files six months later, the difference is enormous — you can answer most questions from the file list alone without opening anything.

This also forces you to actually conclude something. A note that cannot be summarised as a claim is usually a note that has not finished thinking.

The weekly pass, not the daily review

Once a week — and genuinely, once a week is enough — open inbox and do three things:

1. Delete aggressively. Most captures were useful for ten minutes and are dead now. Delete them without guilt. The value was in writing them.
2. Promote the survivors. Anything still interesting gets a claim-style filename and moves to notes/.
3. Link one thing. Pick a single note and connect it to one other note. Not all of them. One.

That last step is the whole system. Over a year, one link per week gives you a genuinely connected set of notes, built with almost no effort. Trying to link everything gives you a burnout and an empty folder.

If you miss a week, nothing breaks. The inbox is just longer. That resilience is the entire point.

What to actually capture

The failure mode of most people who take notes is capturing too much — highlights from books, article clippings, meeting transcripts. Volume feels productive and produces a landfill.

Capture things that meet one of these bars:

• Something surprised you. Surprise is the signal that your model of the world was wrong. These are the notes that pay off.
• You worked something out. A debugging conclusion, a decision and its reasoning, a why-we-did-it-this-way. Future you will need the reasoning and will not remember it.
• You will need the exact details. Config that took an hour to get right, a command with seven flags, the specific version that fixed the bug.

Do not capture things you can look up in thirty seconds. Do not capture things because they seem important in general. A note is only valuable if there is a plausible future moment where you would search for it.

Choosing a tool (briefly)

This matters far less than the structure, so here is the short version:

• Obsidian if you want local plain-text files, backlinks, and control. Best default for most people. Your notes are markdown on your disk, which means no tool can take them hostage.
• Notion if your notes are mostly collaborative or database-shaped — tracking clients, content calendars, structured records. Worse for thinking, better for tables.
• Apple Notes / Google Keep if you are honest with yourself that you will only ever capture, never organise. This is a legitimate choice and it beats an elaborate system you abandon.
• A folder of .md files and ripgrep if you are technical and want something that will still work in twenty years. Genuinely viable.

The migration cost between plain-text tools is low, which is a good reason to start with plain text. The migration cost out of a proprietary database is high, which is a good reason to think twice before building your life inside one.

The test

Here is how you know a system is working: you searched it, and it answered something.

Not "I have 900 notes." Not "my graph looks impressive." Did you go looking for something, find it, and save yourself real time? If that has not happened in a month, your system is a hobby, not a tool — and the fix is almost always writing better filenames and capturing less.