the scapegoat dev

When is a book considered "read?"

stylized phantasmagoric psychedelic library, retro mainframe books, retro mainframe exposed electronics library, horror manga library with creepy books, black and white pen and ink drawing in the style of moebius, line drawing, trending on art station, highly detailed brush pen ink drawing, monochrome black and white, 4k

I love books. I think books are maybe the most significant thing human civilization has created. If thoughts can be put into language, then books are what allows thoughts to be sent across time, across minds, across cultures, across the world. People who write books will often be remembered way past their lifetimes, and influence and communicate with people FROM THE FUTURE.

I buy so many non-fiction books that I often get questioning, if not outright critical, looks from my partner. I recently acquired a binding machine which only exacerbated the pattern. It is simply impossible for a human being to go through 3 dense technical books per week, if not per year. These books usually stay on my desk for a day or two (I'm one of those "thinking with piles" people that Temple Grandin talks about in her latest book "Visual thinkers" ) and then disappear in some random assortment on my book shelf.

So, did I read these books? Why do I buy them? Is it just pure consumerism? What does "reading" a non-fiction book even mean?

Ultimately, the exact definition of "read" does not matter, except if you really care about checking that checkbox on Goodreads. For me, it is much more about understanding the different ways you can get value out of a book. Reading is not something innate. It is a skill to be practiced, studied, discussed, shared, and taught.

Fiction books are, I think, quite a different category. Here "read" also means having given the author's vision the attention and respect it deserves; meaning, having absorbed the book in the way the author intended, usually reading it from beginning to end. The boundary is of course blurry. There is no reason you wouldn't consider non-fiction books just as much an artistic expressionasn fiction or poetry, nor is there any rule in which you should approach a novel—read it backwards or skip every second sentence if that makes you happy.

My many definitions of "read"

Here is an (incomplete) list of what I would consider "reading" a non-fiction book.

Study it from end to end

This is the most time-consuming way of reading a book. I might have done that for less than 10 books in total. It's working through Structure and Interpretation of Computer Programs, it's working through a reasonable amount of exercises from a Knuth volume. It is not just reading and typing some code into an IDE. It is challenging work. It changes your brain through repeated intellectual effort.

  • While many books are worth this effort, I think you should pick the ones you devote this amount of time to carefully. Think of it as choosing which major you are planning to study.
  • Working through a book doesn't mean that the domain needs to be technical (or mathematical). I worked through drawing books in the same fashion.

Setting out to study a book end to end, and jumping off the bandwagon

Because studying a book end to end is so extraordinarily time-consuming, there is no shame in jumping off the bandwagon. You might have only worked through the first two chapters. If the work you put in was genuine, if you feel you grew, if you had to struggle and find things within yourself you didn't know existed, then you got more out of reading those two chapters than forcing yourself to finish it, rushing through exercises or skimming chapters fooling yourself into thinking you absorbed their content.

Some books are meant to be read multiple times

Some books are so dense, so packed with insight and meaning, that they can only be absorbed in small steps, over long periods of time. Some books are so layered and multidimensional that reading them a second time, a third time, a fourth time is like reading a brand-new book.

They are books that never make you feel like you "read" them, because you are aware of how much you missed. I find books like these to not just be "theories of everything" books, written from the perspective of someone that has been a scholar, a pursuer of truth for their entire careers (for example, books by Christopher Alexander, books by Gerald Weinberg)—they can also be books from different disciplines who will appear to cast new lights on each repeated reading. I personally enjoy art books , specifically about teaching and learning, or even a book about trail design.

I am fine with reading just one or two chapters of such a book, knowing that it is a "keeper", and that I will come back to it in due time. It gave me the wisdom I was open to absorbing in that moment, and I recognized its value.

Deliberately study a single chapter

A lot of books contain one valuable idea and a lot of fluff around it. In fact, many books are written in a way that (deliberately) obscures that idea (it is often called "building a narrative"). Besides obvious pop-sci books (whose main idea is often extremely questionable), you can get a feel for these books (some of them are called "the art of XXX" and are written by experts at the end of their career). Or they are management books touted as life-changing by many).

  • I find that often, studying the introduction and the first chapter, pen in hand, writing an essay about it, really challenging and absorbing that content, is worth more than reading the thing end to end.
  • After carefully reading the introduction, I skim the different chapters, realize I already know the main point they are making, and move on.

Reading with a pen in hand

This is more of a technique than a definition of "read", but something that significantly enhances the value I get from books. I read and write in the margins. I don't highlight, I literally write down any thought that pops into my head, valuable or not. I am conducting a dialogue with the author. I will ask "why do you say that?" even if the next chapter explains why the author said that. I will comment if I agree or disagree with a certain idea. I will write down what other things a passage reminds me of. I will also write down tangential thoughts that seem at first completely related to the content at hand.

If you think that this ruins a book, compare the enhanced value, the fun you get out of scribbling into a book to make it yours. This is compared with the value of buying a second copy if you want to start afresh. Think about the value for future readers, who might actually read the book more because they want to see what you wrote than what the original author wrote. Consider what would have happened if Fermat hadn't written in his books. Consider how you might enjoy reading the notes your parents left in their books, your grandparents, your ancestors from the 17th century.

Deconstructing a book

In fields like software engineering, many books approach the same fundamental idea in different ways (for example, decomposing monoliths into microservices, refactoring, unit testing, technical leadership). It is often the case that I carefully read one of them. This allows me to quickly skim the other ones, trying to find where the similarities and differences lie. Are the differences only surface-level differences? Is one written in F# and the other in C++? Are they as modern as this brand-new Elixir book, though soaked in 90ies Java OO astronaut architecture? Which one is better? Are both worth it?

While I have technically only read and studied one of them, I will often call the other one "read", because I know the point it is trying to make and how it is making it. This allows me to grab or recommend either one when the situation arises. With the continuously increasing quality of technical writing and the speedy and tightly integrated exchange of ideas due to social media, this situation routinely arises in the current day. Many quality books cover the same material, and will resonate differently with different people.

Scanning the table of contents and index

This is similar to the previous point, except that it is faster. I will be familiar enough with a topic to be able to understand most of its aspects. It is however a topic that I am only cursorily interested in, or perhaps a book that got recommended to me. Indulging in consumerist, ADHD impulses, I will buy the book because (this is the "piler" vs "filer" thing mentioned above) I want to have it on my shelf, ready to be opened the second I need it. The value of a library is not having read its books, but being bathed in its aura, and having plenty of material ready at hand when inspiration (or boredom) strikes.

The best value I can get out of the book at that moment is to actually not read it, because my mind is better focused on something else. However, I need to know what the book contains, and make either a mental, or (better!) a written note in my Obsidian vault, of the things I will find in it.

A technique I am trying to refine here, inspired by my Zettelkasten practice, is to write an alternative table of contents and index while skimming the book. What is important is not what the book contains per se, it is how I know I will use it in the future.

A recent example that comes to mind is Brendan Gregg's BPF Performance Tools book. I am currently not doing any work that would require me to use eBPF. Therefore, studying eBPF on the weekends would just lead to forgetting everything after two weeks for lack of practice. As such, reading the book is actually counterproductive. However, I read through the table of contents, made a note of the different concepts it is tackling (memory management, scheduling, filesystem and IO performance) and crosslinked those to the relevant notes in my vault (either in my Wiki, or in my Zettelkasten). The next time I look up IO performance in my vault, I will find a precise list of the scripts found

Skim with another topic in mind

However, I am learning to take this a bit further. EBPF has a pretty interesting design in itself, composed of its own VM, a long history stretching back to BSD's firewall rules, tooling allowing for embedding / live-synthesis of eBPF code. This reaches way beyond just filing eBPF away as a performance tool, and might be much more closely related to my current interests (in this case, VM design). I thus wrote a "parallel" index for the eBPF book informed by skimming it with VM design in mind. While not having read a single chapter of the book, I probably got way more value out of it than say, reading through Malcolm Gladwell's platitudes.


I probably read less than 10% of the pages of all the books on my bookshelf. Yet I feel confident I have read about 90% of the books on there.

What is your definition of "read?"

- 18 toasts