Week 2 #100DaysOfCode: Tips on Reading Programming Books
Week 2 is done. I'm still going.
The biggest lesson this week wasn't technical — it was about how to read. Most programmers learn from videos and tutorials, and there's nothing wrong with that. But when you start following a curriculum that requires actual books, you hit a wall quickly. Books are slower. Books don't check your work. Books expect you to sit with confusion.
I spent a lot of this week in Kyle Simpson's You Don't Know JS: Scope & Closures, and I also worked through Shay Howe's "Learn to Code HTML & CSS" course, building a conference website project as I went.
The project helped. Having something to build made the reading feel purposeful.
Six things I've learned about reading programming books
1. Read deliberately, not fast. Speed doesn't matter. Understanding does. If you finish a chapter in 20 minutes and can't explain what you just read, you haven't actually read it. Slow down. Read sentences twice if you need to.
2. Use multiple resources. The book is not the only source. When a concept isn't landing, I open YouTube, search for blog posts, look for a different explanation. Good programmers know how to triangulate — they don't depend on one source to understand one concept.
3. Write down what you learn. Not in the book's language. In your own words. If you can't explain it simply, you don't understand it yet. I keep notes — messy, short, in plain language — and they've helped more than highlights ever did.
4. Accept that you won't understand everything the first time. This one took me a while. When I hit a concept that didn't click, my instinct was to stay there until it did. That's wrong. Sometimes you need more context that comes later. Mark it, move forward, come back. Understanding usually arrives in layers, not all at once.
5. Break it into daily chunks. Ten pages a day beats 70 pages on a Sunday. Consistency compounds. The Pomodoro technique helps here — 25 minutes of focused reading, then a break. It's not glamorous, but it works.
6. Code the examples. Don't read about closures. Write a closure. Don't read about specificity. Change a CSS rule and watch what breaks. The moment you type the code yourself, even copying it from the page, something shifts. Your hands remember what your eyes missed.
What I built
The conference website from Shay Howe's course. It's not impressive — it's a static HTML/CSS page. But building it while reading about CSS selectors and the box model made the book make sense. The reading and the building reinforce each other.
Where I'm at
JavaScript fundamentals are starting to feel less like memorization and more like understanding. I can see the shape of how scope works now. Closures still feel a little magical, but I know what they are. That's progress.
The public accountability works. Knowing I'll post this makes me code on days when I don't want to. That's the whole point.
Week 3 starts tomorrow.