How I read technical books and documentation

Post contents

By technical books and documentation, I mean any sort of nonfiction longform content—detailed blogs, books, or courses. I'll refer mostly to books, but these same concepts apply

Since I have a reading list on my blog, I often get asked "how do you read so much?" or "why read books when I can do tutorials and researching as I go?"

To put it briefly, consuming longform content provides a mental model that shortform content cannot, scope what you want to read, adjust when things don't go to plan, set aside time to read, and finally do it

Why read?

Software engineering is a career all about reading

You can only get so far without learning from others' mistakes. One person can only write so much software, compared to decades of industry research. We really are standing on the shoulders of giants

Beyond documentation, reading code is far more common than writing it, especially so for those that work on teams or use LLMs like ChatGPT to generate code. If you don't like reading, you picked the wrong industry!

But I can Google/ask ChatGPT as I go!

There's a time and a place for everything. Only researching as you go is limiting. Diving deep into a topic builds a mental model and fills in gaps. You may get a good introduction from short term content, and you certainly can fill in those gaps through reading and writing code, but one deep resource makes sure you're not missing anything obvious

How can you know the answers you get online, from blogs, or from LLM responses are relevant to you? How do you know they are up to date and make sense for your use case? That's right! Put on your nerd glasses¹, we are going to read the manual!

What to Read

Know your tools

You should read the manual for tools you use frequently. Knowing what features are available pays dividends in the future

You should go out of your way to learn about tech you'dn't've encountered naturally. This will expose you to new tools and change the way you think. This is a riskier investment, but staying in your comfort zone holds you back. Exercising your learning muscles and learning you don't like something is always valuable!

However, I don't think you should read the whole manual before writing a line of code. We have limited time and energy after all

Know your limits

I know I'll get tired of reading a book in a month or so, so I won't even chance it. If you haven't read through documentation or a technical book in a while, you have to build up to it! Reading is a skill. Maybe someone out there can read through and understand a dense book like Designing Data Intensive Applications (DDIA) in a week, but that's certainly not me

Embrace partial understanding. I read DDIA in a month, and I don't understand it all, and that's ok! I know a lot more than I knew going in, so that's a win for me. I also read the first half of UNIX and Linux System Administration Handbook, which is 1340 pages. Such a large book would be impossible to get through without a plan

Go in with a plan

If you read a technical book like a novel, you won't get far

Before I read the Unix and Linux SysAdmin Handbook, I was familiar with concepts like observability and the cloud, so I knew I could go through those sections pretty quickly. I asked a friend knowledgeable on the subject and found a good ordering and sections to skip, like printer drivers. Even then, I decided to read only the first half to keep things manageable. I only wanted to spend 8–10 hours per week learning

This can be generalized to the following:

1. Decide how many hours per week you want to read
2. Read the author's recommendations on how to read the book and who it's for
3. Skim over the table of contents, headings, and chapters
4. Find what interests you or what scares you and decide on an order. If you are unfamiliar with the topic, ask a friend
5. Read some of the book to get an idea of how long a section will take. Keep in mind the first part is usually quicker than the last
6. Figure out how much time you'll need to spend to hit your goal
7. Read

How to Read

Adapt

Plans never go to plan. Sometimes you read a thing with your eyes and not your brain and have to reread. Sometimes you'll spend too long on a certain section and need to read the next part in less depth

I personally like to spend 15 minutes reading, then see if I've read fast enough, and adjust from there

If you don't finish in your planned timeline, figure out why. Was the book too long? Did you not read enough? Was the book not interesting? Did life happen? No matter what the reason is, it's perfectly fine to set the book down and go on to the next. A stack of unfinished books takes a toll on you eventually. For this reason, I maintain a reading list to keep me accountable to stop reading on

Don't memorize

In my particular case, I am not reading for school or a test. I want to improve my craft and change my mindset. Even if you are studying for a test, I think it's pretty obvious the knowledge doesn't stick when you cram

Recently I started reading Writing For Developers. My goal is to think more about writing and pick up a few tips along the way

Write down what you find interesting and questions to ask later. Don't get too bogged down in writing everything down—you can always come back! I find if I don't end up using something enough to remember it, it probably isn't super relevant to me

I get a lot of value out of recalling what I read afterwards or applying the concepts in the real world. For example, I am learning about concurrency via translating a Rust tutorial to Go

When to read?

If I don't have a time and place to read, I'll probably forget or be too tired to get started. Getting started is the hardest part! Some books are great to read on a walk or a commute to work. Others have code or are more involved and require sitting down to read or do exercises. I like to take 30 minutes at the start of the workday to read. If I push it off, I'll end up skipping out

If you find reading with a friend to be helpful, start a low stakes book club. Even if you're the only one reading, it's good spaced repetition to talk about what you learned

After you finish reading for the day, take some time to let it simmer. Let your brain soak it in. Go on a walk and think

Do it

Now, go read a book! You made it to the end of the article, now do it