Why I keep my tools small

2026-09-14

Most of the tools I use every day are small. A weather lookup in the terminal, a barcode generator, a tiny chat over a socket. None of them are impressive, and that is the point.

One job, done properly

A tool that does one thing has a short list of ways to fail. When it breaks, I know where to look, because there is only one place to look.

Small tools also tend to compose. If a program reads text in and writes text out, I can pipe it into the next one:

weather --city lagos | grep -i rain

What “small” means to me

I use three rules when deciding whether something has grown too big:

• I can explain what it does in one sentence.
• I can read all of the code in one sitting.
• I can delete it without anyone noticing.

The last rule matters most

If something is hard to delete, it has stopped being a tool and become a dependency. I try to notice that early.

Where to start

If you want to try this, pick an annoying five-minute task and write a program for it. Go is a good fit because it compiles to a single binary you can copy anywhere.

The best code is the code you never had to maintain.

That quote is often attributed to someone different each time I see it, so treat it as folklore.