[eanplatter]

Maybe I'm in a minority, but I've never read a programming book that didn't have me writing and testing out code in my console while I read.

Also, the kinds of things I tried out on my own while reading were unique and new. Not the kind of things I would necessarily run into in my job.

Doing is one thing, but if I just keep doing with my current knowledge then it's easy to fall into a situation where improvement is minuscule.

[nostrademons]

Exercises are very different from projects. When you support a project over the long-term, you engage a very different set of skills than what you'll get in a book. You learn how to push your way through a seemingly unsolvable bug that nobody has encountered before, often one in code that you didn't write. You learn how to make technical choices that reduce the likelihood of encountering these bugs. You learn how to come back to your program in a few months and pick up where you left off, and what sorts of coding practices will inhibit this. You learn what sorts of bugs occur in practice, and how to avoid them. You learn how to diagnose performance problems, how to speed them up, when to speed them up, and you build up a mental model of how the systems you work with behave. You learn how to limit complexity, and what the complexity budget of your brain is, and how to break up projects so that you stay within that budget. You learn how to communicate with other programmers, and what they care about. You learn how to build up a codebase incrementally, how software evolves, and how the why of the code usually matters more than the how. You learn how to communicate with users, and how to accept their input, and how to weigh the costs of their feature requests against the complexity of the code base.

All of these are emergent problems that only occur when you work with large, long-lived software systems. You won't get them out of a book.