There’s a specific kind of frustration that comes from opening a note you wrote six months ago and finding something like: “Check the thing with the thing, see notes from Tuesday.” You wrote it. You were there. You had full context. And now it’s completely useless.
This happens to developers, writers, project managers, researchers, anyone who takes notes with the intention of doing something with them later. The common diagnosis is that people need better apps, better systems, more discipline. The real diagnosis is that most people don’t understand what makes a document readable by someone who wasn’t there when it was written, including yourself.
Context Is the First Thing That Rots
When you write a note, you’re not writing everything you know. You’re writing a compressed pointer to everything you know. “Talk to Sarah about pricing” contains, for you in that moment, about fifty other facts: which Sarah, which project, what the pricing problem actually is, why it matters, what outcome you want from the conversation. You don’t write those facts down because you don’t need to. They’re in working memory. They’re obvious.
Six months later, those facts are gone. What remains is the pointer, pointing at nothing.
Software engineers deal with a version of this constantly. A commit message that says “fix bug” tells you nothing useful when you’re trying to understand why a piece of code looks the way it does. A comment that says // this is important raises more questions than it answers. The developer who wrote it knew exactly what they meant. The developer reading it six months later (often the same person) has to reverse-engineer the intent from context clues they may or may not have.
The underlying failure is the same: the author confused the map for the territory. They wrote down the pointer and assumed the thing it pointed to would still be there when someone needed it.
The Half-Life of Your Own Memory
Human memory doesn’t degrade uniformly. The emotional residue of an experience tends to persist longer than the specific details. You remember that a meeting was frustrating long after you’ve forgotten what was actually said. This creates a trap for note-takers: you write notes immediately after something happens, while the emotional context is vivid, and you assume that context will carry the meaning of the notes forward in time. It won’t.
Research on memory consolidation (particularly work building on Ebbinghaus’s forgetting curve) suggests that detailed episodic memory, the kind that would let you reconstruct the context around a note, decays significantly within days. What gets written down in shorthand on Monday is genuinely mysterious by the following Monday, let alone six months later.
This is why the note-taking advice to “write as if explaining to someone else” is actually correct, even though it feels like overkill in the moment. You’re not writing for a hypothetical stranger. You’re writing for yourself after the forgetting has happened. That future version of you is functionally a stranger to the context you currently inhabit.
What Readable Notes Actually Look Like
There’s a structural difference between notes that survive time and notes that don’t, and it’s not about length or detail. It’s about whether the note contains the reasoning, not just the conclusion.
A note that says “use Postgres, not MongoDB” is fragile. A note that says “use Postgres here because we need transactional consistency across the order and inventory tables, MongoDB was considered but rejected because of the join patterns in the reporting queries” is readable by anyone, including future-you, including someone who joins the team two years later.
The same principle applies outside engineering. “Call vendor about contract” is a dead end if you don’t remember which vendor or what the contract issue was. “Call Stripe about the per-seat pricing clause in section 4.2, which may conflict with our reseller agreement” is something you can act on cold.
This isn’t about writing novels in your task manager. It’s about including one layer of reasoning below the surface claim. Why does this matter? What was the alternative? What would someone need to know to understand this decision without asking you? Answer those questions briefly, and the note survives.
Code comments are a useful mental model here. The worst comments describe what the code does (which you can read from the code itself). The best comments describe why the code does it that way, what alternatives were considered, and what would break if you changed it. The same logic applies to any document you’re writing for retrieval rather than for reading straight through.
The Tool Is Not the Problem
A significant part of the productivity software industry is built on the premise that if you just had the right app, the right organizational schema, the right tagging system, your notes would become useful. Notion, Obsidian, Roam Research, and a dozen other tools have all been positioned as solutions to this problem. None of them solve it, because the problem isn’t organizational. It’s compositional.
You can have perfectly tagged, beautifully linked, hierarchically organized notes that are still useless because each individual note contains only a compressed pointer to knowledge you no longer have. The organization helps you find the note. It does nothing to make the note readable once you’ve found it.
This is worth pushing back on firmly, because tool-switching is the most common response to the problem and the least effective one. The person who migrates their notes from one app to another every year is usually doing it to avoid confronting the fact that they haven’t changed how they write notes. The new app feels like a solution because it’s clean and empty. Within months, it’s full of the same inscrutable shorthand.
Writing for Retrieval Is a Skill
The fix is mundane and requires discipline: when you write something down, add one sentence of context. Not a paragraph. Just enough to answer “why does this matter” or “what was the situation when I wrote this.”
“Investigate rate limiting on the API” becomes “Investigate rate limiting on the payment API, we’re seeing 429 errors under load on the checkout flow, likely need exponential backoff or a queue.”
“Finish proposal” becomes “Finish proposal for the Q3 infrastructure migration, stakeholder deadline is the 15th, the main open question is whether to migrate staging first.”
You can do this in five seconds. The habit is cheap. The payoff is that your future self can actually act on what you wrote without reconstructing context from scratch.
There’s a deeper principle here that applies beyond personal notes. Any artifact you create, a design document, a postmortem, a Slack message that someone will screenshot and share, will be read by someone who wasn’t in the room. Writing as if the reader has no context isn’t defensive or pedantic. It’s just accurate modeling of how communication actually works across time.
The document you can’t read isn’t a failure of memory. It’s a failure of authorship. The version of you who wrote it didn’t do the work of making it useful. Future-you is paying the cost. The correction is small and the benefit compounds in ways that are hard to appreciate until you open a six-month-old note and actually understand what it says.
