Many people know the Unix design principles as “everything is a file” and “do one thing and do it well.”, but few know about dozens of others. As a note, these rules, like most engineering rules, do have exceptions, but in my experience the exceptions are incredibly rare. In this post, we’ll touch upon 5 Unix design principles that’ll supercharge your coding. In the following weeks, we’ll do a deep dive into each principle.
The first rule is my personal favorite. It comes from TAOUP (The Art of Unix Programming), the greatest book on fast coding and software design ever written:
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
This is especially true in 2021 where we can buy cloud compute.
I’ve personally witnessed lost sales, engineering years of time wasted, and a project team becoming the butt of many jokes because this simple rule wasn’t followed.
Where EXACTLY to separate code
Another rule from the TAOUP that teaches us exactly where to separate code and what goes on each side:
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Code has policy, what to do, and mechanism, how to do it. Code should always keep these parts separate. The code has a caller, where all policy code goes, and callee, where all mechanism code goes. The interface between the two is a joint of the system. Often times this is an HTTP API, but can even be a method within a codebase. Each part of the code is mostly independent, they only connect at the joint.
My mom always told me
My mom always told me if I don’t have anything nice to say, to say nothing.
Similarly, the TAOUP teaches us:
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
People think they should break this rule is broken because end users don’t interpret silence as success. They are afraid of silence, it could mean anything. If they click “move money”, see a spinner, and then…nothing. What happened? Where’s my money?
This is a great reason for an app to provide friendly help messages to its human clients, but not a program whose clients are other programs.
Rob Pike, co-inventor of Go, brings us this gem:
Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Where data lives, how it’s formatted, where it moves, and how it changes, forms the skeleton of a codebase. Everything else depends on it.
A SPOTty design is a good design
From Brian Kernighan via TAOUP, the K of K&R C and AWK, brings a principle I’ve used again and again.
The Single Point of Truth Rule or SPOT Rule
The SPOT rule is a useful design principle because bugs often lurk when there are multiple points of truth, for example cache bugs. In a SPOTty design, it’s impossible to write these bugs. Fewer bugs means less debugging which means faster coding
We’ve gone through a lot of advanced material in a short time. For the next 5 weeks, we’ll deep dive into each one of these principles and apply them to code design and faster coding. If you don’t want to miss out, just click “Subscribe now”