My snippet library has 200 entries. I've used maybe 40 of them in the last month. The other 160 are, by any curation standard, dead weight — a graveyard of snippets I saved two years ago for projects that no longer exist.
I'm not going to clean them up. And I want to argue that the graveyard is a feature, not a bug, because the alternative — a curated, pruned, "quality" library — has a cost that's worse than the clutter.
This post is about that trade, and about why "cheap storage" is the right design principle for a personal snippet library.
The curation argument, steelmanned
The case for pruning is real:
-
Search noise. 200 entries means
snippetx search deployreturns 12 results instead of 3. The right one is buried under stale ones. - False confidence. A stale snippet in the library looks as trustworthy as a current one. I might copy a deploy command from a project I left two years ago, and it'll be subtly wrong for the current setup.
- Maintenance illusion. A "curated" library implies I'm maintaining it, and the maintenance is a recurring tax I'll eventually stop paying — at which point the library rots from the top down.
All true. I grant every point. Here's why I still don't prune.
The counter: curation is a decision, and decisions are expensive
Pruning a library means, for each entry, a judgment call: "is this worth keeping?" That's a decision with a real cost — not just the time, but the commitment. Every "keep" is a promise to maintain it; every "delete" is a risk of deleting the thing I'll need in three months for a project I can't currently see.
The graveyard avoids the decision entirely. The rule is: save freely, never prune, let search do the filtering. The cost of a stale entry is near-zero (it's a few lines of text in a local directory); the cost of a wrong deletion is real (the thing I can't reconstruct, in the moment I need it). Asymmetric costs favor the side with no decisions.
The graveyard is a record, not a clutter
Here's the part that changed my mind about pruning: the dead snippets are a record of how I worked. The 160 unused entries aren't waste — they're a log of the patterns I encountered, the problems I solved, the configs I needed, over two years. I don't use them, but they tell me things:
- The cluster of
docker-composeentries from 2024 tells me that was when I was doing the containerization work. - The three
stripe-webhookentries tell me I wrestled with webhook signatures harder than I remember. - The
k8s-ingressentries tell me that project's shape, in a form I'd have to reconstruct from memory otherwise.
A curated library is a record of what I currently value. A graveyard library is a record of what I actually did. The second is more honest, and more useful when I need to remember "how did I solve this before?"
Search is the curation that actually works
The graveyard only works if search is good enough to cut through the noise, and this is where the tool design matters. snippetx's search is a simple substring match across names and content, and it's good enough for 200 entries because:
-
The names are distinctive. I name snippets with the
area-purpose-detailconvention, sosnippetx search 301-regexreturns one result, not twelve. - The result is scannable. The search output is a one-line-per-entry format (id, name, language, first line of content), and I can pick the right one in a glance. The stale entries are visible as stale (old project names in the snippet name), which is itself a filter.
- 200 is small enough. The graveyard works at 200. At 2,000, substring search would drown, and I'd need tags or fuzzy matching. The scale limit is real — I'll hit it eventually — and when I do, the answer is better search, not pruning. The storage stays cheap; the retrieval gets smarter.
The design principle
The general principle: for personal reference tools, storage should be cheap enough that you never have to decide what to keep. The moment keeping something requires a decision, you stop saving the marginal thing, and the library becomes a curation project instead of a record.
snippetx's storage is a local directory of text files. The marginal cost of one more entry is zero — no quota, no subscription, no "your library is 80% full." That's the feature. The curation SaaS with its 500-entry limit and its "organize your library" prompts is solving a problem I don't have, by creating a problem I did.
The graveyard is 160 snippets I'll never use. It's also the only complete record I have of two years of actual work. I'm keeping both properties, and the price is a search result with a few extra lines. That's a trade I'll make again.
npx @wuchunjie/snippetx
More Tools
| Tool | What it does | Command |
|---|---|---|
| scaffoldx-cli | Production-ready project templates in seconds | npx scaffoldx-cli |
| dotguard | Scan .env files for exposed secrets | npx @wuchunjie/dotguard |
| gitpulse | Git repo analytics in your terminal | npx @wuchunjie/gitpulse |
| snippetx | Terminal code snippet manager | npx @wuchunjie/snippetx |
If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.
Top comments (0)