unix philosophy
the unix philosophy 1
born from practice, not theory.
bottom-up. small systems. real interfaces.
built by engineers who debugged their own ideas.
the unix philosophy isn’t a method.
it’s a mindset — simple parts, clean rules, and just enough abstraction.
there is no rule six
- you can't predict where code will be slow.
- measure before you optimize.
- don't use fancy algorithms unless
nis huge — and even then, measure. - simple is faster to write, easier to debug.
- data structures matter more than algorithms.
- there is no rule six. 2
modularity
write simple parts with clean interfaces
complexity always wins unless you contain it.
modules with clear edges localize problems.
interfaces help you change one part without breaking the rest.
clarity
clarity beats cleverness
write code for humans.
the computer already understands it.
you’ll come back to this code. so will someone else.
make it readable.
composition
build programs that connect
avoid monoliths.
make small tools that can be combined.
prefer simple input/output streams — text if you can.
don’t assume what’s on the other end.
don’t depend on what’s on the other end.
separation
separate policy from mechanism
don’t mix the rules with the engine.
when you do, both break.
split logic from interface.
test the mechanism without the policy.
swap policies without changing the system.
simplicity
design for simplicity, not ego
complexity is seductive.
engineers compete to show off.
build the clever thing. break the clever thing.
repeat.
resist it.
prefer boring code that works.
prefer structure over style.
prefer systems that are small, sharp, and quiet.
parsimony
only go big when you’ve proven small won’t work
complexity scales cost.
and once it’s built, you won’t want to throw it away — even when it fails.
transparency
make the system easy to inspect
build visibility into the system.
show state. expose internals.
design so you can reason about correctness.
test with real input and clear output.
debugging isn’t an afterthought — it’s part of design.
robustness
robustness comes from simplicity and transparency
most bugs live in special cases.
eliminate them.
remove paths. flatten logic.
if you can’t hold the system in your head, it will break.
build systems you can reason about.
representation
push complexity into data, not logic
code is fragile.
data is easier to reason about.
when faced with a choice, shift complexity into structure.
make the program dumber — and more reliable.
least surprise
do what people expect
interfaces should feel familiar.
respect defaults. avoid clever twists.
follow conventions unless you have a reason not to.
surprise wastes time.
silence
if a program has nothing to say, it should say nothing
don’t make noise.
don’t log what isn’t interesting.
don’t claim attention unless it matters.
quiet is a feature.
repair
handle errors gracefully — or fail loudly
recover when you can.
but if you fail, fail early and clearly.
help the next person see what broke.
economy
optimize for human time, not machine time
machines are cheap.
your time isn’t.
make tradeoffs accordingly.
generation
write code that writes code
don't hand-hack what you can generate.
tools are better at details.
generate once, fix zero.
optimization
get it working before you make it fast
first: make it run.
then: make it right.
then: make it fast.
delete is still the best optimization tool.
diversity
distrust "one true way"
software has many paths.
don’t build for one.
make space for others.
support extensions, variants, options.
rigid systems break. open ones grow.
extensibility
design like the future will show up tomorrow
leave room for versioning.
leave room for evolution.
make formats self-describing.
leave hooks for the next person — which might be you.