For the past two years, I’ve used Obsidian as a knowledge vault.

Whenever I encountered something useful, I logged it. That came in many forms, such as:

• Documentation I read
• Errors I ran into
• Processes I completed
• Ideas I wanted to remember

I even had a rule for myself: if something I learned wasn’t in Obsidian, I hadn’t really learned it.

The appeal was obvious. I thought of note-taking as effort caching. If I spent an hour figuring something out, I could document it once and avoid spending that hour again in the future.

I also tried to make it as easy as possible to capture notes by having dedicated templates for different notes and structured forms to auto-populate them.

However, over time, I started noticing a problem.

I was becoming better at capturing information than retrieving it.

My vault now contains more than 4,000 notes. I have over 80 notes related to Next.js alone, covering things like documentation, cheatsheets, or how to implement certain functionalities. These include notes from reading the documentation, errors I encountered, processes I carried out, and various cheatsheets.

The problem is that those notes don’t always help when I need them.

I remember one time I was trying to figure out how to set up OAuth in a Next.js application. I searched my vault and found a lot of potentially relevant notes: some about NextAuth, others about Better Auth, and multiple notes about Better Auth itself.

Several of them contained overlapping information. Some referred to older versions of the packages. It wasn’t clear which note was the source of truth, or whether the integration details still applied to the version I was using.

Instead of saving me time, the vault created another problem: uncertainty.

I had to determine which notes were relevant, whether they were current, and how they related to one another. In the end, I just searched online for the latest version of the documentation.

That was when I realized that my notes had preserved evidence of my past learning, but they hadn’t necessarily preserved something I could trust in the present.

I had optimized for capture. I hadn’t optimized for retrieval.

I optimized for capture, but not retrieval

Capture is only potential value

Capturing information feels productive because it gives you a visible signal of progress. You read something, summarize it, and save it. The note exists, so it feels as if the effort has been secured.

But a note only creates potential value when it is written. That value is only realized when it helps you do something later.

If I can’t find the note when I need it, or if I find several conflicting notes and don’t know which one applies, then the effort hasn’t really been cached. I still have to rediscover the information myself.

In that sense, the usefulness of a note depends on more than whether it exists.

It needs to be discoverable. It needs to be relevant to the situation. It needs to contain enough context to be actionable. And for time-sensitive information, I need some way to know whether it is still current.

My OAuth notes failed on several of these dimensions. They were related to the topic, but not necessarily to the specific question I was asking. They overlapped with one another. They mixed different authentication libraries and versions. They captured information, but they didn’t help me confidently choose what to do.

The notes that actually save me time

Not every note in my vault has this problem.

I have a note for updating packages in a legacy codebase I work with. That note saves me a significant amount of time because it applies directly to a situation I encounter repeatedly.

The first time I updated the packages, I spent one or two hours figuring out the process. Now, when I need to do it again, the same task takes less than five minutes.

That note works because it is specific.

It describes a particular codebase, with its particular constraints and quirks. It captures the commands I need to run, the order in which I need to run them, and the problems I need to watch out for. I also know the title of the note, so I can retrieve it easily.

I don’t have to search for a vague concept like “package management.” I know that I need the package update process for that specific legacy project.

The note is not trying to be a complete explanation of package management. It is a record of how to complete a recurring task in a particular environment, which is an important distinction.

The package-update note functions like a reliable procedure. My collection of Next.js notes is closer to an archive of things I have encountered. Both have value, but they serve different purposes. I had been treating them as if they were the same.

A vault can become a warehouse

Part of the problem came from believing that more comprehensive capture would automatically produce a better knowledge system.

I recorded documentation, personal discoveries, troubleshooting notes, and copied explanations. But these types of information have different lifespans and different retrieval requirements.

A project-specific procedure may remain useful for a long time because it describes a stable workflow in a particular codebase.

A package integration note may become invalid after a major version update.

A copied piece of documentation may already have an authoritative source online, which is more likely to be updated than my personal note.

An error note might only be useful if it includes the circumstances that caused the error and the solution that worked in that specific environment.

By putting all of these into the same general pool of information, I made the vault comprehensive but harder to navigate. The notes were there, but their relationships were unclear. I didn’t always know which ones were current, which ones were historical, and which ones were merely summaries of information that I could find elsewhere.

The vault had become a warehouse: full of potentially useful things, but not designed around finding the right thing at the right time.

How I’m changing what I optimize for

I don’t think the answer is to stop taking notes or to delete everything that isn’t immediately actionable.

Capture still matters. I wouldn’t have been able to create the package-update note without documenting what I learned the first time.

But capture is only the beginning of the process.

A second brain also needs to help me retrieve information. That means asking different questions when I create and organize notes:

• Will I know what to search for when I need this?
• Is this a reusable procedure, a personal decision, a reference, or a historical record?
• Does this note apply to a specific project or environment?
• Is it likely to become outdated?
• Is this information better represented as a link to an authoritative source?
• If there are related notes, which one should be treated as the source of truth?

I may also need to treat different kinds of notes differently. Project-specific procedures should preserve context and constraints. Decision notes should explain why something was done. Reference notes may be better as concise summaries that point to current documentation rather than attempts to reproduce it entirely. Version-sensitive notes should make their assumptions visible.

These are not systems I have fully implemented yet. They are consequences of realizing that my old metric (i.e. how much information I captured) was incomplete.

The more useful metric is whether the system helps me complete future work. For example, with process notes, the first time I record it I can note down how long the actual process took me. Then, when I encounter the process again, I can use the note to assist me and note down how much time I had saved as a result.

A second brain is not valuable because it contains everything I have learned. It is valuable because it reduces the effort required to solve problems I encounter again.

To put it simply: Capture stores the effort, but retrieval realizes the savings.

Without a reliable way to retrieve relevant information when I need it, I may as well have to rediscover the information myself. And if I still have to rediscover it, then the system has not fully done the job I created it to do.

I was optimizing my second brain for remembering to save things.

Now I want to optimize it for being able to use them.