A Few Simple* Rules To Build Scalable Tools
🧵 👇
* "simple", yes, in nature; consistently applying them requires discipline
🧵 👇
* "simple", yes, in nature; consistently applying them requires discipline
Don't assume you can write intermediate data to a temporary file. Avoid I/O where possible. Avoid state.
Don't try to read all input into memory. Process as a stream.
When implementing e.g., an HTTP API, don't generate all data in one go. Paginate results.
Don't try to read all input into memory. Process as a stream.
When implementing e.g., an HTTP API, don't generate all data in one go. Paginate results.
Don't hardcode assumptions and user- or environment- specific settings. Separate code and config.
Don't leak tokens or passwords. Separate config from secrets.
Don't trust input outside of your control. Assume a hostile environment.
Don't leak tokens or passwords. Separate config from secrets.
Don't trust input outside of your control. Assume a hostile environment.
Don't rely on the user to make decisions at runtime. Avoid interactive use, favor command-line options.
Don't ignore what your tool chain tells you. Enable, then fix all warnings.
Don't explode when things go wrong, nor futilely plod on. Fail early, explicitly, gracefully.
Don't ignore what your tool chain tells you. Enable, then fix all warnings.
Don't explode when things go wrong, nor futilely plod on. Fail early, explicitly, gracefully.
Don't require expert knowledge to use your tool. Document assumptions, document the basics.
Don't try to make your docs match the tool. Write the fine manual, then make the tool match the docs.
Don't try to make your docs match the tool. Write the fine manual, then make the tool match the docs.
Don't try to be clever; that makes debugging so much harder. Murder your darlings.
Don't use comments to describe _what_ your code does. Use it to explain the unobvious, _why_ it does what it does.
Don't use comments to describe _what_ your code does. Use it to explain the unobvious, _why_ it does what it does.
Don't let Perfect be the enemy of the Good, but beware of letting Good Enough become the enemy of Actually Good.
Simplify. Build filters.
Worse is better.
Simplify. Build filters.
Worse is better.
Lastly, to close with Fred Brooks:
"Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence."
🎤 🖐
(To be continued...)
"Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence."
🎤 🖐
(To be continued...)
