How to zoom through a dense book on coding?

People often mistake covering material for learning. You can zoom through material at any speed you like, but learning is building something in your head.

How fast you can build things in your head relates to what you've already built, what and how much you want to build onto it, inherent difficulty of each specific thing you want to build (easier to paint a large wall than build a small cabinet), your energy level, and some amount of natural talent.

As in any building project, you'll probably have more energy if you do it a bit at a time and either rest or alternate tasks. You might find it better to alternate reading the book and writing code. You might go more slowly through the book but still build the knowledge in your head faster, and the latter is the real job. You might also do better with an easier book. Again, it's how fast and well you build things in your head, not get through a book, that matters.

I suggest treat each chapter as its own book.

Then if you get through one chapter, consider that a success. Decide if you need the next chapter.

Some academic books have a dependency graph that helps you decide what chapters you can skip.

There is no need to finish a book. A book is just 20 or so decent size blog posts!

Use the book to prop up your monitor so that it’s at eye level. If it’s making you lose motivation then you’re not ready to read it. I only read a computer book once I have ported a few bits of code in a familiar language to this language and read a bunch of code that other people have written. If I am still interested in the language at that point then chances are I’ll be interested in all the dark corners a book will introduce me to. Then it doesn’t feel like a chore to read the computer book.

Reading a dense computer book as an introduction to a language is quite low effort which is why it’s popular imo. They are extremely detailed so you think that’s all you’ll need. It’s extremely low effort to buy the book and then it’s pretty low effort to casually leaf through it, thinking that you’re actually learning something when you probably aren’t.

This works for me, but might not work for you.

I can't pick up and learn an entire how-to book. But I can use a how-to book to help me complete a project. Once the project is done, and I have an incomplete mental schema for how the new language/platform/framework/tool works, I'm ready to read the book.

At this point I can quickly sail through it, skipping the parts I already learned during the project, and then diving deep on the parts I didn't. The key is using the hands-on project as a reason to build up a filing system in your head. Then as you're reading, you know where -- and whether -- to file all the new information.

Everyone has their own learning style. I found that coding books are quite boring for me too, but working on a practical project can be enjoyable and educational at the same time as you learn things along the way as a part of the journey.

When encountering a seemingly difficult book, I ask myself two questions - is it the right book in the sequence of what I am striving to learn and do I have enough background knowledge to understand it.

When watching lectures on YouTube on software engineering, I note which books those presenters recommend. I also read works they previously wrote because the presentation tends to be an overview of their books.

The book may be essential reading, but it likely assumes prerequisite knowledge if it seems difficult.

For example, Strunk and White is an essential book for writing better in English. I had to read additional books to understand the assumed concepts.