Most note systems don’t fail at writing. They fail at retrieval. You wrote the note, you remember writing it, and it still doesn’t come back when you need it. The fix is smaller than a new app: change what the index line says.
Why can’t you find the note you know you wrote?
Because you filed it under the word you knew after you solved the problem, not the word you’ll have before you solve it again. Topic labels are written from the answer’s side. Searching happens from the problem’s side. The two vocabularies rarely meet, so the note sits there, unfound.
This is the quiet tax on every personal knowledge system. The notes exist. The folders are tidy. And at 11pm, staring at the same error you already beat three months ago, you search two words, get nothing useful, and solve it again from scratch.
What does “index by symptom, not topic” actually mean?
A topic index line names the subject: “PowerShell encoding.” A symptom index line names the observable failure and the trigger: “Korean text turns into garbled boxes when a script writes a file.” Same note, same content. Only the retrieval handle changed — and the handle is the entire difference between a searchable archive and a graveyard.
The rule is simple: write the index line in the words you will have on the worst day, not the words you have on the day you understood it. On the worst day you don’t have the category. You have a symptom.
| Dimension | Topic-worded index | Symptom-worded index |
|---|---|---|
| Written from | What the note is about, in hindsight | What went wrong, as it appeared |
| Vocabulary used | Abstract nouns you chose after solving it | Literal words from the error, screen, or feeling |
| Matches your search when | You already remember the category | You only remember the failure |
| Typical failure mode | Five notes share the same noun; none is obviously the one | Less common — symptoms are usually specific enough to stand apart |
| Best suited to | Reference material you browse deliberately | Troubleshooting and practice you retrieve under pressure |
| Maintenance cost | Quick to write, harder to re-find | Slightly slower to write, much easier to re-find |
Note the honest limit: topic indexing isn’t wrong for everything. For material you browse — a reading list, a concept map, a syllabus — topics are the right shape. Symptom indexing wins wherever retrieval is triggered by a problem rather than by curiosity.
What did symptom indexing look like when I shipped software I couldn’t read?
I built and shipped working software without being able to read the code. The only method I had was to write down every point of failure the moment it happened. That produced a large pile of notes fast. It did not produce a usable system — until I rewrote the index lines from topic to symptom. Then the same pile started paying me back.
Here are index lines from that period, what they cost me at retrieval, and how I rewrote them.
| Topic-worded (before) | Retrieval failure it caused | Symptom-worded (after) |
|---|---|---|
| PowerShell encoding | I searched “broken Korean” and “garbled characters.” The note used neither word and never surfaced. | Korean text becomes garbled boxes when a script writes a file — set the output encoding explicitly |
| Deployment settings | I searched “build failed.” Nothing matched, so I re-diagnosed a problem I had already solved. | Build works locally but fails on deploy — the env var exists in the local file, not in the host dashboard |
| Auth notes | Several notes carried the word “auth.” I opened them one by one before finding the answer. | Every request returns 401 even though the token is correct — the header name is wrong, not the token |
| Database migration | I searched “migration error.” There was no error message, so the note didn’t match my memory of it. | Migration ran successfully but the app still sees the old columns — the schema cache is stale |
| Git config | I searched “wrong account.” The note said “config,” so it stayed buried while I repeated the mistake. | Pushed under the wrong identity — the repo inherited the global git user instead of a per-repo one |
The pattern in that middle column is the whole lesson. Every failure was a vocabulary mismatch, not a missing note. I had the answer. I just couldn’t say the magic word.
How do you write an index line that finds itself later?
Write the line before you write the note, while you still feel the problem. Describe what you saw, when it happened, and what you expected instead. Use the exact words from the error or the moment. Keep it to one sentence. Then, and only then, write the explanation underneath it.
- Lead with the observable. “App crashes when I upload a second file,” not “file handling.”
- Include the trigger. The condition is half the search: “…after the session has been idle for an hour.”
- Keep the ugly words. Paste the literal error string. Ugly text is high-signal search text.
- Add the surprise. “…even though the file is under the size limit.” Surprise is what you’ll remember.
- One symptom, one note. Two symptoms in one note means one of them will never be found.
- Test it once. Search the phrase you’d actually type in a panic. If your note isn’t near the top of the results, the index line is still written from the answer’s side.
What does the research say about why this works?
Memory research has a name for this. Retrieval succeeds when the cue you use at search time overlaps with the information encoded at storage time — the encoding specificity principle, formalized by Tulving and Thomson in Psychological Review (1973). A topic label encodes your post-solution understanding. Your search encodes your pre-solution confusion. They don’t overlap.
- The cost has been estimated. The McKinsey Global Institute’s report The Social Economy (2012) estimated that knowledge workers spend roughly 19% of the workweek — about a day out of five — searching for and gathering information. It’s an estimate from survey data, not a measurement of your desk.
- Vendor surveys point the same direction. Workplace-search reports from search vendors such as Coveo routinely find that a large share of employees have recreated work they couldn’t locate. Treat vendor figures as directional rather than precise; the sponsor benefits from a large number.
- You are a bad judge of your own future confusion. The “curse of knowledge,” described by Camerer, Loewenstein and Weber in the Journal of Political Economy (1989), covers exactly this: once you know something, you can’t reconstruct not knowing it. Which is precisely the state you’ll be in when you search.
So the symptom line isn’t a style preference. It’s a deliberate way of writing a cue for a version of yourself who knows less than you do right now.
How does this connect to tracking work that has stalled?
The same principle governs unfinished work. I keep an open-items ledger as the single source of truth for anything stalled, and every item is tagged by what it’s blocked on — a decision, another person, an external reply, or me. That tag is a symptom label, not a topic label.
The payoff is immediate. Items blocked on a single one-line decision are the cheapest progress available, so they get cleared first. A ledger organized by project would never tell me that. A ledger organized by blocker tells me what to do with fifteen spare minutes.
Two rules keep it honest, both learned the hard way after leaving a 26-year career and having to rebuild — from nothing — the deadlines, review, and noticing that an institution used to supply:
- Work in progress is capped at two started items per project. A backup scan once turned up 41 tasks abandoned mid-flight. Ideas stay unlimited; only starting is rationed.
- Abandonment is maintenance, not failure. Anything untouched for 30 days is surfaced weekly as a discard candidate, and most of them get discarded. A list you don’t prune stops being believed, and a list you don’t believe is worse than no list.
What do you do when a note still doesn’t surface?
Don’t rewrite the note. Rewrite the index line, using the exact phrase you just failed to find it with. Your failed search is free data about your own future vocabulary — it’s the best index line you’ll ever get, handed to you at the precise moment it matters most. Add it and move on.
Over time this compounds. Each miss makes the next hit more likely, because the system is being tuned by real retrieval attempts instead of by your imagination of them. That’s the actual difference between a note pile and a knowledge system: not volume, not tooling, just whether misses feed back in.
Where should you start today?
Take ten index lines you already have. Rewrite each one as the symptom that would send you looking for it. Don’t reorganize the folders, don’t migrate apps, don’t buy anything. Ten lines is enough to feel the change, and it’s one sitting, not a project.
This is the small version of the formula I keep coming back to: Belief × Thinking × Action. Belief that your past self already solved this. Thinking clearly about how your future self will search. And the action — one line, rewritten — that connects them. Any of the three at zero, and the product is zero. A perfect note nobody can find scores exactly as well as no note at all.
If you want that loop to run on your goals rather than just your notes, the VisionDream app turns goals into daily habits, which is the same idea applied to intention instead of information. And if you want the longer story of rebuilding after a career ends, it’s in the book Why Do I Fail While Others Succeed?
Your notes don’t need to be smarter. They need to answer to the words you’ll actually have on the day you’re stuck.