Small Tools for Ordinary Problems
Most of the software I write is small. Not small in the dismissive sense, but small in scope, small in ambition, small in the number of people who will ever use it. Usually that number is one: me. Occasionally two or three, if I'm building something for a specific project with other people involved.
I've started calling this "automation hobbyism" in my own head, though I'm not sure the term is quite right. It's not automation in the industrial sense. It's more like — I encounter a tedious task that I do repeatedly, and at some point the tedium crosses a threshold where I'd rather spend an afternoon writing a script than continue doing the task by hand. Whether the script actually saves time in aggregate is debatable. That's not really the point.
Here's an example. A while back I was doing contract work that involved processing a lot of scanned documents. The documents came in as TIFFs, usually with unhelpful filenames like "scan_001.tif" through "scan_347.tif." My job was to sort them, rename them according to a convention the client used, run OCR on the ones that needed it, and deposit them in the right folders on a shared drive.
The first time through, I did it manually. It took the better part of a day and I made several mistakes that I had to go back and fix. The second time a similar batch came in, I wrote a shell script. Nothing fancy — just some file operations, a call to Tesseract for the OCR, and some basic logic for sorting based on the first page content. It took maybe three hours to write and test. After that, processing a batch took about ten minutes of setup and then I could walk away while it ran.
That script still exists on my machine somewhere. I've modified it a few times for different projects. It's not something I would ever publish or share — it's too specific to my workflow, too ugly in its implementation, too dependent on assumptions about file structures that wouldn't hold for anyone else. But it works for me, and it's saved me a lot of dull afternoons.
I have a whole collection of these. A Python script that renames files based on patterns I define in a text file. A bash function that sets up a new project folder with the directory structure I like. A tiny web scraper I wrote to pull weather data into a dashboard I used for a while. Each one solves exactly one problem and does nothing else.
The temptation, always, is to generalize. To think: "This renaming script works great for my documents — what if I made it work for anyone's documents?" That way lies madness, or at least scope creep. I've gone down that road a few times. The Readpile project on my projects page is a good example — started as a simple reading list for myself, grew into an attempt at a general-purpose tool, and collapsed under the weight of features nobody asked for. Least of all me.
These days I try to resist the urge to generalize. A tool that does one thing well for one person is a success. It doesn't need users or documentation or a GitHub repository. It just needs to work when I run it.
There's a broader point here about the culture around software development. The assumption is that code should be shared, open-sourced, made available to the community. And I think that's admirable in many cases. But there's also value in private tools — in software that exists only to serve a specific person in a specific context. Not everything needs to be a product.
I think more people write small tools like this than we realize. They just don't talk about them because there's nothing to show off. A fifty-line script that saves you twenty minutes a week isn't going to impress anyone on a forum. But over the course of a year, that's real time reclaimed. And the act of writing it — of looking at a problem closely enough to automate it — teaches you something about the problem itself.
Anyway. I don't have a grand conclusion. Just a modest endorsement of writing small, ugly, personal software that solves your problems and nobody else's.
— Kevin Vadala