The hardest problem is the one you think is trivial
Phil Karlton, a Netscape engineer, once said: "There are only two hard things in Computer Science: cache invalidation and naming things." The quote became a joke — printed on mugs, dropped into conference talks, extended with the inevitable "and off-by-one errors." But the reason it persists isn't humor. It persists because every practitioner, in every domain, eventually discovers that Karlton was not exaggerating.
Naming is not labeling. Labeling is what you do after you understand something — you stick a tag on it for filing purposes. Naming is the act that produces understanding. When you force yourself to name an idea precisely, you discover what you actually think. And when you fail to name it precisely, you discover — if you're honest — that you don't yet know what you're looking at.
This lesson sits in Phase 2 because it's the operational consequence of atomicity. You learned in L-0026 that small, self-contained pieces can be assembled into structures that monoliths cannot. But an atomic unit without a precise name is like a LEGO brick with no shape — you can't find it, you can't describe it to someone else, and you can't connect it to anything. The name is what makes the atom usable.
Language shapes the territory, not just the map
In 1922, Ludwig Wittgenstein wrote in his Tractatus Logico-Philosophicus: "The limits of my language mean the limits of my world." This was not a poetic flourish. Wittgenstein was making a structural claim: you cannot think clearly about things you cannot name, because language is the substrate of deliberate thought.
Eighty years of cognitive science has confirmed the practical version of this claim. Lera Boroditsky's research program at Stanford has produced some of the most striking evidence. In a 2007 study, Boroditsky and colleagues demonstrated that Russian speakers — whose language requires different words for light blue (goluboy) and dark blue (siniy) — discriminate between those shades faster than English speakers, who use a single word for both. The effect wasn't a matter of visual acuity. When researchers occupied participants' language centers by having them repeat nonsense syllables, the Russian advantage disappeared. The discrimination was happening through language, not alongside it.
The implication for your knowledge system is direct. When you name a concept vaguely — "burnout," "productivity," "leadership" — you are giving yourself a coarse-grained lens. You can see the general category but not the specific phenomenon. When you name it precisely — "resentment from accountability without authority," "the 90-minute deep work cycle before context-switching penalties begin," "the decision to absorb blame publicly so your team can take risks safely" — you create new perceptual categories. You can now see distinctions that were invisible before. The name doesn't just describe the thing. It creates the cognitive resolution to perceive the thing.
Research with the Himba people of Namibia reinforces this pattern from the other direction. The Himba language does not mark the distinction between blue and green the way English does. Studies show Himba speakers demonstrate no enhanced discrimination at the blue-green boundary — but they do show enhanced discrimination at boundaries their language marks. Language literally partitions the perceptual field. Your note titles do the same thing to your conceptual field.
Evergreen titles as cognitive APIs
Andy Matuschak, the researcher and designer behind some of the most rigorous thinking on personal knowledge management, articulated the principle this way: "Evergreen note titles are like APIs." The analogy is precise. In software, an API (Application Programming Interface) is a contract: it tells you what a module does, what it accepts, and what it returns — without requiring you to read the implementation. A well-titled note does the same thing. The title is the interface. If it's sharp, you can reference the idea, link to it, and compose it with other ideas without reopening the note.
Matuschak's design principles for note titles follow directly:
- Use complete phrases, not topics. "Evergreen notes should be concept-oriented" — meaning the title states a claim, not a category. Not "Spaced repetition" but "Spaced repetition produces stronger retention than massed practice for factual recall."
- Prefer declarative statements. A title like "Naming things is hard" tells you less than "Precise naming forces you to confront what you don't yet understand." The declarative version is falsifiable, composable, and useful at a glance.
- Treat titles as abstractions over content. As your ideas develop, the title should abstract over increasingly complex subtrees of thought. A mature note system develops "concept handles" — compressed phrases that carry heavy conceptual freight. Terms like "prisoner's dilemma," "Overton window," and "technical debt" are concept handles that allow complex ideas to travel in a single phrase.
The difference between a well-named note and a poorly named one is the difference between a tool and a pile. "Meeting notes 2026-01-15" is a pile — it tells you when something happened, not what was decided or why it matters. "Decision: delay v2 launch until auth migration completes" is a tool — it tells you the outcome, the dependency, and the action, all in the title. You will never search for the first note. You will reach for the second one repeatedly.
Ubiquitous language: how teams fail at naming
The naming problem compounds when more than one person is involved. Eric Evans identified this in his 2003 book Domain-Driven Design through the concept of Ubiquitous Language: a shared, precise vocabulary that both technical and business teams use to describe their domain. Evans observed that most software bugs are not logic errors — they are naming errors. When the code calls something a "user" and the business calls it an "account holder" and the support team calls it a "customer," every conversation introduces translation overhead, and every translation introduces ambiguity.
Evans' prescription was rigorous: the domain model's language should appear in conversations, in documentation, and in the source code itself. If two people use different words for the same concept, that's a bug. If one word is used for two different concepts, that's a critical bug. Robert C. Martin extended the principle in Clean Code: "A name should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent."
This applies identically to personal knowledge work. If you have three notes tagged "productivity" that are actually about time-blocking, energy management, and meeting reduction — you have a naming collision. The tag gives a false sense of organization while hiding the fact that these are three distinct concepts requiring three distinct strategies. The Ubiquitous Language principle says: make the names so precise that they cannot be confused, even by someone encountering them for the first time.
The Linnaean lesson: how naming enables a field
The most dramatic example of naming transforming an entire domain is Carl Linnaeus's binomial nomenclature, introduced in the 18th century. Before Linnaeus, the same organism might have half a dozen names across different regions and languages. A biologist in Sweden and a biologist in France could be studying the same species without knowing it — or, worse, could think they were studying the same species when they were not. Communication was impossible. Cumulative progress was accidental.
Linnaeus imposed a system: every species gets exactly two Latin names — a genus and a species designation. Homo sapiens. Canis lupus. Escherichia coli. The names were unique, stable, and language-independent. Suddenly, a finding in Tokyo could be connected to a finding in Berlin because they shared the same name for the same organism. Taxonomy did not just organize biology. It enabled biology as a cumulative science.
Your knowledge system faces the same problem at a smaller scale. If your past self called an idea "leadership stuff" and your present self searches for "delegation frameworks," you will not find your own work. Imprecise names break retrieval. Precise names build a personal taxonomy — a Linnaean system for your own ideas — where every concept has a stable, unique handle that your future self (and your tools) can find.
Naming in the age of AI retrieval
This matters more now than it ever has, because the tools you use to retrieve knowledge have changed. When your knowledge system consisted of paper files in a cabinet, naming mattered for your own memory. Now that AI-powered search, semantic retrieval, and retrieval-augmented generation (RAG) are embedded in most knowledge tools, naming matters for machine comprehension too — and in ways that are not always intuitive.
Semantic search can find conceptually related content even when the exact words differ. That's its strength. But semantic search struggles with vague, generic titles because they embed poorly — "Interesting article" carries almost no semantic signal. A note titled "Evidence that deliberate practice requires immediate feedback loops" embeds into a rich region of meaning-space. It will surface when you search for "practice," "feedback," "skill acquisition," or "performance improvement." The precise name creates multiple retrieval paths. The vague name creates none.
In RAG systems — where AI pulls from your notes to generate responses — the quality of naming directly determines the quality of the AI's output. If your notes are titled with complete declarative statements, the AI can select the most relevant ones, synthesize them accurately, and cite them back to you. If your notes are titled "Misc," "Draft 2," and "Stuff to think about," the AI retrieves noise. The naming convention you adopt today determines whether AI becomes a genuine thinking partner or an expensive random-text generator.
The practical rule is simple: name things so that a search query you'd naturally write would match the title you've already given the note. If you'd search "how to give difficult feedback," then your note should be titled something like "Difficult feedback is more effective when anchored to specific observable behaviors." The note title anticipates the retrieval context.
The name reveals your understanding
There's a deeper function of precise naming that goes beyond retrieval. The act of naming is a diagnostic. When you struggle to name something precisely, that struggle is not a writing problem — it is a thinking problem. The name reveals how well you understand the thing.
Try it. Take any concept you think you understand and attempt to write a one-sentence title that captures its essence. If you can do it quickly, you understand it. If you can't — if you keep hedging, adding qualifiers, reaching for vague words like "framework" or "approach" or "methodology" — you've found the edge of your understanding. That edge is exactly where the most productive thinking happens.
Martin Fowler captures this through the lens of code: "If you have to spend effort looking at a fragment of code to figure out what it's doing, then you should extract it into a function and name the function after that 'what.'" The same principle applies to ideas. If you have to open a note and read three paragraphs to figure out what it's about, extract the claim and put it in the title. If you can't extract the claim, the note is not yet a finished thought — it's raw material that needs more processing.
This is why naming is not a cosmetic step you do after the real work. Naming is the real work. It is the moment where fuzzy intuition becomes operable concept. It is the compression step that turns a paragraph of reasoning into a phrase you can carry, reference, and build on.
From precise names to separable claims
You now have the practice: name every idea precisely enough that the title alone tells you what the idea claims, why it matters, and when to use it. This is the skill that makes your atomic notes actually atomic — not just small, but self-describing.
The next lesson, L-0028 — Separate claims from evidence — takes the next step. Once you can name an idea with precision, you'll notice that many of your "ideas" are actually two objects fused together: a claim ("spaced repetition is more effective than rereading") and the evidence that supports it ("Karpicke & Roediger, 2008, showed 80% retention vs. 36%"). These need to be stored separately, because claims can be challenged and evidence can support multiple claims. But you can only see that distinction when the name is sharp enough to reveal the seam.