Books I recommend

Engineering books I keep coming back to. Hover over a spine to pull a book out, then click it to take it off the shelf. The shelf comes in two builds; switch between them to compare, or read the trade-offs.

Trade-offs ↓

Pull a book off the shelf to see why it is worth reading.

Covers © their publishers, shown to identify each book.

Pull a book off the shelf to see why it is worth reading.

Covers © their publishers, shown to identify each book.

.bookshelf-views { display: none; }

Designing Data-Intensive Applications by Martin Kleppmann (2017): The clearest map of how data systems work: storage engines, replication, partitioning, transactions and streams, and the trade-offs between them. It teaches no product; it teaches you to reason about all of them. Read it before you pick a database, not after.

The Pragmatic Programmer by David Thomas, Andrew Hunt (2019): A book of habits, not technologies: own your work, don't repeat yourself, fire tracer bullets, fix broken windows. The advice has aged well because it is about how you work, not what you work with. Read it early, then again every few years.

A Philosophy of Software Design by John Ousterhout (2021): A short, opinionated book with one big idea: complexity is the enemy, and deep modules with simple interfaces are how you fight it. It names things you argue about in code review every week: shallow modules, information leakage, defining errors out of existence.

Site Reliability Engineering by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2016): How Google runs production: error budgets, SLOs, toil, on-call and blameless postmortems. Not every practice fits a small team, but measuring reliability and budgeting for failure work anywhere.

Working Effectively with Legacy Code by Michael Feathers (2004): Practical ways to change code that has no tests: find a seam, break a dependency, get it under test, then change it. Most of a career is spent in code like this, and this book makes it bearable.

Thinking in Systems by Donella H. Meadows (2008): Not a software book, but it changes how you see software: stocks, flows, feedback loops, delays, and why systems resist the fixes we push on them. It is short and readable, and the chapter on leverage points is worth rereading.

Domain-Driven Design by Eric Evans (2003): Argues that the hard part of software is the business domain, not the technology. It teaches you to build a shared language with the people who know the domain, and to carve the code into models that match it. Read it before a large rewrite or a service split.

Software Engineering at Google by Titus Winters, Tom Manshreck, Hyrum Wright (2020): How Google keeps a huge codebase healthy over decades: code review, testing, build systems, deprecation and a monorepo. It separates programming from software engineering, which is programming integrated over time. Read it to see what scale does to ordinary practices.

An Elegant Puzzle by Will Larson (2019): Treats engineering management as a set of systems problems: sizing teams, managing technical debt, onboarding, migrations and reorgs. Each chapter is a model plus the stories behind it. Read it when your team starts to grow.

The Staff Engineer's Path by Tanya Reilly (2022): A guide for engineers who lead without managing: big-picture thinking, working with people across teams, and setting direction. It names the skills that code alone does not teach. Read it before or just after you step into a staff role.

Staff Engineer by Will Larson (2021): Leadership beyond the management track: what staff engineers do, the four archetypes, and how to pick projects and build sponsors. The second half is thirty interviews with working staff engineers. Read it for the range of ways the role can look.

Drive by Daniel H. Pink (2011): Argues that carrots and sticks work for routine tasks but hurt creative ones. What drives people is autonomy, mastery and purpose. Read it before you design incentives, goals or a team's way of working.

Empowered by Marty Cagan, Chris Jones (2020): How product companies turn teams of order-takers into teams that solve problems. It covers product leadership, vision, strategy and the coaching that holds them up. Read it if you lead product or engineering teams.

High Output Management by Andrew S. Grove (1995): A manager's output is the output of their team and the teams around them. Intel's former CEO shows how to run meetings, delegate, measure and coach with that idea. It is short, practical and dated only in its examples.

Release It! by Michael T. Nygard (2018): A catalogue of how production systems fail (cascading failures, slow responses, unbounded queues) and the patterns that stop them: timeouts, circuit breakers, bulkheads. Read it before your first on-call week, and again after.

Trade-offs

CSS 3D builds the shelf with CSS, the browser’s ordinary styling language. Each book is a box of flat panels (spine, covers, page edges), turned and stacked in 3D by the browser. Nothing in the scene knows about light, so shading and shadows are painted on with gradients. Learn more.

WebGL, the browser’s direct line to the graphics card, draws a real 3D scene onto a canvas, a blank drawing surface on the page. A window light (and a lamp in dark mode) lights the scene, books cast soft shadows on each other, and gravity decides how a book tips and settles. Learn more.

Aspect	CSS 3D	WebGL
What you see
Realism	Light and shadow painted on	Real light, soft shadows, truly rounded edges, gloss
Motion	Animated slides and turns	Books tip, lean and rock under gravity
Text	Real text, sharp and selectable	Spine and cover text drawn into images
What it costs
Download	~47 KB compressed	~152 KB compressed, only when you switch
Complexity	Everyday web skills: HTML, CSS, animation	3D graphics: camera, lights, shadows, physics
Fallback	Any modern browser	Needs WebGL, otherwise a plain list
Accessibility	Native page elements	Invisible buttons over the canvas give the same access

Reach for CSS 3D when a handful of objects need to move and stay light and accessible; reach for WebGL when real light, shadow and physics are the point and worth three times the download and more specialist code.

Under the hood

CSS 3D: each book is a box of flat faces that the browser keeps in one shared 3D space (transform-style: preserve-3d). Gradients fake the light, and the Motion library springs books in and out. About 1,100 lines of code.
WebGL: plain three.js, without a React wrapper, since the scene is drawn frame by frame outside React. Shadow maps (a depth picture taken from each light, used to work out what sits in shade) give soft shadows; an environment map (a picture of a surrounding room that shiny surfaces reflect) gives the covers their gloss; a small physics step tips and settles each book. Spine and cover lettering is drawn on a hidden canvas and wrapped onto the books as textures, like printing a label and gluing it on. A canvas is a single picture to a screen reader, so a real button sits over each book to keep keyboard and screen-reader access. Flight paths are planned so no two books ever overlap. About 1,700 lines of code, a quarter of it the cat.
Sizes count each build’s own code, gzipped; both also load React (~65 KB).