[anthomtb]

Are you reading programming books the same way you would read a fiction book? If so, stop doing that.

Programming or any technical learning is a hands on experience. Take notes and apply techniques, using pen-and-paper or the keyboard, as they are presented.

If you really have to just "read" a technical book, IME a less-is-more approach works best. 5-10 minutes at a time, not even a chapter at once. Maybe a few paragraphs if its something really information dense. Funny aside, I find my morning "business" is the perfect time to this sort of reading using the Kindle app on my phone.

[berkes]

I read about fifty books a year for a decade now. Only about four of them per year, are programming books. They are indeed to be read very differently. Here's how I read them, ymmv.

- never in bed. never as audiobook. But sitting. At a table or desk.

- no distractions. At most "focus music".

- read a chapter through. Then read it again and do all excercises (on a computer without wifi)

- make copious notes, highlight quotes, summarize. Most important for me is to write down why I made that note.

- a time (years sometimes) later, do it again. E.g. when having worked on the concepts from a book in real prod projects.

- at most an hour. I have ADHD and my mind often flies everywhere suddenly; time to give up and grab a beer or coffee.

Very few of these work as ebook (Kobo) for me. The formatting of code is poor and diagrams unreadable. Prefer paper or PDF (but read on a computer or tablet without network).

[wyclif]

That's all good advice. You should definitely not read programming books like normal books. But I'll extend it somewhat:

~ Yes, always do all the exercises. It's important how you do them. No copypasting. Enter all the code examples in your text editor of choice and run them if possible. Experiment liberally and don't be afraid of errors; instead, adjust the program in response to the errors. Create a directory and save all your files; don't just keep overwriting the same exercise. This is so you can go back and review if necessary.

~ If possible, always use the PDF formatted version of the book. EPUB and other formats too often don't look good and aren't formatted as the author(s) intended, and PDFs tend to be easier to follow because the page is formatted the same as the print version.

~ I use the Pomodoro technique of working intensely on the book for 25-30 minutes and then taking a short break before continuing. This tends to help me focus and retain more of the book.

Back when I was learning Python, I used two books in sequence, "Python Crash Course" by Matthes and "Think Python" by Downey. This turned out to be fortuitous, because until I started working through them I didn't know they are two completely different approaches: PCC teaches you how to program in Python and TP teaches you computer science using Python. Working through both books consecutively gave me a much better scope and understanding of the language to build on than using one book alone and stopping there.

[berkes]

That's some great advice.

When you say "don't overwrite", di you mean to start from scratch every chapter? I can imagine this would work for me: repetition is key. But also to get frustratingly boring after a few chapters.

I'll just treat is as any trunk based git repo. Commit significant progress, several times per hour. Then rebase to "summarize" my learnings into a history. I'll commit them to a public repo and treat as if that annoying colleague is going to review. Not that anyone will ever read them. I probably won't myself. But the art of rebasing, amending and pulling apart helps me with what would have been the perfect eLearning history.

[wyclif]

No, I just meant save every exercise as a file, like chpt1ex1.js, chpt1ex2.js, &c. A lot of consecutive exercises are just variations on the previous exercise, helping you build your knowledge, but that makes it tempting to overwrite the previous exercise or never save the file. Then you don't have anything to review with after working hard on the book.

[anthomtb]

I agree with all your bulleted points. Especially the "at most an hour". Maybe its age or outside responsibilities, but mental fatigue is a real thing for me, and spending more time than that on technically-challenging materially brings rapidly diminishing returns.

> Very few of these work as ebook (Kobo) for me. The formatting of code is poor and diagrams unreadable. Prefer paper or PDF (but read on a computer or tablet without network).

My ancient (2011) Kindle is borderline useless for technical material but the iPhone app renders diagrams and equations acceptably well (my experience, of course). The small form factor of the phone is helpful too - more desk or table space for notebooks. Mind you, I make heavy use of app limits and downtime so its not the distracting experience of typical smartphone use.

[chrisweekly]

I find my ReMarkable 2 e-ink tablet provides fantastic UX for technical PDFs. Zero distractions, handwritten (or typed!) annotations, etc.

[auggierose]

It's not large enough, in my opinion. For PDFs, personally I think that an iPad 12.9 inch is the best choice.

Adding this just in case someone is tempted to get a Remarkable for reading PDFs.

[walteweiss]

Thanks, I thought whether I want ReMarkable or iPad 12.9 for reading PDFs.

I had this the biggest iPad back in the days it was introduced, but gave it to a friend as it felt too big for me, and way too expensive for what I wanted from an iPad. (Basically just a YouTube streamer, and my long obsolete iPad 3 from 2012 still does the job, surprisingly.) I checked iPad Pro 12.9 and there are justifiable prices for used ones, so I think I’ll replace my iPad 3 with this big one, which will allow me to read PDFs more comfortably as well.

Btw, I tried printing some PDFs and I don’t like it that way. I know to each their own, someone likes the books printed, but I’m the opposite of that. So much that I had donated all the physical library of my dad’s books I had in the house after his passing out, as I realized I would never read them in paper.

[rapind]

> do all excercises (on a computer without wifi)

And make sure you are typing the code, and not just copy pasta. Writing it out helps most people process it.

[berkes]

yes! Very much.

And turn off copilot. The code from the book is very likely in its training set. It will produce it almost verbatim. And you learn nothing.

[skydhash]

I don’t mind distractions when learning via books (I wouldn’t be able to finish my degree otherwise), but the other advices still apply. Reading a chapter without doing the exercices is like listening to a lecture without taking notes. You may understand a few things (or everything), but you’ll find that doing practice, drawing diagrams, or summarizing it lead to a deeper understanding. More often than not, you have to dedicate a few days or weeks depending on how dense it is. You find yourself rereading a page from a previous chapter or consulting another book. You don’t have to read it end to end unless you view it as taking a course.

[berkes]

As mentioned, I have ADHD. Which means I cannot handle distractions. So I try to uses processes and tools to manage distractions as much as possible for me.

But I guess a neurotypical zoomer can code fine with a TV in the background, a podcast in one ear, insta and DMs ploinging into their notifications and slack nagging in the status bar. I cannot.

[walteweiss]

Do you keep some notes on the books you read? (I mean online notes here; but if you don’t keep them online, while maintaining the notes, the question is still valid. Maybe you have some system that works for you and you want to share.)

[berkes]

I use Joplin. And that has no way to share a part of my notes. And I'm really not ready to share my woes with my wife with the world. These are all mixed with my Kobo notes.

Also. Notes have always been a mess. I note a lot with pen and paper. Most even. I have piles of random paper. Pen drives with markdown. And large gaps.

If anything, adhd is terrible for consistency in this kind of stuff. Which is why I go full on plain text formats. Any binary, SQLite, cloud whatevs will rot within weeks after me loosing interst. Yet my diary.md and my bookkeeping.ledger, albeit gapped with years, still goes strong.

[vadman]

> Most important for me is to write down why I made that note.

My ears perked at this. Great advice!

[kabes]

I, for one, was a really bad student, until I discovered learning in bed. A desk is still to distracting for me.

In bed, phone out of reach and reading one hour, sleeping half an hour was super efficient for me. You only process material while sleeping anyway.

[ornornor]

> I find my morning "business" is the perfect time to this sort of reading using the Kindle app on my phone.

Beware of hemorrhoids later in life if you’re spending too much time sitting on the throne.

[noufalibrahim]

Yup. The key to learning is doing. You need exercises at the end of every chapter if you want to learn. Math books, programming books etc. And they need to be challenging. That's what helps retention and understanding.