I've known for a long time that developer tools are the thing I care about in tech – making other developers lives even easier is something I aspir...
For further actions, you may consider blocking this person and/or reporting abuse
When it comes to
Emacs, which is a tool I use everyday I would say it's::%s/emacs/vim/gi
:%s/elisp/vimscript/g
This is an awesome example! On the last point, I'm curious how you'd define stable – does this mean the features don't change often, that it doesn't crash/break, or something else?
likewise... I believe the same as well, and I too aspire to one day create a tool that literally stands the test of time and literally saves time--If a tool saves you even a few seconds each time you use it and you use it
ntimes a day everyday fornyears you definitely would get your ROI on learning the tool.I think great examples of these tools are: grep, fzf, parallel
I think these tools all have pretty simple APIs and just intuitively go with unix piping.
Git is not a tool it is a way of life!
Vim is not a tool it is a religion!
So in conclusion any tool that makes me more productive and gives an ROI of learning it
To answer my own question and kick things off, I'll say what I think makes
npmgood:npmhas an incredible amount of defaults that you can change and tweak to make it work for you, down to the registry that you're pulling modules from.npm initandnpm install. Once you've got those down, you're able to move on and learn more complex commands as the need arises.npmfor ~5 years now and get a lot of value out of commands likenpm ls,npm audit, andnpxbut still end up learning new features of the CLI on a weekly basis.A good tool takes up more of my burden than it adds. A good tool does the same for the maintainer who comes after me.
If I know that I don't have to worry about a particular kind of failure, then I no longer bear the burden for avoiding that failure mode.
When an authz module checks that the request is authorized to access the requested resource, I bear no burden for access control.
When an autoescaping template encodes untrusted values for me, then I don't bear the burden for avoiding XSS.
When a library clearly outlines all the exceptions that can happen, my burden for error handling is easily understood.
When a client-side web framework uses eval on data attributes in the DOM, now I have to worry about new XSS vectors, so my burden is increased.
The number one thing which makes a developer tool good is being bug and hassle free to use. It's a lofty goal, but it's totally doable if the code behind is solid and follows accepted development practises, especially KISS.
The second thing which makes developer tool good is when it gets out of the way. A lot of "power users" (quotes because one person's description is different from another) like to use the CLI, mainly because its super fast to use, but also because there are no menus options to search for - it does mean that you have to deal with discoverability though.
The third thing is documentation. A lot of tech workers are explorers ("what happens if I push this button?"), so we usually don't have a problem discovering functions. But, knowing where to look first (does it have a
manpage? Are the docs online? Can I use Zeal to get the docs?) makes a huge difference.It's all about net decrease in friction:
11jto move down eleven lines,}to go to the end of the paragraph) for the continuous-feedback process of tracking a target with the mouse.psqldatabase tool has a whole array of short-enough-to-become-muscle-memory commands that give you information about the schema as you're working in it, and integrates with your choice of editor and pager.npxeliminates a whole category of$PATHand installation issues.There are all kinds of ways developer tooling can be good, but what the best tools have in common is that they remove more complexity than they add.
I'm curious what you mean by "anticipates me". Could you elaborate?
A good tool will solve an actual real problem, without creating more problems that need to be solved.