The engineering frameworks that actually hold up: Carmack, Hopper, Torvalds and the documented method

Software engineering is unusual among disciplines in how much of its best thinking survives in a form you can actually read: mailing list threads, conference talks, internal memos, and a handful of unusually candid books. John Carmack reasons from what the machine is actually doing rather than the abstraction the language presents. Grace Hopper built a compiler while colleagues insisted the idea wasn't workable. Linus Torvalds has defended two decades of kernel architecture decisions in public correspondence that doubles as a design rationale anyone can still read. This guide takes the collection's signature frameworks in turn, with the documented practice or talk behind each, before addressing where the field's genuinely different schools of thought disagree.

None of these frameworks were written as generic advice for engineers in the abstract. Each came out of a specific, high-stakes problem, an unreliable early compiler, a mission computer with no room for silent failure, a kernel maintained by thousands of contributors with no single point of authority, which is worth keeping in mind before applying any one of them outside the conditions that produced it.

First-principles engineering

Carmack's documented approach, visible across decades of public technical writing and interviews, is to reason from what the hardware and the mathematics actually require rather than from the abstraction a language or framework presents as the default way to think about the problem. His early work on fast inverse square root approximations and software rendering techniques is frequently cited as an example of stripping a problem to what the machine can actually do cheaply, rather than accepting the general-purpose library solution as the only option.

A worked example: a team debugging a performance problem by adding caching layers on top of a slow database query is treating the symptom at the abstraction layer where it's visible. First-principles engineering asks what the query is actually doing at the storage level, index structure, disk access pattern, before assuming the fix belongs at the application layer where the slowness merely became noticeable.

Where it fails: first-principles engineering requires genuine depth in the underlying layer, which is a reasonable expectation for a narrow, performance-critical system and an impractical standard to hold every engineering decision to; a team that insists on reasoning from hardware fundamentals for a routine CRUD application is applying the right discipline to the wrong scale of problem.

Decomplecting

Hickey's framework, developed most fully in his widely watched talk Simple Made Easy, distinguishes between simple (unbraided, one concern at a time) and easy (familiar, close at hand) as two different properties that are often conflated. His central claim is that object-oriented state management, bundling identity, mutable state and behaviour into one unit, is easy to write initially but complects three genuinely separate concerns, making each harder to reason about independently than if they had been kept apart from the start.

A worked example: a class that manages both a user's session state and the logic for validating that session complects two concerns that could be decomplected: a pure data structure representing session state, and a separate function that validates it. Decomplected, the validation logic can be tested and reasoned about without needing to construct or mutate the stateful object at all.

Where it fails: decomplecting has a real cost in indirection; a codebase decomplected aggressively can require a reader to trace across more files and functions to understand one piece of behaviour, which is a genuine trade against the easier, if more tangled, single-location version, and Hickey's own framework doesn't specify exactly where that trade stops paying off.

Reliability as a discipline

Hamilton's work on the Apollo Guidance Computer, documented in her own later interviews and in the history of the Apollo programme, treated software errors as a category of risk requiring the same rigour as other engineering disciplines, at a time when software was often treated as inherently less formal than hardware engineering. Her team built extensive error-checking and recovery logic into the Apollo systems specifically because they treated failure as something to design against systematically, not something to patch reactively.

A worked example: during Apollo 11's lunar descent, the guidance computer began throwing unexpected alarm codes from an overloaded task queue. The documented reason the mission wasn't aborted was that Hamilton's team had built the system to prioritise critical landing tasks and shed lower-priority ones automatically under overload, exactly the kind of designed-in reliability behaviour that only exists because someone treated the failure mode as foreseeable rather than exceptional.

Where it fails: reliability engineering at this level of rigour has a real cost in time and process overhead that is justified for mission-critical or safety-critical systems and difficult to justify for a fast-moving product where the cost of a contained, recoverable bug is genuinely lower than the cost of the engineering discipline required to prevent it.

Strong opinions, weakly held

Torvalds's kernel mailing list correspondence, spanning over three decades of public record, documents a consistent pattern: defending a specific technical position on architecture or a submitted patch in detail, with specific technical reasoning, while remaining demonstrably willing to reverse that position when presented with evidence the original reasoning was wrong. The discipline is holding the position firmly enough to force real scrutiny, not holding it regardless of what the scrutiny reveals.

A worked example: kernel development is documented as having reversed major architectural decisions, including significant changes to the kernel's locking model and scheduler, following sustained public technical argument on the mailing list, cases where Torvalds's own initial position was the one that changed after the technical case against it held up.

Where it fails: the framework requires genuinely separating the technical argument from the manner of its delivery, and Torvalds's own communication style during parts of that correspondence has drawn public criticism, including a documented public apology and temporary step back he took in 2018 to address it, which is worth reading as an acknowledged limitation of how the discipline was practised, not an endorsement of the tone as part of the method.

Simplicity and tool composability

Kernighan's Unix philosophy, documented across decades of writing including the influential book he co-authored, The Unix Programming Environment, holds that small tools doing one thing well, composed through simple shared interfaces, outperform large integrated systems trying to do everything. The philosophy's practical form was the pipe: a tool's output becomes another tool's input without either tool needing to know about the other's internals.

A worked example: rather than building one large utility to search, filter and reformat log files, the Unix approach chains grep, sort and awk, each doing one narrow job, through pipes, producing a result that's easier to modify (swap one tool) than a monolithic utility would be to patch.

Where it fails: the composability that makes small tools powerful for a single user's command-line workflow doesn't transfer cleanly to distributed systems, where composing small services introduces network calls, partial failure, and coordination overhead that a local pipe never had to account for; the philosophy's simplicity is partly a function of the tools running in the same process on the same machine.

Literate programming and mathematical rigour

Donald Knuth's contribution, developed across his multi-volume The Art of Computer Programming and his own literate programming methodology, treats source code as a document meant to be read and understood by another person first, with correct execution as a downstream consequence of clarity rather than the sole goal. His documented practice of interleaving code with prose explanation, in a form meant to be read start to finish like a technical essay, was a deliberate rejection of the assumption that code's only audience is the compiler.

A worked example: Knuth's own TeX typesetting system, still in wide use decades after its release, was documented and published as a literate program, with the reasoning behind each design decision recorded alongside the code itself, a practice credited with making the system unusually maintainable and auditable long after its original author moved on to other work.

Where it fails: literate programming's overhead, writing genuine explanatory prose alongside every piece of logic, is difficult to sustain under the delivery pressure most commercial software teams operate under, and the discipline has seen far more adoption in long-lived scientific and reference software than in fast-moving commercial products where the documentation burden competes directly with shipping speed.

Where the field's schools of thought actually disagree

The apparent unity of "good engineering practice" hides a real disagreement about where complexity should live. Hickey's decomplecting argues for pulling concerns apart even at the cost of more indirection. Kernighan's Unix philosophy argues for composing small, simple pieces rather than building integrated systems. Carmack's first-principles approach argues for depth in the specific layer that matters most for a given problem, accepting less generality elsewhere. None of the three is simply correct in general; each optimises for a different failure mode, unmanageable coupling, unmanageable integration, and unmanaged performance, and a working engineer typically needs judgement about which failure mode a given system is actually at risk of.

---

The Developer category collects these frameworks, and others including Donald Knuth, Barbara Liskov and Tim Berners-Lee, as downloadable .md files for Claude, ChatGPT or any LLM. Andrej Karpathy, John Carmack, Linus Torvalds and six others also appear in The Engineer's Stack, a ten-persona bundle for the decisions a working engineering career actually spans.