Every book here is one I have read end to end. I have left off the ones everybody lists and nobody finishes, and where a book is overrated or badly aged I say so, because a recommendation list where everything is a nine out of ten is worth nothing.
System design and architecture
If you are preparing for interviews, start with Alex Xu and move to Kleppmann. If you are designing something real, start with Kleppmann and never really stop.
Designing Data-Intensive Applications (2nd Edition)
The reference text on how storage, replication, consistency, and stream processing actually behave under load.
This is the book I have re-read the most. Almost every architecture decision I get right traces back to a chapter in here — particularly the replication and consistency material, which is the part most engineers hand-wave and then get paged about at 3am.
Skip it if: You want quick answers. It is dense, and the payoff comes from reading it slowly.
Check current priceSystem Design Interview – An Insider's Guide (2nd Edition)
Sixteen worked system design problems — URL shortener, rate limiter, chat, notifications — each solved end to end.
The best structured walkthrough of the interview format. What it teaches is the sequence: clarify, estimate, draw the high level, then go deep on one component. That sequence is the actual skill.
Skip it if: You are past interviews and want depth rather than breadth. Go to Kleppmann instead.
Check current price Kindle editionSystem Design Interview – An Insider's Guide: Volume 2
A harder problem set: payment systems, hotel reservation, metrics monitoring, ad click aggregation.
Volume 1 teaches the format. Volume 2 is where the problems start to resemble things you will genuinely be asked to build. The payment system and metrics aggregation chapters are the standouts.
Check current price Kindle editionFundamentals of Software Architecture (2nd Edition)
A survey of architecture styles with the trade-offs made explicit, plus the soft skills the role actually requires.
The chapter on architecture characteristics — treating 'scalability' and 'elasticity' as distinct, measurable things you trade against each other — changed how I write design docs. It gave me vocabulary for arguments I had been losing.
Check current price Kindle editionSoftware Architecture: The Hard Parts
How to decompose a monolith when there is no clean answer: distributed data, transactional sagas, service granularity.
Every other architecture book shows you the finished microservice diagram. This one sits in the ugly middle where you have to split a shared database and nobody is happy. That is where real work happens.
Check current price Kindle editionBuilding Microservices (2nd Edition)
The practical guide to service boundaries, deployment, testing, and the organisational cost of distribution.
The second edition is notably more sceptical than the first, which is why I trust it. Newman spends real pages on when *not* to do this. Read it before you split anything.
Check current price Kindle edition
AI engineering
The field moves fast enough that most books age badly. These three have not, because they teach the engineering discipline around models rather than the API surface of any particular one.
AI Engineering: Building Applications with Foundation Models
The engineering discipline around foundation models: evaluation, prompting, RAG, finetuning, inference optimisation, and architecture.
The single most useful book for the job I actually do. The evaluation chapters in particular — Huyen is unusually clear that if you cannot measure your AI system, everything downstream is vibes.
Check current price Kindle editionDesigning Machine Learning Systems
End-to-end ML system design: data engineering, feature stores, deployment, monitoring, and drift.
Predates the LLM wave and is better for it. The chapters on data distribution shift and monitoring apply exactly as well to a RAG pipeline as they did to a recommender, and almost nobody building agents today has read them.
Check current price Kindle editionBuild a Large Language Model (From Scratch)
Implements a GPT-style model in PyTorch, step by step, from tokeniser to finetuning.
You do not need this to build products on top of models. You need it to stop treating them as magic. Working through the attention implementation changed how I write prompts, because I finally understood what the context window physically is.
Skip it if: You want to ship an app this month. This is a study project, not a manual.
Check current price Kindle edition
Engineering leadership
I read most of these while scaling a team from four engineers to thirty-five, usually about two months later than would have been useful.
From Code to Culture
My book on building engineering teams at high-growth startups — hiring, culture, and the transition from writing code to building the organisation that writes it.
I wrote this because the advice I was given when I first became a manager was either abstract enough to be useless or specific to companies a hundred times my size. This is what I actually did, including the parts that did not work.
Check current priceThe Manager's Path
The engineering management career ladder, one chapter per rung: mentor, tech lead, manager, director, VP.
The book I give every new manager. Its real value is showing you the next rung before you are on it, so the jump is a decision rather than a surprise.
Check current price Kindle editionAn Elegant Puzzle: Systems of Engineering Management
Engineering organisations treated as systems — sizing teams, managing migrations, allocating headcount, and running the process around all of it.
Larson's framing of team size as a systems constraint is the thing I quote most. When I was scaling a team from four to thirty-five, this is the book that stopped me from making the obvious mistakes twice.
Check current price Kindle editionStaff Engineer: Leadership Beyond the Management Track
What senior individual contributors actually do, told through interviews with staff and principal engineers.
The most honest account of the IC track I have read, largely because the interviews contradict each other. There is no single staff engineer job, and the book has the confidence to say so.
Check current price Kindle editionTeam Topologies
Four team types and three interaction modes as a design language for organisational structure.
Short, and the ideas stick. Once you have the vocabulary of stream-aligned versus platform teams, a whole class of org dysfunction becomes nameable — and things you can name, you can fix.
Check current priceAccelerate
The research behind the four DORA metrics and what statistically separates high-performing engineering organisations.
This is the book to bring when someone senior wants to measure productivity in story points. It replaces a bad argument with evidence, and the four metrics have held up remarkably well.
Check current price Kindle editionThe Phoenix Project
A novel about an IT organisation in crisis that turns into a DevOps primer.
The fiction framing is divisive and the business-novel dialogue is rough. I still recommend it, because it is the only book on this list a non-technical executive will actually finish, and getting them to understand work-in-progress limits is worth the awkward prose.
Skip it if: You already believe in DevOps. You will find it long.
Check current price Kindle edition
Craft and code
The slow-burn books. None of them will help you ship this week; all of them change how you write code over a decade.
Clean Code: A Handbook of Agile Software Craftsmanship
Naming, function size, comments, error handling, and boundaries — the line-level habits of readable code.
The most-argued-about book on this list, and still the one I would hand a junior engineer first. Take the chapters on naming and function size, which are excellent and uncontroversial. The later object-oriented dogma has aged less well, and reading it next to Ousterhout is the honest way to get both sides.
Skip it if: You are already senior. You have absorbed the good parts by osmosis and will spend the book arguing with it.
Check current price Kindle editionA Philosophy of Software Design (2nd Edition)
Complexity as the central problem of software, and deep modules as the main tool against it.
Short, opinionated, and the best counterweight to Clean Code — Ousterhout argues directly against several of Martin's rules, particularly on function length. The distinction between tactical and strategic programming is the idea I have quoted most often in code review.
Check current price Kindle editionCracking the Coding Interview (6th Edition)
189 programming questions with worked solutions, plus the mechanics of how big-tech interview loops actually run.
Still the default for coding-round preparation, and the non-coding chapters are underrated — how offers work, how to handle the behavioural round, what the interviewer is scoring. Pair it with Alex Xu for the system design round.
Skip it if: You want current online-judge practice. The problem set is a decade old and platforms like LeetCode have overtaken it for drilling.
Check current priceThe Pragmatic Programmer (20th Anniversary Edition)
A collection of practices and heuristics for the day-to-day work of writing software well.
The book I would hand a version of myself ten years ago. The anniversary edition has aged better than it had any right to — the material on orthogonality and reversibility of decisions is more relevant now, not less.
Check current priceRefactoring (2nd Edition)
A catalogue of behaviour-preserving code transformations, with the mechanics of each spelled out step by step.
Use it as a reference, not a read-through. The value is in having names for the moves — once 'extract function' and 'replace conditional with polymorphism' are shared vocabulary, code review gets dramatically faster.
Check current price Kindle editionClean Architecture
Dependency rules and boundary design — keeping business logic independent of frameworks, UI, and databases.
I disagree with parts of it and still recommend it. The core argument, that your framework is a detail and should not be the centre of your application, is one most codebases violate and pay for later.
Skip it if: You want prescriptive folder structures. It is more principle than recipe, and taken too literally it produces a lot of pointless indirection.
Check current price Kindle editionDomain-Driven Design
Modelling complex business domains in code: ubiquitous language, bounded contexts, aggregates.
Bounded contexts are the single most useful idea for anyone drawing service boundaries, and this is where they come from. Read the strategic design section — part four — before you read the rest.
Skip it if: You are early. The book assumes a domain complex enough to be worth modelling, and most products are not there yet.
Check current price
Reliability and operations
What to read before the pager goes off rather than after.
Release It! (2nd Edition)
Stability and capacity patterns — circuit breakers, bulkheads, timeouts — written as a catalogue of real outages.
This is the book that taught me to think in failure modes rather than happy paths. It is directly why Codelit has a chaos mode: the idea that you should be able to see a cascading failure before it happens came straight out of these pages.
Check current price Kindle editionSite Reliability Engineering
How Google runs production: error budgets, SLOs, on-call design, and the economics of reliability.
The error budget chapter is worth the whole book. It is the cleanest framing I know for the argument between shipping fast and staying up, and it converts that argument from opinion into arithmetic.
Skip it if: You are a team of three. Much of this assumes Google-scale headcount — take the SLO chapters and leave the rest.
Check current price Kindle edition
Common questions about this list
- What is the single best book for learning system design?
- Designing Data-Intensive Applications by Martin Kleppmann, if you are designing real systems. It explains how storage, replication, and consistency actually behave rather than presenting a catalogue of diagrams. If you are specifically preparing for an interview in the next few weeks, Alex Xu's System Design Interview Volume 1 is the faster path, because it drills the format: clarify, estimate, sketch the high level, then go deep on one component.
- Which books should a new engineering manager read first?
- The Manager's Path by Camille Fournier, then An Elegant Puzzle by Will Larson. Fournier maps the career ladder one rung at a time so you can see the next role before you are in it. Larson treats the organisation as a system, which is the mental shift that makes headcount, team size, and migrations tractable instead of overwhelming.
- Are books still worth reading for AI engineering when the field moves this fast?
- Yes, but only the ones that teach discipline rather than API surface. Chip Huyen's AI Engineering and Designing Machine Learning Systems both hold up because evaluation, data drift, and monitoring do not change when the model does. Anything organised around a specific provider's SDK is obsolete before it ships.
- Do I need to read Designing Data-Intensive Applications cover to cover?
- No. The middle of the book — replication, partitioning, transactions, and the chapter on what goes wrong in distributed systems — carries most of the value, and that is where to start. The stream processing material toward the end is excellent but only becomes urgent once you are actually running event pipelines. Note that the second edition, co-written with Chris Riccomini, shipped in March 2026 and reorganises some of this, so chapter numbers from older reading guides no longer line up.
- How were these books chosen?
- Every book listed is one I read end to end and still return to. Books I started and abandoned are not here, and where a book is overrated or has aged badly I say so in its entry rather than leaving it off. The list is deliberately short — around two dozen books drawn from fifteen years of practice, not a hundred titles nobody could finish.
If you want the working notes rather than the reading list, the blog is where I write up what actually happened when I applied this stuff — building Codelit, scaling a team from four engineers to thirty-five, and the parts that went badly.