Periodically over on Stack Overflow (and in many other programming forums) the question comes up about what books are good for programmers to read. The question has been asked and answered several times, in several different ways. The same group of books always seems to rise to the top, so it's worth it to take a look at these books to see what everyone is talking about.
Disclosure: All of the links in the following lists are Amazon affiliate links. If you're opposed to me making a few cents off this blog, but you're interested in any of these books, they're easy enough to find by searching Google for the individual titles.
Books Most Programmers Have Actually Read
- Code Complete
- The Pragmatic Programmer
- C Programming Language (2nd Edition)
- Refactoring: Improving the Design of Existing Code
- The Mythical Man-Month
- Code: The Hidden Language of Computer Hardware and Software
- Head First Design Patterns
- Programming Pearls
- Effective Java (2nd Edition)
or Effective C++ - Test Driven Development: By Example
Among the most commonly recommended programming books there is another group that deserves special consideration. I call the next list "Books Programmers Claim to Have Read". This isn't to say that no one who recommends these books has actually read them. I just have reason to suspect that a lot more people claim to have read the following books than have actually read them. Here's the list.
Books Programmers Claim to Have Read
- Introduction to Algorithms
(CLRS)
This book may have the most misleading title of any programming book ever published. It's widely used at many universities, usually in graduate level algorithms courses. As a result, any programmer who has taken an algorithms course at university probably owns a copy of CLRS. However, unless you have at least a Masters degree in Computer Science (and in Algorithms specifically), I doubt you've read more than a few selected chapters from Introduction to Algorithms.
The title is misleading because the word "Introduction" leads one to believe that the book is a good choice for beginning programmers. It isn't. The book is as comprehensive a guide to algorithms as you are likely to find anywhere. Please stop recommending it to beginners. - Compilers: Principles, Techniques, and Tools
(the Dragon Book).
The Dragon Book covers everything you need to know to write a compiler. It covers lexical analysis, syntax analysis, type checking, code optimization, and many other advanced topics. Please stop recommending it to beginning programers who need to parse a simple string that contains a mathematical formula, or HTML. Unless you actually need to implement a working compiler (or interpreter), you probably don't need to bring the entire force of the Dragon to bear. Recommending it to someone who has a simple text parsing problem proves you haven't read it. - The Art of Computer Programming
(TAOCP)
I often hear TAOCP described as the series of programming books "that every programmer should read." I think this is simply untrue. Before I'm burned at the stake for blasphemy, allow me to explain. TAOCP was not written to be read from cover to cover. It's a reference set. It looks impressive (it is impressive) sitting on your shelf, but it would take several years to read it through with any kind of retention rate at all.
That's not to say that it's not worthwhile to have a copy of TAOCP handy as a reference. I've used my set several times when I was stuck and couldn't find help anywhere else. But TAOCP is always my reference of last resort. It's very dense and academic, and the examples are all in assembly language. On the positive side, if you're looking for the solution to a problem in TAOCP (and the appropriate volume has been published) and you can't find it, the solution probably doesn't exist. It's extremely comprehensive over the topic areas that it covers. - Design Patterns: Elements of Reusable Object-Oriented Software
(Gang of Four)
Design Patterns is the only book on this list I've personally read from cover to cover, and as a result I had a hard time deciding which list it belongs on. It's on this list not because I think that few people have read this book. Many have read it, it's just that a lot more people claim to have read it than have actually read it.
The problem with Design Patterns is that much of the information in the book (but not enough of it) is accessible elsewhere. That makes it easy for beginners to read about a few patterns on Wikipedia, then claim in a job interview that they've read the book. This is why Singleton is the new global variable. If more people took the time to read the original Gang of Four, you'd see fewer people trying to cram 17 patterns into a logging framework. The very best part of the GoF book is the section in each chapter that explains when it is appropriate to use a pattern. This wisdom is sadly missing from many of the other sources of design pattern lore. - The C++ Programming Language
This book is more of a language reference than a programming guide. There's certainly plenty of evidence that someone has read this book, since otherwise we wouldn't have so many C++ compilers to choose from.
Beginning programmers (or even experts in other languages) who want to learn C++, though, should not be directed to The C++ Programming Language. Tell them to read C++ Primerinstead.
Posts
63 comments:
I also see SICP coming up on these lists of must read books and I always wonder how many people have actually read it and done the exercises.
Also, you might find Anti-Patterns interesting as both a reference and bed time reading (if thats your cup of tea). I've perused both GoF Design Patterns and Anti-Patterns and I definatly think the latter had a much more immediate effect on my programming.
GEB should go in one of the two categories, though I'm not sure which.
Craig,
I almost included SICP in the list, but I haven't read any of it, so I didn't feel qualified to comment on it.
Anonymous,
I think GEB probably goes in the first list. It's a pretty accessible book, even for non-programmers.
Right on Bill.
I have TAOCP on my shelf, and have used it maybe twice in 20 years.
It feels good having it on the shelf though.
EvilTeach,
I've used TAOCP a bit more often than that, but certainly not more than twice a year since I bought it five years ago.
I agree that it feels nice to have it on the shelf. Knuth is brilliant, and he deserves every bit of respect he's gotten for writing it. I wouldn't be surprised if he's the only person who has ever read it in its entirety, though. :)
I disagree with a few points.
First, TC++PL is a great book to read cover-to-cover if you're a hobby programmer who is just getting into serious programming. I had played around with BASIC and Pascal in school and used TC++PL to teach myself C++ in college. Along with C++ you pick up a lot of programming wisdom from a guy who has not only done a lot of programming himself, but who spent a lot of time talking to the best systems builders in the industry, finding out how they program so he could make C++ a better language for them.
Second, it's often useful to recommend the Dragon Book to people who have simple text parsing tasks, specifically when the problem is of their own devising. I.e., when they're trying to parse a file format or other minilanguage they designed themselves. Reading a few chapters out of the Dragon Book helps you figure out how to write minilanguages that are possible (even easy!) to parse.
Third, Introdution to Algorithms is commonly used in undergraduate classes as well as graduate classes, so I'm sure many people have read eight or ten chapters out of it. It isn't bad at all as an introductory text, and most programmers who use it in school hang on to their copy as a reference book for non-experts, a comprehensive guide that explains things in a gentle way instead of just plopping down a bunch of pseudocode.
Señor Anonymo,
All three books are great. My point was that far more people claim to have read them than have actually read them.
My only real problem with TC++PL is that it is far from the best introduction to C++. There are many authors that do a better job of explaining the fundamentals than Stoustrup. Having said that, I don't think the beginning programmer was who he had in mind when he wrote it, so this is far from a failure on his part.
On the Dragon book: If what you're trying to parse is a mini-language, then it's totally appropriate to read the Dragon. I caution against recommending it when someone is trying to parse HTML (why wouldn't you just recommend a readily available HTML or XML parser?), a simple file format, or an algebraic formula. I often see people recommend the Dragon book whenever someone is trying to parse
x = a * b + c / d - e;
It looks like a job for a simple text parser. I think the Dragon book goes in to far more detail than is necessary to get the job done.
I expected CLRS to be the most controversial pick for the "Don't Read" list. I used it myself in the one graduate level CS course that I took, and I'll never get rid of it. Ever. It is a popular book at many universities, at both the graduate and undergraduate level, but I talk to far too many people who don't have even a basic understanding of the fundamental concepts of algorithm development and analysis to believe that people are actually reading CLRS. I doubt that most people get very far past the chapters on searching and sorting.
+1 for SICP, a book that actually teaches you how to think like a programmer (as opposed to the nuts and bolts, the topic of books like CC and the Pragmatic Programmer).
For what it's worth here the list of must read I give to all wannabe developers i meet. (Not in reading order)
- C Programming Language (2nd Edition)
- Data Structures and Algorithm Analysis in Java
- The Pragmatic Programmer
- Design Patterns: Elements of Reusable Object-Oriented Software
- AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
- Internetworking with TCP/IP, Vol 1
- Joe Celko's SQL for Smarties: Advanced SQL Programming
Not much of anything new but I really like the anti-pattern book which takes the pattern concept the opposite way and look at common mistakes and pitfalls of code organization. It's a bit tongue in cheek but still has valuable info.
Boyd,
That's a pretty good list. I usually recommend Head First Java to anyone who has never programmed before.
I've read about Antipatterns on Wikipedia, but I've never picked up that book. I'll have to check it out. Thanks for the recommendation.
TaPL is awesome, and everyone should read it.
PS. This only partially a joke, it's one of the most surprisingly interesting/entertaining yet incredibly mathematically rigorous and academic programming books I've seen. Still haven't read the whole thing, but it's pretty good.. it should probably make your list :)
Wow. Is this the Onion? Just because one knows how to start a car doesn't make them Hakkinen. Your not close to programming till you've slayed the "Dragon." This is often considered "Genesis" for anyone that wished to survive in the field. Some advice would be to Google it, keep quiet and listen to your peers...
I'll second an upvote for SICP - it's truly an amazing book that breaks all the stereotypes... let's just say I had preconceived notions about it beforehand, but wow I don't know how I chugged along without ever reading it. I'll admit that I didn't do all the problems because it was done at a course's pace, but reading it - definitely. Heck, just read it through then if you want go back and read it again while doing some of the exercises... what folks tend to not understand about SICP is that the exercises were designed in such a careful way as to assist in the learning of the content - this is moreso than other books, where you think obviously, sure. It's like the authors devised a way for to actually gain more out of the book if you decide to do the exercises.
The C++ Programming Language - is *superb. I had the 2nd edition, gave it away and bought the third.
* - where superb only applies to people who are serious about grokking the language.
I confess. I pretend to have read Gang of Four, when I just memorized the cover list of design patterns.
I have no respect for design patterns, as they overcomplexify everything. But interviewers love to ask about them, so whatever...
I graduated from Imperial(UK) around 2 years ago and have been programming for a well-known company in a well-paid job for just over a year now. I have read none of these books. Hurray!
+ another for SICP. Even as an experienced programmer I have gained a lot of knowledge from it. I am starting my BS in Comp Sci after almost 10 years of programming, and my course uses this book.
It is easy to read and the exercises are very well designed and worth doing. I love it when they appear easy and elementary, but they end up being hard to solve.
I think suggesting that TAoCP is comprehensive is actually quite misleading. It really provides the fundamentals of a wide range of basic computer science, but there are plenty of data structures and algorithms out there that are very useful in real-life, that simply aren't treated in TAoCP. Of course, if you can understand the algorithms that are in there, you have a much better chance of understanding more complex algorithms.
To all the people who are giving "+1 to SICP", does that mean we should all get started reading it, or are you saying that it's another book that many only pretend to read? :)
One anonymous poster said:
"Just because one knows how to start a car doesn't make them Hakkinen. Your not close to programming till you've slayed the 'Dragon.'"
I disagree. You don't need to be able to build a car to drive one.
I'm sure reading the Dragon will make you a better programmer, I just wouldn't recommend it to someone who is trying to parse HTML.
gmh33,
Thanks for recommending "Types and Programming Languages". I'll be sure to add it to my ever growing queue.
Another Anonymous reply:
"I think suggesting that TAoCP is comprehensive is actually quite misleading. It really provides the fundamentals of a wide range of basic computer science, but there are plenty of data structures and algorithms out there that are very useful in real-life, that simply aren't treated in TAoCP."
What I meant was that TAOCP is a comprehensive reference of the topics it covers. Of course it is a work in progress, so it doesn't cover all of Computer Science (yet?).
I feel really cool, at UIUC as an undergrad we had to read at least 1/2 of CLR. Take that sucka!
Here's the reading list for the undergrad class Intro to Algorithms:
http://stellar.mit.edu/S/course/6/sp08/6.046/materials.html
The Dragon Book is so hopelessly outdated that it shouldn't be recommended to anyone ever. It will teach you how to implement a moral equivalent of a crappy Pascal compiler using 1970s' techniques, and doesn't even cover basics of modern compilers like SSA.
And in general - books are a completely outdated format. For reference wikis or Google will be vastly more comprehensive and orders of magnitude faster to get what you want.
For reading from cover to cover - it's not how people learn - what you've just read won't have any points of attachment to your experience so you will barely remember a few pages worth of material after a few days. Many math books have exercises after each chapter, so you can experience what you've just read, and understand and retain it better, but for most high-level subjects it would be very difficult to create sensible exercises.
Kristian,
Reading half of CLR isn't the same as reading CLR(S).
To the Anonymous reader who posted the course notes for MIT's Intro to Algorithms,
Most programmers don't go to MIT. That sounds like a weed-out course to me. Can someone who went to MIT verify this for me? :)
taw,
You make a valid point about books being outdated. Many are outdated as soon as (before?) they're published.
Bill the Lizard. We read about the whole book, but I only read half :(
However, this post discussion brings up a great point: whenever I try to keep up with the topics in the CLR book, I use wikipedia instead. Straightforward examples and concise descriptions allow me to impress those young punks who tell me they're awesome because they went to Stanford, MIT, UIUC, or Carnegie.
Honestly though, I was a freak - I only read and comprehended 1/2 of it because I was trying NOT to read it. I was going online to all the university websites and downloading solutions to the CLR book. While organizing the answer book I was reading the solutions. Consequentially, this made me an algorithm snob in the process.
Bill, good lists, but I think the Mythical Man Month belongs in the second list. Most programmers can quote one or two lines from it, but few have actually read it.
Kristian,
Excellent point about reading material outside CLRS in an attempt to grok CLRS. I had to do the same thing when I was using it.
I don't mean to disparage the book itself. I just get annoyed with people who recommend it, when it's clear they haven't read it themselves. If you know a good Wikipedia article with the same information, send me there. :)
Dan,
That might be true. There are a few pearls of wisdom in MMM that pop up in a lot of places.
taw: You said the dragon book is outdated. You are aware that there's a recent second edition? Is that still outdated, and if so in what areas?
The dragon book 2nd edition should change their cover to have tiamat on it.
I hated that book. Guess compiler design isn't my cup of tea.
TAOCP was on my self for a few years as an excellent reference but then this spring I was getting ready to interview with google and I read it straight through esp vol 1,3 and on random numbers) and it was a real good read. He is a very funny writer and has a very noble view of what programmers do.
I srarted read to read SICP for the same reason and it was so enjoyable as well. Gotta love an approach to making a compiler that starts out with designing circuits that would run an algorithm well. And the sections on state/time/concurrency I still find myself mulling over. So just because many do not read these doesn't make them not a fun read.
I have not read any of those books. But then I'm not a "moderately competent programmer". I just copy and paste code from the Internet. However I have read "The Adventures Of Huckleberry Finn" and 18 works of Jean-Paul Sartre so you can be assured I've got the brains.
@Craig: I think the number of "normal programmers" who have read and done all the exercises for SICP can be counted on one's hands. SICP should probably be on the second list.
That said, if I knew the person I was talking to was MIT material, I would believe them if they said they had "read" it.
(I was able to get through the first four chapters, but in the last one (compilers) the examples were too large for me to really grasp. I did not try to do most of the exercises past chapter three.)
Chris Austin-Lane,
Getting through all of TAOCP is a pretty awesome accomplishment. Now that you've made the claim on a public forum, be prepared for a MMIX quiz. :)
I actually have read Introduction to Algorithms, Design Patterns, and The C++ Programming Language all the way through. I don't think the first and last did anything to help my knowledge base or my career. Design Patterns, eh... it helped me to understand a lot of the stuff I cared about until I realized that most "patterns" are idiomatic fill-ins for things a programmer should have as a library in his or her language of choice.
I keep meaning to get through SICP, but always stall out somewhere in the middle of the second chapter.
Robert Robbins,
I respect a programmer a lot more if they admit that they copy and paste code from the internet, rather than try to BS me into thinking they've read TAOCP.
I've not read Sartre, but Huck Finn is one of my favorite books. As a completely amateur writer myself, Twain just makes me downright jealous with his wit and style.
Elf,
I think the most helpful part of Design Patterns is that it provides a vocabulary for things we're already doing. It also gives good hints as to when it's appropriate to use each pattern.
I have found the parts of CLRS that I've actually read to be helpful. It might just be that the book contains too much information for my brain to hold all at once. I guess that's why I've kept the book. :)
Interesting list and comments. My take:
1) Don't often see Petzold's "Code" cited. Great read.
2) SICP. Worked (and I mean *worked*) through about 90% of it for fun (nerd alert). It's simply a great book, and like most great works, it's not for everyone. That said, I think everyone should try once to get through the first 50 pages or so, just to see what all the uproar is about. As one commenter noted, the exercises are an integral part of the learning experience. If you don't do them, you're wasting your time.
3) Not on your list: "Concepts, Techniques, and Models of Computer Programming", Van Roy and Haridi
http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695/ref=sr_1_3?ie=UTF8&s=books&qid=1229361863&sr=8-3
This is sometimes compared to SICP. Haven't read the whole thing but I'm a big fan so far.
Anonymous,
Speaking of nerd alerts, I had exactly 42 comments and you ruined it! :)
I came from an EE background originally, then went back to school to get a CS degree. Petzold's "Code" was exactly the book I needed. It's a fantastic read for anyone in either discipline.
I'm going to have to bump SICP up on my queue. With so many recommendations, I really feel like I'm missing out.
Graham's books, ANSI Common Lisp, and On Lisp, are excellent (though I've not read all of On Lisp). After those I started reading SICP. SICP is nicely organised in five large sections. They would have done well to revert to older conventions, naming the sections "Books" and the subsections "Chapters".
I worked through Book One:Building Abstractions with Procedures, Book Two:Building Abstractions with Data, Book Three: Modularity, Objects, and State. Eventually I arrive at the bit I was really interested in Book Four: Metalinguistic Abstraction, and I gave up.
Lisp's fully parenthesised prefix notation is pretty crap if you are planning on typing all your code in by hand, but it is OK because that is never the plan. You are supposed to write read-macros adlib whenever repetitive blocks of code would benefit from a denser notation with more punctutation and parsing. You are supposed to write macros to raise the abstraction level above raw Lisp.
I gave up on SICP because they were not using macros. The authors have something against them. The unrelently low level of the code was getting tedious and irritating. I bought Lisp In Small Pieces, read 19 pages, then struck out on my own, writing a headcase macro to factor out the repetition from the SICP code, and an interpreter. Don't be confused by the fact it is only 52 lines, it really works.
This convinced me that the SICP approach of Lisp without macros really was a mistake. It is too large a mistake for the book to be considered a classic.
All of your books programmers don't read were in my Computer Science curriculum.
Alan Crowe,
Thanks for sharing that experience with us. It brings to mind an interesting point. The books in the second list that I wrote about are all very theoretical, while the books in the first list are all much more practical (at least, I think that's close to the point you were trying to make about SICP). Could that be the reason for the popularity of the books on the first list?
Rick Minerich,
They probably all should be, particularly if it was a graduate program. I'm not sure how many schools use TAOCP, but I know that the other four are widely used.
In contrast, the other list is mostly ignored by universities. I think those books are more widely read by practitioners (Software Engineers) than by theoreticians (Computer Scientists).
I read more of the second list than the first.
Paco,
That could be because it takes longer to digest the books in the second list. I know I could read the entire first list in the time it would take me to read either TAOCP or CLRS. :)
Regardless, I suspect you are in the minority.
Well, the fact that a book has been bought does not mean it has been / will be read. You have no idea of how many books I have on bookshelf that I either have never started or never finished reading simply because of a lack of time.
On the other hand, Amazon is not the only provider of books in the world. On my shelf, most of the IT books have been bought at the bookshop.
Last but not least, many "old" developers (like me) have kept important books (bought at times Amazon did not exist...) that still hold good now; when these old folks started development, "bibles" such as "Code Complete" did not exist, and at the time these bibles have been edited, old folks did not need them anymore.
Jean-Francois,
"Well, the fact that a book has been bought does not mean it has been / will be read."
I know that all too well. Whenever I come home from the bookstore with four books my wife asks "Which three do you think you'll read?"
How about books programmers buy but don't actually read:
The Art of War by Sun Tzu
Any of the CJ Date Database books
Any of the XP programming books
sal,
The first two are good examples.
I'd have to see what you mean by "XP books" before I can agree with that, though. I consider TDD:By Example to be an XP book (TDD is an offshoot, but still falls under the XP umbrella).
Any of the Extreme Programming " " books like Kent Beck's Extreme Programming Explained. At least half the time, the copy sitting on the shelf has a pristine spine indicating it hasn't been opened let alone read.
If you are unsure about what you are saying, then I typically look at the Amazon rating. If 20+ people have rated a book as a 4+ in points, I have never been disappointed personally after the purchase. I use the Amazon rating system and # of users who rated it as the basis in addition to actually seeing the book in the store to verify if it's a good buy or not.
sal,
I can't speak for any of Beck's other books, as I haven't read (or bought) them. :)
Of all the times where I got the solution of how to do something programming related from a book, I bet the majority of the time that book was from the Deitel & Deitel series.
Pete Michner,
I think you just nailed my point right on the head. For every CLRS or TAOCP there are a hundred books with the same information that speak to a wider audience. It would be nice if everyone recommended those books (or Wikipedia articles) that they actually use, rather than trying to appear smarter by saying "If you haven't read Knuth, you're a bad programmer" (quote paraphrased from a reddit comment).
The only book worth reading on your "actually read" list is K&R, and even then there are better C books. As for your "claimed" list: CLRS and knuth are more reference books these days; very few people need the dragon book in it's entirety; Stroustrup is only meant to be read when you're on the toilet constipated; and all design patterns are for morons.
I'm surprised nobody's recommended "Working Effectively with Legacy Code" yet. It's a very accessible book, even if you're not working on legacy code.
I find it to be useful as a list of difficult pieces of code to unit test, and how to make them testable.
Jason,
Thanks for the recommendation. That's not a book that I've read, so I'll have to add it to my queue.
I love the design patterns book because the authors communicate simply and teach well. Many books remain unread because the authors are poor teachers. Take Stroustrup. Great knowledge, lousy teacher. God help the poor student who's first book is "the c++ programming language".
http://tinyurl.com/dmbunv
It's like trying to learn carpentry from a book about the chemistry of wood glue.
But I think the gof book isn't read because it's really just a library of patterns. With the exception of the first chapter, the book is meant to be a reference.
And really there's nothing more to retain from the book than:
1) "Design to an interface not an implementation"
2)"favor object composition over inheritance."
So Simple.
Post a Comment