Back to blog
8 min readMay 26

The hard drive fallacy: why second brains fail, and what recall-first actually looks like

Storage is solved; retrieval isn't, which is why most second brains end up as guilt objects rather than thinking partners that brief you in the morning.

TL;DR: Most second brains fail because they treat knowledge like a hard drive: save now, hope to retrieve later. The fix is recall-first, a system that reads what you save and pushes connections at you, the way Glen Rhodes describes in his May 2026 piece on knowledge systems that actually work.

You spend a Saturday afternoon building it. A Notion workspace with nested databases. An Obsidian vault wired up with backlinks. A bookmark folder that promises this time you'll go back and read it. By Wednesday of the following week, you've stopped opening it. By the month after, the thing has become a guilt object: a monument to a version of you that was going to be more organized.

The tool isn't the problem. The mental model under the tool is the problem. Glen Rhodes calls it the hard drive fallacy, and once you see it, you can't unsee it.

What is the hard drive fallacy?

In his May 2026 essay, Glen Rhodes puts it directly: "We treat personal knowledge management like we're building a hard drive. Write it down. Store it. Retrieve it later. That model works fine for passwords and meeting notes. It fails completely for engineering knowledge, because useful engineering knowledge is not retrieval. It's pattern recognition."

Read that twice. The hard drive model assumes the hard part is storing the bytes. For passwords, yes. For a kept receipt or a meeting agenda, sure. But the knowledge that actually moves your work forward isn't a file you go open. It's a half-remembered paper on distributed consensus that resurfaces at 2am when you're staring at a timeout you can't explain. That connection does not live in a folder you decide to browse. Folders are inert. They wait.

The contrast is sharp: passwords need storage, engineering insight needs a system that recognizes when an old note becomes newly relevant. Rhodes draws the line between retrieval and pattern recognition, and that line is the whole article.

Why does capture beat surfacing every time?

The default architecture of every popular knowledge tool is capture-then-wait. Notion gives you a beautiful database; you have to walk in and pull. Obsidian gives you graph view; you have to ask it a question. Bookmark managers, highlight apps like Readwise, and even thoughtful note systems all share that same arrow direction: in, then nothing.

Rohit, quoted in Rhodes's piece, says it more cleanly than most product specs do: "It should brief you every morning with the connections you missed. Instead it captures everything and surfaces nothing."

You can feel the cost of one-way capture in your own behavior. You stop saving things when saving feels like throwing them down a well. You save anyway, out of guilt, then stop opening the well, also out of guilt. Two months in, you're back to googling the same Stack Overflow answer for the fourth time, because the well never offered it back.

Rohit's morning-brief test is the cleanest benchmark for whether a tool counts: if it never briefs, it never beat the bookmark folder.

What does a recall-first system actually do?

Rhodes lists three properties that separate a system from a graveyard.

First, capture has to be nearly frictionless. If saving takes longer than ten seconds, you will stop. This is not a discipline problem, it's a physics problem.

Second, the system has to do something with the material. Not just index it. Read it, summarize it, find the line that connects to last week's note about retries, and hold onto that line.

Third, there has to be a regular push. A morning brief. A weekly digest. Something that says: you read this paper in February, you're working on a latency issue now, here is the paragraph that might matter.

That third property is the one most setups never get to, because building it requires the system to reason over your notes rather than just store them. A plain vault can't. A vault with Claude running over it, as Rhodes notes, starts to. So does any tool whose default loop is read-and-respond rather than write-and-wait.

Where the tools you already use fall short

Notion is a category-defining workspace, and the database model is genuinely powerful: you can build a CRM, a doc site, and a tracker in the same surface. The cost is exactly that flexibility. Every workspace wants a schema decision before you've saved anything, and the schema decisions compound into setup debt. You end up maintaining the database instead of using it.

Obsidian is the engineer's love. Local files, plugins, the graph view that looks like proof you are thinking. The honest tradeoff: the graph is decorative until you build a review habit around it, and most users never do. The connection from "I saved a thing" to "I encountered it again at the right time" is left as an exercise for the reader.

Readwise solves capture for highlights elegantly and ships a daily review email, which is closer to the right shape than most. The gap is that highlights without surrounding context decay quickly, a problem worth its own write-up. A snippet stripped from its argument is hard to recompose six months later.

Notion's database flexibility, Obsidian's graph view, and Readwise's daily review email are real strengths. None of them was designed to be the system that briefs you on the connection you missed.

What changes when memory pushes back

A recall-first setup inverts the loop. You save in ten seconds or less. The system summarizes what you saved, anchors it to the moment it arrived, and quietly cross-references it against what you've saved before. When you sit down to work the next day, something hands you the relevant paragraph before you knew to ask for it. The folder doesn't wait for you to remember. The system remembers for you.

This is also the part where pure local file vaults run out of room. Reading and connecting requires a model that can read. A vault of markdown files is a fine substrate, but on its own it doesn't push. Pairing it with a model that does, or moving to a tool whose default behavior is the push, gets you to the shape Rhodes is describing. The same pattern shows up when you compare quick notes apps to systems that hold context across time.

If you want to see what this looks like as a product rather than a stitched-together setup, dEssence is one option. It's built around the recall-first idea: you save through the Chrome extension, Telegram bot, or the web app at dessence.ai, and the archive is meant to be read back to you rather than browsed. The honest tradeoffs: it's in beta, free during beta with no card, but the paid tier isn't finalized. There's no native mobile app yet, and no team or shared-collection features. If you want a polished, paid, settled product today, this isn't it. If you want to feel what memory-that-pushes feels like before the rest of the category catches up, a week with it is enough to tell.

The deeper point, the one Rhodes lands on, is that the failure mode isn't laziness or the wrong template. It's the wrong mental model. Fix the model first, then the tool choice becomes obvious. Memory that pushes back is the recurring theme across every product trying to do this honestly, regardless of the surface.

Frequently asked questions

Why do most second brains fail within a month?

The capture is easy and the recall is hard. Most setups solve the easy half and ignore the hard half. After a few weeks you stop opening the vault because opening it doesn't return anything useful, and the loss compounds: you stop saving too, because saving feels like throwing material into a place you never visit.

Is Obsidian or Notion the better second brain?

Both are good at storage and neither is good at recall on its own. Obsidian is friendlier if you like local files and plugins. Notion is friendlier if you want shared workspaces and databases. Either becomes a recall-first system only when you bolt a reading-and-summarizing model on top, and both require an explicit review habit you'll have to build yourself.

What does "recall-first" actually mean in practice?

It means the system reads what you save and surfaces it back to you when relevant, rather than waiting for you to remember to open a folder. The defining behavior is a push: a morning brief, a weekly digest, or an inline connection while you're working, anything that puts the right paragraph in front of you without a search query.

Do I need to migrate everything from my old notes app?

No. The hard drive fallacy is about the model, not the file count. Start by capturing new things into a recall-first surface for two weeks and see whether anything gets surfaced back. If it does, you've validated the model before you migrate. If it doesn't, you've saved yourself a migration.

Is dEssence a replacement for Notion or Obsidian?

Not yet. It's a focused web product in beta with three save surfaces and no team features. If your second brain is a shared workspace with databases and docs, stay where you are. If you mostly want a personal archive that talks back, dEssence is built for that shape.

This article was inspired by glenrhodes.com's piece on why most second-brain knowledge systems fail engineers.