Command Line Interface Guidelines
An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating…
I am excited to see this reference. I’ve long felt that the most important part of building a tool for people to use is thinking through how they’re going to use it, and even considering what you would want out of a tool if you were supposed to use it. I can’t count the number of times I’ve given the feedback of “how would you feel if you had to use this?”, followed by an acknowledgement that they’d built something less friendly than it might have been. If you’re going to build a tool to help someone with a task, you might as well go the extra mile and make it satisfying and intuitive to use too. I’m pretty open to variety in technical architecture and implementation details, but I’m a real stickler about not building tools that are hard, confusing, or unpleasant to use. A relatively small up-front investment in thinking about usability pays exponential dividends throughout the life of the tool in the amount of time and pain it saves its users relative to the least-effort implementation that lacks empathy for the poor souls who are going to be stuck using your tool.