The joy of small tools

My scripts folder has about forty files in it. Most are under thirty lines. One renames screenshots into a format I can actually search. One diffs two JSON exports and prints only the keys that changed. One reads a log and tells me which request IDs appeared more than once.

None of them are good software. They have no tests, no error handling worth the name, and no interface beyond the arguments I remembered to add. They are some of the most useful code I’ve written.

The economics are different

Real software has to survive contact with other people, future requirements, and its own past decisions. That’s why it costs what it costs.

A small tool has none of those obligations. It runs on my machine, on input I understand, and if it breaks I’m standing right there. That means I can skip nearly everything that makes software expensive and still get the whole benefit. Fifteen minutes of writing against a task that would have taken two hours by hand, and will come up again next month.

The mistake is applying real-software standards to this category. Once you start adding argument parsing and config files and a --dry-run flag, you’ve turned a fifteen-minute win into an afternoon, and the tool now needs maintenance it will never earn back.

Write it for the version of you that exists today

The best thing about a small tool is that it can encode assumptions out loud. The file is always UTF-8. The column is always third. There are never more than a few thousand rows. Every one of those would be a bug in shipped software and a feature here, because each one removes code that would otherwise need to exist.

If an assumption breaks, the script fails immediately and loudly, and I fix it in the two minutes I saved by not handling it. That trade is almost always right.

Let them die

The other half of the discipline is not caring about them. A tool written for one migration should be deleted after the migration, or left to rot without guilt. The value was extracted at the moment it ran.

I used to try to promote these into something respectable; give it a proper CLI, put it in a repo, write a README. Almost every time, the promoted version got used twice and then bit-rotted anyway, except now it was in a repo where its rot was everyone’s problem. The ones that genuinely deserved promotion made that obvious by being reached for over and over, for months, without me planning it.

So the rule is: write it badly, use it, and let the usage decide. Tools earn their way into being real. They don’t start that way.

Why it’s fun

Partly it’s the ratio. Thirty lines against a task you were dreading is the best return in this job.

But mostly it’s that these are the only programs I write where I’m the entire audience. No review, no compatibility, no one else’s conventions. Just a problem I have and the shortest thing that makes it go away. It’s the closest programming gets to using a hand tool: you pick it up, it does the thing, you put it down.