DEV Community

ke jia
ke jia

Posted on

If You Paste It Twice, It Earns a Name: The Rule That Built My Snippet Library

My snippet library has about 200 entries. It wasn't built by curation — I didn't sit down and design a taxonomy. It was built by one rule, applied over months:

If I'm about to paste something for the second time, it earns a name.

The tool doing the holding is snippetx, a zero-dependency terminal snippet manager. But the library's shape is the rule's shape, and the rule is worth writing down because it's the difference between a snippet library and a junk drawer.

The rule, precisely

The trigger is the second paste, not the first. This matters:

  • First paste: just paste it. It's a one-off. Naming it would be overhead with no payoff.
  • Second paste: stop. This is now a pattern. Give it a name and save it:
echo '<the snippet>' | snippetx add <name> <lang>
Enter fullscreen mode Exit fullscreen mode
  • Third and later pastes: snippetx search <term> and snippetx copy <id>. The paste is now a lookup, and the lookup is faster than re-deriving or hunting through browser history.

The rule has a built-in filter: one-offs don't get saved. That's the feature. A junk drawer is full of one-offs that got saved on the first paste "just in case." My library is full of two-pasters and above, which means every entry has at least two data points proving it's worth keeping.

Why the second paste is the right threshold

Because it's the first point where the snippet has evidence of recurrence. The first paste is a hypothesis ("I might need this again"). The second paste is a confirmed prediction. Saving at the second paste means:

  1. Every entry is earned. No speculative entries, no "this looks useful" graveyard. The library's content is a record of what I actually reuse, which is the only curation that's honest.
  2. The naming cost is amortized. Naming a snippet takes ten seconds. If the snippet is a one-off, those ten seconds are pure loss. If it's a two-paster, the ten seconds are paid back on the second use and in profit on every use after. The second paste is exactly where the break-even happens.
  3. The library stays small enough to trust. 200 entries is searchable. 2,000 entries is a database I don't want to maintain. The rule's filter keeps me in the first regime.

What the rule did to my habits

After a few months, the rule changed how I work in ways beyond the snippets themselves:

1. I name things as I encounter them. The act of naming a snippet forces a two-word description, and the two-word description is often the name the thing should have had. A snippet I named retry-backoff turned out to be the pattern I'd been re-deriving in five different projects — naming it surfaced the pattern, and the pattern became a function.

2. My "useful commands" stopped living in my head. The rule externalized the stuff I used to memorize. The kubectl one-liners, the jq filters, the nginx redirects — they're in the library now, and "I used to know that command" became "I can find that command." The library is a second brain with a search box, and the search box is the part that makes it work.

3. The library is a map of my actual work. The 200 entries, sorted by use frequency, are a record of what I actually spend time on. The top 20 are 90% of the lookups. That's not a curation decision — it's an emergence. The rule produced the library's shape without me deciding what to keep.

The tool's role

snippetx is deliberately minimal — it's the storage and the search, nothing more:

snippetx add <name> [lang]    # save (pipe content in)
snippetx list [filter]        # list
snippetx search <term>        # search
snippetx copy <id>            # output to stdout
Enter fullscreen mode Exit fullscreen mode

No cloud, no sync, no mobile app, no account. The snippets live in a local directory, and the manager is a single zero-dependency Node file. The tool's job is to make the rule cheap to apply — the add is one piped command, the search is one word, the copy is one id. If the tool were heavier than the rule, the rule would die from friction. It isn't.

The meta-point

A snippet library isn't a storage problem; it's a curation problem, and curation is the part that usually fails. People build junk drawers because saving is cheap and deciding-what-to-keep is hard. The rule inverts that: it makes keeping the expensive act (you have to name it) and saving the cheap act (one piped command), and it gates keeping on evidence (the second paste).

The library that survives is the one where every entry earned its place. The second-paste rule is how mine got there, and it's the whole system — the tool is just the part that makes it frictionless.

npx @wuchunjie/snippetx
Enter fullscreen mode Exit fullscreen mode

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)