Reading list

Paul Graham

Hackers & Painters

Programming as a creative craft, closer to painting than to civil engineering. It is the book the hackers&wizards name comes from, and the reason I keep technology work human even as more of it gets automated.

Nicole Forsgren, Jez Humble, Gene Kim

Accelerate

The research behind DORA. This is the book I reach for when someone wants to argue that quality slows teams down. It does the opposite, and Accelerate has the data to show it.

Sam Newman

Building Microservices

Newman shaped how I think about system boundaries and the team structures around them. That thinking ran straight through the architecture work at Breuninger and BLUME 2000.

Eric Evans

Domain-Driven Design

Evans gave me the language for aligning a system with the business it serves. Most architecture arguments I have seen are really arguments about where a domain boundary should sit.

David Farley

Modern Software Engineering

Farley treats software development as an experimental practice: build feedback loops, run small experiments, let the results decide. Reading it moved me off gut feeling more than any single pattern.

Robert C. Martin

Clean Architecture

A clear account of how to organize code so it can change later. I do not agree with every line, but the core ideas show up in every architecture review I do.

Google

Site Reliability Engineering

The book that connected how I think about monitoring, incidents, and operations. Reliability is a feature, and this is where that clicked for me.

Gregor Hohpe

Platform Strategy

Hohpe writes about platforms and enterprise architecture without losing the plot. Useful once an engineering organization gets large enough that the platform becomes the product.

L. David Marquet

Turn the Ship Around!

The clearest book on leadership I have read. Marquet ran a nuclear submarine by giving control away instead of giving orders. It changed how I lead: the goal is not to be the smartest person in the room.

L. David Marquet

Leadership Is Language

The follow-up, and it refined how I talk to teams. Small changes in how you phrase a question change who feels free to think.

Patrick Lencioni

The Five Dysfunctions of a Team

A short, sharp model of how teams fail, starting with the absence of trust. I have watched every layer of Lencioni's pyramid play out in real teams.

Daniel Coyle

The Culture Code

Coyle looks at what high-performing groups actually do, and most of it is small and unglamorous. Good companion reading to Lencioni.

Matthew Skelton, Manuel Pais

Team Topologies

A practical way to think about team structure and cognitive load. It gave me vocabulary for decisions I had been making on instinct.

Daniel Kahneman

Thinking, Fast and Slow

Kahneman maps the biases in how people decide. If you build systems other people use, this is not optional reading.

Max Tegmark

Life 3.0

Tegmark asks what happens to human purpose when machines get very good at almost everything. The zoo scenario has stayed with me for years.

Cathy O'Neil

Weapons of Math Destruction

O'Neil shows how algorithms quietly encode bias and cause harm at scale. A necessary counterweight to any optimism about automation.

Stuart Russell

Human Compatible

Russell's account of the AI alignment problem, written by someone who helped build the field. It is why I think about AI as something that assists people rather than replaces them.

Donella Meadows

Thinking in Systems

The book that taught me to look for feedback loops instead of single causes. It changed how I read both code and organizations.

Diana Montalion

Learning Systems Thinking

A newer book that brings systems thinking down to the everyday work of engineering. Practical where Meadows is foundational.

Alexander Osterwalder

Business Model Generation

A visual way to map how a business actually makes money. Useful for connecting architecture decisions to where the value is.

Peter Senge

The Fifth Discipline

Senge on the learning organization. It shapes how I think about how teams build and pass on knowledge.

Annie Duke

Thinking in Bets

Duke, a former poker player, on deciding well under uncertainty. It separates a good decision from a good outcome, which is harder than it sounds.

Dave Snowden

Cynefin

Snowden's framework for telling apart the simple, the complicated, and the complex, and acting differently in each. It stops me from applying the wrong kind of fix.

Liu Cixin

The Three-Body Problem trilogy

The best thing I have read on the unintended consequences of progress. When I get excited about a new technology, Liu is the voice asking about the second and third-order effects.

William Gibson

Neuromancer

The book that built the cyberpunk imagination. Gibson saw the shape of networked life decades early.

Isaac Asimov

The Foundation series

Asimov on whether you can predict and steer the path of a whole civilization. It connects to my interest in measuring systems, and to the limits of that idea.

Software engineering is an experimental practice.

David Farley

Farley made me treat software development like science. Not the lab-coat kind, the kind where you build feedback loops, run small experiments, and let the results tell you what to do next. That shift changed how I work more than any single architecture pattern.

As independent as possible, as integrated as necessary.

Stefan Tilkov

Tilkov gave me Self-Contained Systems, the pattern between microservice sprawl and a monolith. His quieter point: boundaries follow business capabilities, not the org chart, and not the database schema. He passed away in 2024. I still hear his framing every time a team argues about where to draw a line.

Refactoring isn't cleanup work. It's how good software gets built.

Martin Fowler

Fowler taught me that good architecture is not a perfect drawing you make on day one. It is a system that can change as you understand the problem better. The enemy was never change. It was the inability to change.

Make it work, make it right, make it fast.

Kent Beck

Beck taught me that the bravest technical decision is usually the simplest one. Test-driven development was never really about tests for me. It is about writing code other people can read and change.

Quality enables speed.

Nicole Forsgren

Forsgren put numbers on something the field used to argue about with feelings. The DORA research made delivery measurable, and DORA metrics became my shared language with executives.

Don't move unless you're certain.

L. David Marquet

Marquet ran a nuclear submarine by giving control away instead of giving orders. It changed how I lead: the goal is to build the conditions where everyone else makes better decisions than I could.

Happy engineers build better products.

Gene Kim

Kim connected technical practice to business outcomes in a way that finally made sense to developers and executives at the same table. He gave me the words to explain why developer experience and customer experience are the same conversation.

The zoo scenario: people kept comfortable, and quietly without purpose.

Max Tegmark

Tegmark asks the questions I cannot answer and should not ignore. His writing shaped how I think about efficiency. The interesting question is not how fast we can go. It is where we are trying to arrive.

System 1 and System 2: fast, automatic thinking and slow, effortful thinking.

Daniel Kahneman

Kahneman mapped the biases in how people decide. When people keep making the wrong choice, the honest conclusion is usually that the design is wrong, not the people.

Hackers build, painters create. Technology as creative work.

Paul Graham

Graham's essays make the case that programming is a creative craft. Hackers & Painters is where the hackers&wizards name comes from, and the reason I still think technology work should stay human.

Every solution creates new problems.

Liu Cixin

Liu's Three-Body trilogy is the best thing I have read on the unintended consequences of progress. When I get excited about a new technology, Liu is the quiet voice asking about the effects I have not thought through yet.