The programming book market these days is small. Nothing like what it was eight years ago or so. And apparently, programmers don’t read books (any more).
It’s mostly true. But of course, there are still books worth reading. I’m going to take as read the easy arguments: let’s assume that you’ve already pared away all the “learn such-and-such in 24 hours”, anything with “for dummies” or “for teens” or equivalent in the title, and any book that weighs more than your head.
What you are left with is two kinds of books: timeless or beautiful texts that everyone agrees will still be worth reading in 20 years (and in many cases, already have passed this test), and the tougher category to decide on: the middling sort of books, probably specific to certain technologies and/or languages. In many cases they may be very good books, may even have been defining texts on first release, but either technology has moved on, or there is so much great information out there on the web that it makes spending $50+ on a book a proposition to think about.
The answer is: you should absolutely use all the information on the web, pulling it in as you “page fault”, and googling solutions as you go, in a practical way. AND you should absolutely read these books.
Reading and doing are not mutually exclusive ways of learning. They are complementary. And reading is more useful than many pragmatist programmers realise. Sure, you’re not going to learn practical things like debugging or how to wrangle libraries and packages just by reading. But you’re not going to get much wider context just by doing, either.
One of the first programming (culture) books I bought was the New Hacker’s Dictionary. It says this about reading:
Although high general intelligence is common among hackers, it is not the sine qua non one might expect. Another trait is probably even more important: the ability to mentally absorb, retain, and reference large amounts of ‘meaningless’ detail, trusting to later experience to give it context and meaning. A person of merely average analytical intelligence who has this trait can become an effective hacker, but a creative genius who lacks it will swiftly find himself outdistanced by people who routinely upload the contents of thick reference manuals into their brains.
The crucial part here is that reading gives a wider context to doing. This is why programmers should read, and reading and retaining (or at least being able, on second encounter, to remember and put in context) technical information is an important skill to have.
So read those books. Read code and blogs too. It may sound daunting (“How can I possibly remember everything?”) but the more you read and remember, the easier it will get, because brains are great at putting things in context and linking to things that they already know. And then when you get to doing, you’ll see the bigger picture, and perhaps you’ll also remember about a looming pitfall you read about, but which the hastily-constructed web tutorial you’re currently perusing glosses over.
I disagree with: …Sure, you’re not going to learn practical things like debugging…
When I pitched my book Debugging to the publisher, I pitched it as one of those timeless books that will still be valuable in 20 years. (I didn’t call it beautiful — I used words like valuable and fun to read.) It was published in 2002 and still sells well, and is a textbook for several college-level programming courses.
The key to avoiding the obsolescence factor is to make it universal enough to be useful in spite of technology advances. So I extracted the essence of what good debuggers do, and applied these rules to all kinds of debugging situations, including software, hardware, plumbing, cars, and human bodies.
On my URL debuggingrules.com, I have reviews, a pointer to Amazon if you want to buy it (only $16, not $50), and a fun poster to put up on your wall to remind you when the going gets tough.