Reading List

The Timeless Way of Building
Alexander's foundation for everything that follows. Quality in buildings (and by extension, in anything we make) comes not from imposed design but from patterns of life that emerge naturally. The On Design page draws heavily from this — his 27 principles of the timeless way are reproduced there in full.
A Pattern Language
The companion to Timeless Way. A catalog of 253 interconnected patterns for towns, buildings and rooms. The idea that complex systems can be described as networks of named, reusable patterns influenced software's own pattern movement — and the way this site organizes ideas by topic owes something to Alexander's structure.

Zen and The Art of Motorcycle Maintenance
The book that asks "what is Quality?" and never quite answers it, which is the point. Pirsig's insistence that Quality is real but undefinable runs through the Incomplete Philosophy page and the Zen and the Art of Software draft. His motorcycle maintenance as metaphor for caring about craft is the spirit of this whole site.
Lila
Pirsig's sequel, where he builds a Metaphysics of Quality — a framework for understanding value as the primary reality. Harder, stranger, and more systematic than ZMM. The idea that static and dynamic quality must be balanced maps well onto the tension between stable code and adaptable code.

The Lost Tools of Learning
A short essay arguing that education should teach people how to think and learn, not just what to know. The trivium (grammar, logic, rhetoric) as a framework for mastering any subject. Relevant to how we approach learning new codebases and technologies — first understand the vocabulary, then the structure, then express ideas fluently.

The Design of Design
Brooks on the design process itself — how designers actually think, how constraints shape solutions, and why rational models of design don't capture what really happens. Connects to the ideas in On Design about design being a process of discovery rather than specification.
The Mythical Man Month
The classic on why adding people to a late project makes it later, and more broadly, why software is hard to build with teams. Essential context for the Working with Other People page — communication overhead is real and collaboration has to be intentional.

The Design of Design
An engineer's perspective on design as a discipline, written decades before Brooks' book of the same name. Short, opinionated, and practical. Glegg makes the case that design is neither art nor science but its own thing — a view that resonates with Dieter Rams' principles on the On Design page.

The Pragmatic Programmer
The software craft handbook. "Coding by Coincidence" (referenced in Zen and the Art of Software) is from here — the idea that most developers don't know why their code works, just that it does. The AAA Structure page and the refactoring drafts are practical applications of the pragmatic mindset.

Clean Code
Martin's rules for writing code that humans can read. Naming, functions, formatting, error handling — the mechanics of clarity. The Code — The Small Things draft and the Refactoring Naming draft are both working in this territory. Agree or disagree with Martin's specifics, the discipline of caring about code at the line level matters.

Software Design for Flexibility
A case for building systems that can adapt to changing requirements by designing with combinators, generic operations and layered architectures. Directly relevant to the ideas in On Maintaining Code — writing code that's ready for change means building in flexibility from the start, not bolting it on later.

Structure and Interpretation of Computer Programs
The classic MIT text on thinking about computation as a medium for expressing ideas, not just a way to get machines to do things. Its emphasis on abstraction, managing complexity and building systems from simple, composable parts echoes throughout the Refactoring and AAA Structure pages.

Story
McKee's masterclass on narrative structure, written for screenwriters but applicable to anyone who needs to communicate ideas. Story structure — setup, conflict, resolution — turns out to be a useful lens for technical writing, presentations and even commit messages. The discipline of "what's the story here?" helps cut through noise.