One giant file buries ideas; a thousand atomic notes shred them. A practical rule for deciding when a thought deserves a note of its own.
· Note-Taking Basics · 7 min read
Every note-taker eventually runs into the sizing question. You sit down to capture something — a project, a book, a person, an idea — and before the first word lands you have to answer: does this go into an existing note, or does it deserve its own? Answer wrong in one direction often enough and you get a junk drawer. Answer wrong in the other and you get confetti.
Both extremes have loud advocates. The monolith camp keeps one giant file — or a handful of huge notes named Work, Ideas, Life — appends everything, and retrieves by search. The atomic camp keeps one idea per note, thousands of tiny notes, and retrieves by links. Both are answering the same anxiety, will I find this again?, with opposite architecture. Both are right about something, and both fail in predictable ways.
The appeal is real. A single everything-note has zero capture friction: there is never a filing decision, you just jump to the end and type. Search still works. More than a few programmers have famously run their entire lives out of one text file for decades, and the fact that this is possible at all says something important — capture friction matters more than structure.
The failure arrives slowly, and it is a failure of handles. A monolith gives you nothing to point at. You cannot link to "the pricing decision" when it is line 2,417 of work.md; you can only excavate it. Opening the file drops you into everything at once, so reviewing any one topic means scrolling past every other topic. Search finds words, but the hits come back stripped of shape — twelve scattered mentions of a project instead of the project. Past a certain size, a monolith stops being a place you read and becomes a place you only ever grep, and material you never re-read might as well not exist.
Hyper-atomic systems fail as the mirror image. Every capture now demands a title, and usually a decision about links and location — a small tax collected at the worst possible moment, which is the moment of actually having the thought. Some captures get skipped because the paperwork feels heavier than the idea. Worse, context shatters: an argument that made sense as one page becomes eleven fragments, each individually true and collectively unreadable. You open a note and it is four lines long, a stub whose meaning lived in its neighbors. Orphans accumulate — perfectly formed atomic notes that nothing links to and no search will surface, because their titles were named for the thought, not for how you would ever look for it.
The confetti failure is sneakier than the monolith failure because it looks like diligence. The archive is beautifully granular. It is also a bag of shredded paper.
Here is the rule that settles most cases: a note should be the thing you would want to open by name.
A note title is a handle. It is what you type into search or a quick switcher, what a link points to, what a backlink list collects under. And you do not retrieve thoughts by name — you retrieve topics, projects, people, meetings, books, decisions. Those are naturally note-sized. The test takes five seconds: imagine future-you needing this material. What would they type to find it? That phrase is the note. Everything you would only ever find through that phrase belongs inside it, not beside it.
Applied concretely:
Notice the rule is about you and your retrieval habits, not about some objective taxonomy of knowledge. The same fact can be a bullet in one person's system and a note in another's, and both are correct.
The corollary: sizing is not a decision to make at capture time. It is a refactor you perform later, when a note tells you it is ready.
If this sounds like how good software grows — write it inline first, extract the function once three callers want it — that is not a coincidence. Premature abstraction fails the same way in both places.
The sizing question feels agonizing mostly because conventional apps make a note a flat page, so inside a note and its own note are wildly different states — one is scroll-and-squint, the other is a first-class object. An outliner collapses that gap. When a note is a tree of bullets, every branch is already a small, addressable thought: collapse the tree and you get the summary, expand a branch and you get the detail, and a big note stays navigable at any size. You get atomic granularity inside monolith-grade capture friction, which is most of what each camp wanted from the other.
Outlines also make the split moment obvious instead of theoretical: a branch that has visibly outgrown its parent is the section with gravity, and promoting it to its own note is a cut-and-paste, not a reorganization project. Indenta leans into exactly this shape — notes are outlines, and [[wiki-links]] with automatic backlinks mean a bullet that mentions a topic is findable from that topic's note without ever being moved into it. Material no longer has to live in the "right" note to be reachable from it, which quietly removes half the reason people agonize over note size in the first place. The User Guide covers the mechanics.
Fairness demands the caveat: some systems are atomic on purpose, and correctly so. The Zettelkasten method pays the per-note naming tax deliberately, because its product is not storage but recombination — small self-contained claims that can be linked into essays and arguments you did not plan. If you are building toward writing, atomic notes are not overhead; they are the point. Reference material earns atomicity too: one note per recipe, per person, per API you keep looking up, because each is retrieved by name, which — note — is the same rule again, applied honestly.
The mistake is importing that discipline into general capture. Your meeting log, your project journal, and your reading intake do not need to be a Zettelkasten, and running them like one is how the confetti failure usually starts.
One note per thing you would open by name. Capture into the nearest existing note by default, and let an inbox or daily note absorb everything that has no home yet. Split when a section develops gravity; merge when stubs travel in pairs; never split for looks. And then stop optimizing — the perfectly sized note is not the one that matches a methodology diagram. It is the one you actually open.
Try it in practice: Indenta is a free, offline-first outliner — nested notes, backlinks, tags, and peer-to-peer sync, with no account required. Start writing in your browser, or read the User Guide first.