Apply UX principle to DX: 100ms for instant feel, 1s for keeping flow of thought, 10s for avoiding context switch

Many development services are metered by the minute, and time here is literally money

Tools that you build may be used as part of other tools, try to respect the constraints of such other tools (composition is a good thing!)

Software may have heavy update cycles, however downloading over night or creating a patch update tricks us into feeling that it's fast

Continuously seek where you can eliminate "required knowledge" from successful usage

Success is often portrayed as hard as climbing a mountain. Great experience should feel effortless, like falling into a pit

When adding dependencies, make sure you have a process to remove or modernize old ones, so that you can avoid bloat

Make the introductory tasks trivial and advanced ones simple

Size is often a lead indicator of complexity - binary size, install size, download size, and more; make sure that what you deliver is free of extra bloat

Depends on the platform, create the appropriate just-in-time help: manpages, help screen and autocomplete

If applicable: a good practice is to keep an /examples folder in your Github repo, or live Codepen examples for other cases

Have purpose built documentation for your tool, or even a website

Offer version and other contextual information to send when communicating to a colleague

When communicating errors and exception cases, use simple language, and offer a link for extra help if possible

Have predictable version and change policy that would not surprise people

Where possible make your tool pluggable, open for extension, or composition (see the UNIX philosophy as one example)

Don't ignore common operating-system principles. Such as text on STDOUT, errors on STDERR, or no emojis on Windows (yet)

A tool conversing well with humans, should converse with machines as well. For that we need predictable, formatted, and typed output

Accept arguments or configuration though flags, environment variables and/or configuration files

When building CLIs, set up an architecture for commands, with a predictable grammer (noun verb - `post create`, or verb noun `create post`)

Similar to other software systems, keep your tool under checks and balances. Identify when it needs to split into several different tools

Sometimes your tool will be a part of a testing suite. Make sure you play well in that scenario - the best way is to dogfood.

Make sure you have a core that can be wrapped and used in many different ways. Have a clear API for that, for example, so that you could (if you wanted) support plugins.

Some communities already have starters, kits, and boilerplates. Find the good ones and start from there

Be mindful of the kind of hardware you are running on, or will be running on. What are the limits or what is already in stress? RAM (for example, Raspberry Pi), CPU?, network?, IO?

Offer logging with levels (debug, verbose, info, warn, error), or a good debugging story in general

Try your best not to intentionally track or spy on end users, especially if they are developers which deal with sensitive data, naturally

Respect your users by offering sane and safe defaults, by convention. With that, do give ways to override with configuration

No body likes a tool that installs and breaks a few other tools afterwards. Try not to do that and be mindful of what you could break, or package your tool in a way that can break nothing (Docker container)

Software updates can be one nasty surprise if not done right. Let your users know about updates, if possible offer to opt-into update risk levels (e.g. stable, beta, canary)