Programming books are generally technical documentation, or close enough - of course they're boring to read. There's so much detail to programming you could spend the rest of your life reading documentation and feel like you barely scratched the surface.

The article suggests identifying the reason you want to read it. In your case, you should identify what kind of problem you're trying to solve (even if not in an actual project and just in your head, something like "how DOES a cloud server work?") and then get that specific knowledge out of the book, as deep as you want to go.

Programming books can be expensive though, so you should generally google overviews of what you're looking for before committing to a whole book.

If you're having to read the thing for work, I guess identify what the problem at work/school you're trying to solve (or what project you'd be applying it to) and regularly relate back what you're reading to what you would do with it practically.

Funny. I was listening to the back catalog of Django Talk podcast. The hosts are well informed and yet one commented to the same effect that programming books are difficult.

I’ve heard researchers speak about how they read papers—read the abstract and jump to the conclusion.

For my part when I read a non-fiction book that doesn’t capture my attention (and excitement) with the first pages, I jump to the index and scan for keywords which are of interest. Then I read those chapters first. This can sometimes jumpstart my interest in the author’s other chapters and their perspective.

I work programming books similarly. I know I have to work through some of the examples while I read. If the book is not specific to a particular language, say an algorithm book, I have tried to rewrite in my language of choice.

If all of this sounds very slow and non-linear…well, maybe it is and should be. Many books take months to write or years. I don’t expect to read them as quickly or to enjoy then the same as the Murderbot Diaries.

I can whole-heartedly recommend "The Ray Tracer Challenge" by Jamis Buck. It's a fun project-based book without all the computer graphics theory, where you focus on building a ray tracer in small increments while Jamis holds your hand until you can walk on your own. As a small bonus, you get to generate some awesome images pretty quickly.

I usually consider programming books as a reference and don't "read" them. My way of getting value out of these books is remembering the high-level contents and diving deeper when there is the need (e.g, a coding problem that I need to take care of)

the thing is literature, philosophy, history are trying to tell you something about reality - most programming books are trying to tell you something not much different from a washing machine instruction manual, the machine is just much more complicated.

Have you tried reading the more classical computer science books like Structure And Interpretation Of Computer Programs, I find I can handle getting through those (because at that level they are also trying to say something interesting about reality) but Web Developer Pro or Expert React Design Patterns (presumed fictitious titles that still sound pretty plausible) would probably bore me and make me put the instruction manual aside in favor of some experimentation.

An ACM membership ($99/year, discounted to $75 for the first year) gets you access to ~40,000 books via O’Reilly.

It’s a very good option if you think you might want to dip your toes into a variety of programming books, and don’t want to commit to buying individual ones.

Same here. Novels are easy for me, but technical books not nearly so much.