How I Read Technical Books

I often get asked how do I read so many books? Do I read them cover to cover? How do I deal with overwhelming difficulty? How do I persevere if a book is boring? etc..

I read lots of books because it’s the most efficient way for me to understand all the open problems in a given technical field. This gives me a window into where I could contribute.

My past experience was in Machine Learning and Product Development but I felt like Robotics would soon hit an inflection point where building useful robots at home would become easy.

I had to self teach myself all I could in Robotics and Game Dev and design a useful product before my savings ran out. I needed to move fast but also couldn’t afford to gloss over the details.

As a self learner I can choose my peers online. Unfortunately, this means I’m overwhelmed by choice — especially when each new reference I come across is a dense 500+ page monstrosity written entirely in Greek.

Because I’ve read a lot a books, I’ve gotten better at reading lots of books. I thought I’d share so that you don’t waste more time than I did.

All the techniques I talk about below were ones that I had to learn by necessity — they may be obvious to long time researchers but they certainly weren’t obvious to me when I started.

The main trick was weirdly enough, introspection.

How I Read Technical Books

1. Don’t keep reading a boring book — if you take 1 thing from this entire post let it be this. The idea of “completing” a book only applies to novels or textbooks for a class. You never really finish understanding a subject and if it’s also boring you’re unlikely to be good at it. Boredom and procrastination are information not a quest that needs to be conquered so try to keep yourself honest about whether you actually want to read a certain book. Related: I don’t read 500+ books because it’s more likely I’ll find multiple 200 pages ones that are far more pleasant to read.
2. Buy lots of books — it’s hard to know beforehand which books will be a joy vs slog to read. The most reliable technique to solve this problem is to buy tons of books. While the cost may pile up $30–50 per book I always felt that good ideas are worth a lot more. I think of books as the best possible investment in myself. It’s also very rare for a single author to have all the best explanations for all the important algorithms and theorems in a field so it’s better to embrace this and actively seek out the best explanations instead of just assuming that the first reference you bought is the best one.
3. Take lots of notes in the book — ink is a lot less valuable than ideas so I stopped treating books like collectibles and treat them as consumables. The more beat up a book looks, the more love it’s gotten by its owner.
4. Ask smart people for book recommendations — the best books on a topic are rarely just a book on the topic instead they give you a new way of seeing the world. So if someone I admire recommends a certain book, I buy it regardless of the subject. Twitter, Github, Reddit and Hacker News have it made it really easy to find the smartest people in the world working on any topic. Related: you should spend as much time researching for good books as you do reading books.
5. Read and highlight your interests in the table of contents — the table of contents generally makes it clear what is background material (usually in the appendix). I make a note next to each chapter that looks fascinating to “me” and just read those.
6. DO NOT READ BOOKS COVER TO COVER,— My favorite technical books are the ones I come back to the most often. I first do a quick scan of the chapters I’m interested in and make a list of open questions or concepts I don’t understand. Then read the chapter again and try to answer those questions and make a new list of questions.
7. Skip the middle pages of a chapter on a first read — the beginning of a chapter often motivates and defines the problem and the end summarizes it. That’s usually all I need if I’m treating a techniques as a black box. I do this first, it takes a few minutes only and then read the middle part if I’m really compelled to do so.
8. The first 3 chapters often contain 80% of the total information — It’s very rare for long books to be building on a single idea. What’s more common is that the first few chapters introduce the basic terminology and the basic formulation of the problems you’re working on and then the rest of the chapters branch out from this base. Exception to above rule: it’s OK to read the intro chapters cover to cover.
9. Build a glossary — each field has its own basic terminology and basic results. Just knowing what those words are may not make you an expert in the subject but it’ll make it possible for you to go through more complicated work if it’s interesting to you. It’s very common for some words not be well defined in some books in which case just find alternate references on Google and YouTube and write down inside the book cover what those words mean.
10. Prerequisites are often overestimated — many books will say something like “prerequisites are linear algebra and calculus” but what they really mean is you should look 3 theorems online before you start. Tackling prerequisites partially is totally valid.
11. Write notes — this can be as simple as a bullet list of things you thought were cool or it could be a long blog article. I usually reread great chapters about 3 times so it takes me about 3 iterations to get to a blog post I’m comfortable sharing.
12. Avoid the Hivemind — if you’re an independent researcher odds are you’re on a tight budget so you need to be smart about how you allocate your time, don’t try to be the best in the world at 1 specific topic and compete with the top research labs in the world all by yourself. You’ll get diminishing returns after investing too much in a single field so you’ll probably be a lot happier browsing techniques from various fringe fields instead of the 1 over-hyped one.
13. Github Archeology — whether a book is talking about simulating some model or describing some algorithm it’s almost impossible to understand how they really work by visual inspection alone. Google “<name_of_concept> Github” and you’ll often find top notch implementations of any technical problem you can think of. The best code-bases are interactive books so a lot of the advice from above also applies.
14. It gets easier — different fields will often use the same mathematical techniques, ideas and code. Because ideas cross pollinate you’ll find it easier over time to read technical books regardless of the subject matter. Before you start seeing some connections between fields you’ll find yourself questioning the point of what you’re reading so it’s important to have some faith that some connections do exist because more often than not, they do.

What about Non Technical Books?

Novels: I don’t read novels, I prefer video games, comics and movies. I get antsy whenever I read a novel so have stopped forcing myself to enjoy them

Self-help books: I stopped reading these about 2 years ago. I Google the summary online since for the most part they’re a 2 page blog post which is stretched to fit the standard 250–300 page format