For the software engineer — grounded in the canon
Build software that lasts — read from the field's best books, not the framework of the week.
The software-craft canon is deep and often ignored. This is the reconciled version: what the best books on design, architecture, delivery, and operability actually agree on — where the experts genuinely disagree (and how to choose), cited per claim, light enough to carry. A bicycle for your craft. You still pedal.
How a guide actually reads
MisconceptionMore modules, smaller pieces, and more services automatically mean better design.
RealityWhat matters is loose coupling and high cohesion, not granularity. A Philosophy of Software Design shows that splitting into many shallow modules adds interfaces — and interfaces are complexity. The microservices books warn that over-decomposition produces a distributed monolith or a big ball of distributed mud, which is worse than the original. Depth and cohesion are the targets; small size is a sometimes-consequence, not the goal.
from the “Decoupling and Modular Boundaries” section of Build Software That Lasts — grounded in A Philosophy of Software Design (2nd Edition), The Pragmatic Programmer (20th Anniversary Edition), Domain-Driven Design: Tackling Complexity in the Heart of Software, Software Architecture: The Hard Parts
Why this is different
Grounded
A free summary is one voice with no receipts. Here, every claim traces to the books behind it — we read the canon so you don’t have to, and show the sources.
Aware
We take the comprehensive view — naming where the field broadly agrees and where the outliers are. On the outliers we take a position, weighed by the type and quality of the evidence behind it: the author’s, or our own research.
Essential
Not exhaustive, not thin — only what’s load-bearing, ordered as a journey from foundations to the summit. Light enough to carry.