Books That Shaped How I Build

For years I read books that mattered to me and never wrote down why. When I finally laid them out together, on the bookshelf, they stopped looking like separate genres. Clean code, platform strategy, trading psychology and a science-fiction series about a rogue AI keep making the same few arguments. These are the five I hear most.

1. Make change cheap

Change is unavoidable. It is ubiquitous, omnipresent, and inevitable.

That line from Sandi Metz is my favourite quote of all time, and it’s the root of this whole section.

Sandi Metz says it outright in Practical Object-Oriented Design in Ruby: the purpose of design is to reduce the cost of change. Ruby is where I first shipped something real, an A-level coursework platform for teachers whose classroom seating-plan generator placed students by rules (never two disruptive students side by side). Each rule was its own small object answering one question, so adding a rule never meant rewriting the rest. I didn’t have the vocabulary then; Metz gave it to me.

Fowler’s Refactoring shows the mechanics, tiny behaviour-preserving steps with tests underneath, and Clean Code is the everyday discipline that keeps those steps possible. Taking a large codebase to zero TypeScript errors one small merge request at a time is the most refactoring-shaped thing I’ve done (Driving a TypeScript Codebase to Zero Errors).

Gregor Hohpe’s Platform Strategy makes the same argument at organisational scale: a good platform lowers the cost of change for every team built on it. It’s also how I train. Small, repeatable increments you can back out of, which is the whole idea behind Progressive Overload and Incremental Migration.

2. Flow beats heroics

The Phoenix Project taught me that work in progress is the hidden killer, and that the most heroic person on the team is often the bottleneck. When I moved on from a platform I’d led the UI of, the most useful thing I could do was stop being that person: structured handover sessions, written docs and a clean backlog (Knowledge Transfer Before Moving On).

The Five Dysfunctions of a Team explains the human side: without trust there’s no honest conflict, and without that nobody really commits. It was given to me early in my career at Elanco, and it’s where I started working out what kind of leader I wanted to be. A mentoring session a couple of years later turned that into a short list I still use: empower people rather than force them, lead by example, build a coaching culture, and be consistent and predictable without micromanaging. Chairing a cross-team UI guild was where I got to practise it (Chairing a Cross-Team UI Guild).

Thinking in Platforms joins them up. It treats recurring knowledge work as a production system and designs the paths work actually takes, so nobody has to be a hero. That’s what Golden Paths and DORA Metrics are for, and why You Can’t Serve Two Masters.

3. Design for the people who use it, and now the agents too

Users Not Customers argues that in digital products the user’s experience is the business. Mary Thengvall’s The Business Value of Developer Relations (the avocado book) applies that to developers: you earn a technical community, you don’t market at it. Building Digital Culture adds that none of it sticks without a culture change first.

I apply all three to internal platforms. Developers are the users, adoption is earned through guilds, docs and demos rather than mandated, and an Internal Developer Platform nobody enjoys using has failed. The new twist from Thinking in Platforms is that AI agents are users of the platform too (What Makes an AI Agent).

4. Discipline under uncertainty

Mark Douglas’s Trading in the Zone and The Disciplined Trader are the most useful psychology books I’ve read, and they’re about trading. Any single outcome is random and your edge only shows up over many attempts, so you set rules before you start and follow them when your emotions argue. The Naked Trader and Trading for Dummies gave me the rules and the vocabulary, and a CFA Level 1 prep course this year filled in the fundamentals. Options as a Strategic Investment showed me how much more there is to learn: I started it and found it a lot to take in, so it’s now a reference.

What I took from all of them is a way of thinking for work where change is completely out of your control: set your rules, act, and let the outcome be. It’s my favourite quote again in another domain.

The psychology transfers. Incidents, estimates and training plateaus all reward the same stance: accept the risk up front, trust the process, review honestly afterwards. That’s Balance Is a Control Loop and Deloads Are Tech-Debt Sprints in another domain.

5. Show the signal, not the noise

Tufte’s The Visual Display of Quantitative Information is the reason I’m suspicious of chart decoration: above all else, show the data. Building dense, real-time trading views, that means fewer flourishes and more signal, and keeping the render loop calm while data pours in (Zustand Transient Updates).

Node.js Design Patterns and Architecting the AI-Driven Node.js Backend are the same lesson on the server: respect the event loop, use backpressure, and treat slow or unreliable dependencies, model calls included, as things to queue, observe and govern (Observability).

The stories underneath

The fiction set the mood for all of it. Star Scrapper made me take AI risk seriously long before I had to as an engineer: there’s a fine balance between what AI can do for us and what it can do to us. The Hitchhiker’s Guide to the Galaxy gave me Deep Thought and 42, the best parable I know for prompting (a perfect answer to a vague question is useless). And Ready Player One and Ready Player Two are a reminder that whoever owns the platform owns the world inside it, and that technology should connect people rather than replace real life.

What I’m reading next

I’ve just finished Platform Strategy and I’m reading Domain-Driven Platform Engineering by Ajay Chankramath and Eamonn Ryan, which takes Hohpe’s DDD lens (Where Platforms Fit: DDD Subdomains) to enterprise scale. After that, the rest of the AI Backend Architecture series, and going back to the options book more slowly. When a book changes how I work, I’ll add it to the bookshelf with its own page of notes.