One of the central themes of stackoverflow.

com is that software developers no lo

nger learn programming from books, as Joel mentioned:
Programmers seem to have stopped reading books. The market for books on programm
ing 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 developer
s don't read books about software development, they don't read Web sites about s
oftware 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 ha
rnessing the collective wisdom of the internet in a second window. The internet
has rendered programming books obsolete. It's faster, more efficient, and just p
lain 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 typic
al.
I lay part of the blame squarely at the feet of the technical book publishing in
dustry:
Most programming books suck. The barrier to being a book author, as near as I ca
n tell, is virtually nonexistent. The signal to noise of book publishing is argu
ably not a heck of a lot better than what you'll find on the wilds of the intern
et. Of the hundreds of programming books released every year, perhaps two are th
ree are truly worth the time investment.
Programming books sold by weight, not by volume. There seems to be an inverse re
lationship between the size of a programming book and its quality. The bigger th
e 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 le
ss lift the damn things?
Quick-fix programming books oriented towards novices. I have nothing against nov
ices entering the programming field. But I continue to believe the "Learn [Inser
t Language Here] in 24 hours!" variety of books are doing our profession a disse
rvice. 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-lo
oking 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 Pr
ogramming. Try to purchase practical books you'll actually read, and more import
antly, 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-psy
chology 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 b
e far more accessible on the web. Trapping it inside a dead tree book is ultimat
ely a waste of effort.
The internet has certainly accelerated the demise of programming books, but ther
e is some evidence that, even pre-internet, programmers didn't read all that man
y 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 tha
n most people in the software industry because one book is more than most progra
mmers 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 eve
ry two months, roughly 35 pages a week, you'll soon have a firm grasp on the ind
ustry 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 p
assage 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 abo
ut the quality of work in the field; for folks like us who write books, it is po
sitively tragic.
It pains me greatly to read the reddit comments and learn that people are interp
reting the stackoverflow.com mission statement as a repudiation of programming b
ooks. As ambivalent as I am about the current programming book market, I love pr
ogramming books! This very blog was founded on the concept of my recommended dev
eloper 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 dynam
ic? 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 h
ouse on your bookshelf every five years, trust me on this, you're buying the wro
ng programming books.
I wouldn't trade my programming bookshelf for anything. I refer to it all the ti
me. In fact, I referred to it twice while composing this very post.
my-programming-bookshelf-small.jpg
I won't belabor my recommended reading list, as I've kept it proudly the same fo
r years.
(Update: Tim Spalding kindly set up a LibraryThing account on my behalf
and member
s have already documented and entered every book pictured on these shelves. Impr
essive, and quite cool!)
But I do have this call to arms: my top five programming books every working pro
grammer 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 r
eadings, 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?