The shape of a useful tool
Good tools reduce the number of decisions required to do good work.
·2 min read
The best tools can be difficult to notice. They fit the work closely enough that the interface recedes and the result stays in view.
Software often moves in the other direction. A small need accumulates settings, modes, and extension points. Each choice makes sense in isolation. Together, they ask the user to understand the tool before doing the work.
“The best modules are those that provide powerful functionality yet have simple interfaces.”
— John Ousterhout, A Philosophy of Software Design
Start with the common path
A useful tool should make its main task obvious. Good defaults are part of the interface, not an alternative to it. They encode a clear opinion while leaving an escape hatch for the cases that genuinely need one.
This static site generator has one common path:
go run ./cmd/site build
That command validates the articles, renders the pages, minifies the assets, and writes a directory ready to deploy. The implementation can change without making the publishing workflow more complicated.
Keep the seams visible
Simple does not mean opaque. Plain Markdown goes in. Plain HTML comes out. A writer can inspect either side with tools that will still exist years from now.
A useful tool makes routine work quiet and unusual work possible. Finding that balance is less about adding features than deciding which ideas the tool can safely hide.