Programmers Don't Read Books -- But You Should

One of the central themes of stackoverflow.com is that software developers no longer learn programming from books, as Joel mentioned:

Programmers seem to have stopped reading books. The market for books on programming topics is miniscule compared to the number of working programmers.

Joel expressed similar sentiments in 2004's The Shlemiel Way of Software:

But the majority of people still don't read. Or write. The majority of developers don't read books about software development, they don't read Web sites about software development, they don't even read Slashdot.

If programmers don't learn from books today, how do they learn to program? They do it the old-fashioned way: by rolling up their sleeves and writing code – while harnessing the collective wisdom of the internet in a second window. The internet has rendered programming books obsolete. It's faster, more efficient, and just plain smarter to get your programming information online. I believe Doug McCune's experience, which he aptly describes as Why I Don't Read Books, is fairly typical.

I lay part of the blame squarely at the feet of the technical book publishing industry:

• Most programming books suck. The barrier to being a book author, as near as I can tell, is virtually nonexistent. The signal to noise of book publishing is arguably not a heck of a lot better than what you'll find on the wilds of the internet. Of the hundreds of programming books released every year, perhaps two are three are truly worth the time investment.
• Programming books sold by weight, not by volume. There seems to be an inverse relationship between the size of a programming book and its quality. The bigger the book, somehow, the less useful information it will contain. What is the point of these giant wanna-be reference tomes? How do you find anything in it, much less lift the damn things?
• Quick-fix programming books oriented towards novices. I have nothing against novices entering the programming field. But I continue to believe the "Learn [Insert Language Here] in 24 hours!" variety of books are doing our profession a disservice. The monomaniacal focus on right now and the fastest, easiest possible way to do things leads beginners down the wrong path – or as I like to call it, "PHP". I kid! I kid!
• Programming book pornography. The idea that having a pile of thick, important-looking programming books sitting on your shelf, largely unread, will somehow make you a better programmer. As David Poole once related to me in email, "I'd never get to do that in real life" seems to be the theme of the programming book porn pile. This is why I considered, and rejected, buying Knuth's Art of Computer Programming. Try to purchase practical books you'll actually read, and more importantly, put into action.

As an author, I'm guilty, too. I co-wrote a programming book, and I still don't think you should buy it. I don't mean that in an ironic-trucker-hat, reverse-psychology way. I mean it quite literally. It's not a bad book by any means. I have the utmost respect for my esteemed co-authors. But the same information would be far more accessible on the web. Trapping it inside a dead tree book is ultimately a waste of effort.

The internet has certainly accelerated the demise of programming books, but there is some evidence that, even pre-internet, programmers didn't read all that many programming books. I was quite surprised to encounter the following passage in Code Complete:

Pat yourself on the back for reading this book. You're already learning more than most people in the software industry because one book is more than most programmers read each year (DeMarco and Lister 1999). A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.

I believe the same text is present in the original 1993 edition of Code Complete, but I no longer have a copy to verify that. A little searching uncovered the passage Steve McConnell is referencing in DeMarco and Lister's Peopleware:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

It pains me greatly to read the reddit comments and learn that people are interpreting the stackoverflow.com mission statement as a repudiation of programming books. As ambivalent as I am about the current programming book market, I love programming books! This very blog was founded on the concept of my recommended developer reading list. Many of my blog posts are my feeble attempts to explain key concepts outlined long ago in classic programming books.

How to reconcile this seemingly contradictory statement, the love and hate dynamic? You see, there are programming books, and there are programming books.
The best programming books are timeless. They transcend choice of language, IDE, or platform. They do not explain how, but why. If you feel compelled to clean house on your bookshelf every five years, trust me on this, you're buying the wrong programming books.

I wouldn't trade my programming bookshelf for anything. I refer to it all the time. In fact, I referred to it twice while composing this very post.

I won't belabor my recommended reading list, as I've kept it proudly the same for years.

(Update: Tim Spalding kindly set up a LibraryThing account on my behalf – and members have already documented and entered every book pictured on these shelves. Impressive, and quite cool!)

But I do have this call to arms: my top five programming books every working programmer should own – and read. These seminal books are richly practical reads, year after year, no matter what kind of programming I'm doing. They reward repeated readings, offering deeper and more penetrating insights into software engineering every time I return to them, armed with a few more years of experience under my belt. If you haven't read these books, what are you waiting for?

It is my greatest intention to make stackoverflow.com highly complementary to these sorts of timeless, classic programming books. It is in no way, shape, or form meant as a replacement for them.

On the other hand, if you're the unfortunate author of Perl for Dummies, then watch your back, because we're definitely gunning for you.