· Jonathan Cutrer · Life · 4 min read
On Reading Technical Books Slowly
I used to skim. Now I read 10 pages a day and take notes that actually change how I write code.
For most of my career I treated technical books the way I treated documentation: something to search through when I had a specific question, not something to read cover to cover. I’d buy a book on systems design or database internals, read the first three chapters, understand roughly what it was about, and then shelve it.
I’m not sure when this changed. Somewhere around 2023 I started actually finishing technical books, and the difference has been real enough that I want to write it down.
The Problem With Skimming
Skimming works for reference material. It doesn’t work for anything where the point is building a mental model from the ground up.
The reason I skimmed was efficiency: reading every page of a 400-page book on database design felt like overkill when I just needed to understand B-tree indexes right now. But the mental model you build from a targeted search is local and shallow. You understand B-tree indexes in the context of the specific question you were trying to answer. You don’t understand how they relate to write amplification, or why that matters for LSM trees, or how that connects to the trade-offs in the storage engine you’re using.
That connective tissue is what slow reading builds.
What Slow Actually Means
Ten pages a day. That’s it. I read ten pages, I write two or three sentences about what I understood, and I stop.
Ten pages a day through a 400-page book is 40 days. Two months, roughly, if I miss some days. That sounds slow. But I’ve finished more books in the past two years than in the previous five, because “ten pages” is achievable on any day, including the ones where I’m tired and my attention is bad.
The alternative — reading 50 pages when I have time and motivation, then not touching it for two weeks — resulted in forgetting the first 50 pages before the second 50 happened.
The Note-Taking Part
I use a plain text file for notes while I read, kept next to the book (or in the Kindle app notes for ebooks). Not comprehensive summaries — just the things that surprised me, or the places where I disagreed with the author, or the ideas I want to think about further.
After finishing, I look back at the notes. Usually there are four or five ideas that appear repeatedly in different forms — those are the things the book actually taught me. The rest was context.
This is different from highlighting. Highlighted passages are passive. Writing a sentence about why something is interesting forces a minimum of active engagement that highlighting doesn’t.
The Books That Changed Something
Designing Data-Intensive Applications (Kleppmann) — the one I wish I’d read five years earlier. Changed how I think about replication, consistency guarantees, and what “distributed system” actually means in practice. I read it slowly and took 40 pages of notes and referred back to specific sections four times in the year after reading it.
A Philosophy of Software Design (Ousterhout) — short, opinionated, worth reading twice. The section on “deep modules” reframed something I’d been thinking about poorly for years.
The Pragmatic Programmer — I read this too fast the first time in my early career and got surface-level lessons from it. Read it again slowly ten years later and it was a different book.
What I Skip
Books where the central insight could have been a blog post. There are a lot of these. The signal is usually visible in the table of contents — twelve chapters on twelve variations of the same idea is a book that should have been an essay.
I’ve started abandoning books at the 20% mark without guilt if I’m not getting something I couldn’t get faster from a targeted search. Slow reading doesn’t mean finishing everything you start — it means giving the books that deserve it the attention they need.
The Uncomfortable Part
Reading slowly enough to actually absorb technical material means accepting that you’ll cover less ground than someone who skims aggressively. There’s a period early in this habit where it feels like falling behind.
I’ve found that the depth gained on a smaller number of topics is more useful than surface coverage of a larger number, at least in how I actually work. The question isn’t how many books I’ve “read” — it’s how often something I read actually shows up in a decision I make. Slow reading increases that rate considerably.
