Why I Still Like Small Python Tools
Small scripts still earn their keep when they remove one repeated annoyance from the week.
I still have a soft spot for small Python scripts.
Not because every problem should be solved with one, and not because tiny tools are somehow more pure than bigger systems. Mostly because there is a class of recurring work that does not need a platform, a workflow engine, or a proper product surface. It just needs to stop being annoying.
That might be diffing release notes.
Or cleaning up a deck outline.
Or checking docs for placeholder text before they go out.
Or turning rough notes into something a leadership team can actually scan.
These are not glamorous problems, which is exactly why they stay around so long.
What I like about Python for this kind of work is that it lets you stay close to the problem. Read a file. Transform it. Return something readable. Done. No need to pretend the first version needs an architecture diagram.
There is also something useful about publishing small tools in public. They show how you think when the goal is not to impress anyone. A tool can be opinionated, constrained, and maybe even a little narrow, but still be obviously useful.
That combination tends to age well.
A lot of my favorite internal tools have been exactly this: not strategic enough to become products, not trivial enough to ignore, and worth their weight because they remove one repeated point of friction from the week.