Software Engineering Enchiridion: Omnibus Edition. 1
Part of a Software Engineering Enchiridion
This past couple of weeks I started publishing an enchiridion. “Enchiridion” is an old word, Greek origin: en- “in” + cheir– “hand” + -ion diminutive — literally, “a little handbook held in the hand.” Think: portable wisdom, something practical, ready whenever you need it.
Side note: omnibus, Latin, means “for all” — originally “for everyone” — hence a public vehicle for all. This post is an omnibus summary: a ride gathering all the best seats of what I’ve explored so far.
My reason for this old term is simple: I love the Enchiridion of Epictetus, as written down originally by his student Flavius Arrianus. When I started translating my own copy from 1578 (see image), I really related to its simple, maxim style:
My own Enchiridion focusses on software development. Specifically it focussed on my personal philosophy of software development, i.e. antifragile software development. I plan to explore things over the coming year and compile the best into my Antifragile Software book.
Throughout I am not looking to sugar coat the hard bits. I won’t pretend software craftsmanship is glamorous. I’ll explore the friction, the mess, where theory fails. While I aim for snappy and entertaining, there’s a background of moral seriousness: you have a responsibility when you build systems. I hope these maxims will ask for your best thinking, rather than dumb things down.
Which means this kind of mindset demands discipline. It often means emphasising doing the boring things: writing tests, refusing tempting shortcuts, always asking “why.”
The tech world is overloaded with frameworks, patterns, hype. Many guides tell you how to do things, fewer help you decide why you should do them. My Enchiridion is in that smaller class. It forces perspective, not just pattern. It’s meant to keep you honest. To keep you useful.
Some highlights from the past weeks
Here are some highlights from the past couple of weeks:
Why an Enchiridion on Software Development?
Why does this handbook even matter? Because people in software engineering often drift: lose sight of what matters. The enchiridion is meant to restore clarity. It’s not academia; it’s not buzz. It’s grounded.
Before Tech, Explore Context & Impact
Software is never in a vacuum. Think why before how. Impact trumps tech for tech’s sake. Understand the context first. If what you build doesn’t matter, you are building for nothing.
Control What You Can, Ignore What You Can’t
This is tightly written: focus your effort where you have leverage. Don’t waste time pretending to master what’s uncontrollable. A lot of engineering stress comes from trying to fight the un-fightable. Let go of it.
Make Reality Your Spec: Tests Before Opinion
Reality checks are non-negotiable. Test to validate assumptions before you commit to design or ideology. Opinions are cheap; tests cost something, but deliver truth. Use them early.
Some Emerging Core Principles
From the maxims so far, these are some of the principles that are starting to stretch across the work:
Clarity over complexity. If you don’t know why you’re doing something, you probably shouldn’t be doing it.
Action over theory. Being right matters less than being useful.
Humility. Know what you can’t control. Assume there’s something you don’t know.
Reality as arbiter. Opinions, feelings, doctrines — they must yield to what works, empirically.
Impact first. Your goal is use, benefit, effect — not elegance or purity for their own sake.
Some Final Thoughts
I hope folks are starting to find the stream of enchiridion posts useful, even inspiring. There’s a lot more to come, I have around 600+ in their infancy that have been collated over the past 10 years (ish).
My hope is that these things will become your own handheld guide. Not perfect. Not complete. But damn useful.