
When you can actually see the changes to things and have a real interesting project to work on its way more engaging that just going over the theory of things. Obviously, one should follow up with actually learning the theory as well to get a deeper understanding, but I often just can't grok things unless I can play with them.
A previous HN discussion on that book:
https://news.ycombinator.com/item?id=15624521
EDIT: That earlier discussion has an excellent first post. Quoting:
"It bothers me so much that very few books (Kernighan) talk about WHY. WHY. WHY is a variable needed? WHY is a function needed? WHY do we use OOP? Every single book out there jumps straight into explaining objects, how to create them, constructors, blah blah blah. No one fricking talks about what's the point of all this?
Teaching syntax is like muscle memory for learning Guitar. It is trivial and simply takes time. Syntax - everyone can learn and it is only one part of learning how to code. Concepts are explained on their own without building upon it.
[... A list with learning resources the poster finds great ...]
This is learning how to produce music. Not learning the F chord. Teaching how to code is fundamentally broken and very few books/courses do it well."
building a working C compiler from scratch is literally in my "teach yourself C in 24 hours" book from 30 years ago
But yeah, the big thing here is that the substance of my critique is on a different thread. It's disfavored to retype things you can just link to. I'd be irritated with me too if I just said "CATB is bad!" and left it at that.
My first exposure to programming was Sam's Teach Yourself C++ In 24 Hours from a used bookstore in my early teens. I didn't stick with it for more than a couple chapters but compiling a program that printed "Hello world" was a magical experience.