Small Tools Compound
A short defense of the 100-line script you'll use every day.
Most of my best workflow improvements have come from scripts under 100 lines that I wrote in an afternoon and have used every day since.
Some examples from the last year:
tmx— a tmux wrapper that names panes by task, so I can see what every window is for at a glancemac-notify— sends a macOS notification when a long-running command finishestokens— a terminal dashboard for my Anthropic + OpenAI spend
None of these are products. None of them have READMEs. They all live in ~/code/hacks/ and they all save me 30 seconds, 50 times a day.
The trap of “this should be a product”
Every time I build one of these I get a flicker of “this should be open source, this should be a CLI on Homebrew, this should be a SaaS.” And every time I’ve tried to follow that flicker, the tool gets worse — because building for me and building for strangers are different jobs.
Building for me means I can hardcode my username, assume my shell, and ignore Windows. Building for strangers means I have to defend every choice. The 100-line script becomes 800 lines of argument parsing and config loading and I stop using it because it’s no longer a tool, it’s a project.
So: write the small thing. Use it for a month. Then decide if it deserves to be a product. Most don’t.