the best developer tool i’ve ever used was jq. it does one thing: transform JSON. the interface is a query language that takes thirty minutes to learn and then feels like an extension of your fingers. it has no gui, no dashboard, no settings file. it ships as a single binary.
i think about jq a lot when i’m building tools.
the invisible tool
there’s a category of software that you notice when it’s broken and forget when it works. good developer tools aim for that. they have opinions, they’re fast, and they stay out of the narrative you’re building in your head about the problem you’re solving.
the tools that fail are usually the ones that want to be part of that narrative. they want you to think about them. they have configuration ceremonies and plugin ecosystems and ui states that demand attention. the tool becomes the work.
cli vs gui
i’m biased toward CLIs. not because GUIs are bad — but because a CLI is a forcing function for clarity.
if you can’t describe what your tool does as a single command with a few flags, you probably haven’t figured out what it actually does yet. the gui lets you defer that decision. the cli doesn’t.
there’s also composability. a tool that reads from stdin and writes to stdout can be combined with every other tool that does the same. that’s not just a technical property — it’s a philosophy about how tools relate to each other.
the dangerous moment: feature request
every tool has a dangerous moment, and it’s not the first bug — it’s the first feature request from yourself.
the tool works. it does the thing. and then you think: wouldn’t it be useful if it also did this other thing? the answer is almost always yes. and then the tool doubles in scope and halves in clarity.
the discipline is to stay sharp. to ask what the tool is for before adding something to it. to make the tool do less and do it more completely.
on building for yourself
the tools i use most are the ones i built for myself. not because they’re polished — they’re not — but because they encode exactly the thing i needed. no more.
commercial developer tools are built for a wide surface area of users. they have to be. but there’s a kind of tool that can only be built by the person who needs it, for the exact shape of their problem.
the craft is knowing when to build that tool instead of bending the commercial one into something it wasn’t designed to be.