The joy of small tools

I have a scripts folder with a bunch of tiny files in it. Most are under thirty lines. One renames screenshots so I can actually search them. One diffs two JSON exports and prints only the keys that changed. One reads a log and tells me which request IDs showed up more than once.

None of them are good software. No tests, barely any error handling, and the only interface is whatever arguments I remembered to add. They’re also some of the most useful code I’ve written.

Different rules

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

A small script has none of that. It runs on my machine, on input I understand, and if it breaks I’m sitting right there. So I can skip almost everything that makes software expensive and still get the full benefit. Fifteen minutes of writing against a task that would take two hours by hand and comes back every month.

Where I used to go wrong was treating these like real projects. Argument parsing, a config file, a --dry-run flag. Suddenly a fifteen minute win is a whole afternoon, and the script needs maintenance it’ll never pay back.

Hardcode everything

The best part about a small script is that it can assume things out loud. The file is always UTF-8. The column is always the third one. There are never more than a few thousand rows. In shipped software each of those is a bug. Here each one is code I didn’t have to write.

If an assumption breaks, the script crashes right away, and I fix it with the time I saved by not handling it in the first place. Good trade, almost every time.

Let them die

The other half is not getting attached. A script I wrote for one migration can be deleted after the migration. It already did its job when it ran.

I used to try to turn these into proper tools: real CLI, own repo, a README. Almost every time, the “proper” version got used twice and then rotted anyway, except now the rot was in a repo where others could trip on it. The ones that really deserved to grow up made it obvious. I kept reaching for them, for months, without planning to.

So now: write it badly, use it, and let usage decide. A tool earns its way into being real.

Why I like it so much

Part of it is the return. Thirty lines against a task I was dreading is the best deal in this job.

But mostly it’s that these are the only programs where I’m the whole audience. No review, no backward compatibility, nobody else’s conventions. A problem I have and the shortest thing that makes it go away. Pick it up, do the thing, put it down.