I actively disrecommend Code Complete. I bought the first edition back when I uncritically acquired everything with a Jolt Award logo. It's a pile of tautologies and common sense. It tries to teach stuff that is best learned through experience.
K&R was my second C book, and I love it for its authenticity, but I learned more from Kelly & Pohl's "A Book on C".
The Mythical Man Month I read in anger after a project failed. It not only resonated with me, but cheered me up.
Programming Pearls can't be "read" in the usual way, it's something I flip through when facing particular problems, but generally I savor it (ended up selling my copy after my 2 year backpacking trip, back when I swore I'll never write software again .. oops!)
Effective Java (C++) are practitioner lore. Their teachings have been subsumed by the language community and you can see it in code bases.
My advice is to learn to use your favorite editor with a TAGS file, then go navigate through a large open source project, and extend it in some minor way. That's more profitable than enduring any book on "design".
I never cared for "Pragmatic" or "Test-driven" or "Agile" publications.
I am sure that for you it was a pile of tautologies and common sense, but I think most people graduating with an undergraduate degree would benefit from reading Code Complete as they start their career.
I have to admit I thought it worth the time to read. It is an easy read. There are certainly books on this list that provide >10x the value, but take >10x the effort to assimilate.
>> It tries to teach stuff that is best learned through experience.
> My advice is to learn to use your favorite editor with a TAGS file, then go navigate through a large open source project, and extend it in some minor way. That's more profitable than enduring any book on "design".
This is the truth.
On the other hand, I learned from experience that people do not take this advice when you give it. Maybe plunging into large codebase is daunting, I don't know. Now I give them http://www.aosabook.org/en/ and tell them to choose an interesting project and then read it.
Code Complete is a great book, and I don't think there are any other books out which cover the nuts and bolts in such a thorough way.
I also recommend "Rapid Development", by the same author. It sounds like a fuzzy, Agilish cliche, but a more accurate title is probably "How not to fuck up your project." All of the usual bugbears are there - technical debt, creeping requirements, gold plating, etc.
I was about to say the same exact thing, but was too afraid to because of the backlash.
That book has little to no use. It's a book you would give to someone that's a -1 level programmer on a 1 to 10 level scale, to bring him up to a 1. Really, it is.
I've always wondered if its recommended because people were not reading it, or if there is a case of general incompetence (the type that would get you fired, or not hired) in the general programming pool.
> My advice is to learn to use your favorite editor with a TAGS file, then go navigate through a large open source project, and extend it in some minor way. That's more profitable than enduring any book on "design".
If this were a book, it would probably go on the "Books Programmers Claim to Have Read" list.
Have to agree on Code Complete. The first edition was a load of waterfall bollocks and I couldn't believe anyone wrote code like that. It actively put me off a "proper" programming career. The second edition, apparently, reduced that shite, but by that point I wondered "if the author is just reproducing dogma, why bother?"
Thank you! I'm beginning to think all the Code Complete recommendations are a large scale troll-in-progress on the programming community. I found a copy years ago and opened it up to a random page right around the middle of the book. I was then greeted with a half-page or longer explanation of how the condition of a while loop is only evaluated once per iteration, rather than magically causing the loop to terminate the instant it becomes false. I was just flabbergasted. Again, this wasn't in chapter zero somewhere, but hundreds of pages into the book.
Ya know, I would put a lot of the books most programmers have read on the second list. How many have actually read Code Complete (HN is probably a bad sample)?
I totally agree about Design Patterns. That is perhaps the driest (I mistyped that as "direst"; Freudian slip?) technical book (or any book for that matter) I have ever tried (and failed) to read.
Thing is, technical books don't have to be that way. The early Michael Abrash books (eg [1]) are actually highly entertaining. Effective C++ and Java are eminently readable.
I lot of people recommend CLRS and I've certainly studied from parts of it but I found Skiena's The Algorithm Design Manual to be far more approachable and enjoyable. If your goal is to learn I suggest that. CLRS seems more aimed at people who want or need to know mathematical proofs or are bound for postgrad CS.
TAOCP and the Dragon book are classic examples of books that get recommended all the time (on SO, here and elsewhere) but I'm convinced only a handful have actually read them.
Surprised Tufte's books aren't on the second list. I see programmers referring to Tufte but I doubt many have read his books. I recommend them.
I nominate Stepanov's Elements of Programming to the second list. Beautiful, dense, and a perpetual shelf ornament. Stepanov's papers, especially the one that launched the STL, Fundamentals of Generic Programming (with James Dehnert) is a masterpiece.
I have some favorites that show my age:
Software Tools by Kernighan and Plauger. Can be thought of as the poor-man's Dragon book.
The Practice Of Programming by Kernighan and Pike. As if the UNIX way needed any defending after almost 40 years.
Reliable Software Through Composite Design and Composite/Structured Design by Glenford Myers. You have to get past the ancient languages and flowcharts. These books describe modularity and module strength and coupling and are full of good ideas that still apply.
Database In Depth by C.J. Date, for programmers who haven't read Date's textbook on databases and probably don't need to. I do wish the NoSQL weenies would read Date's Introduction To Database Systems for some history and humility. Database technology has been there, done that, moved on.
Another commenter mentioned SICP, I'd add Let Over Lambda and On Lisp which while I haven't read cover to cover I've enjoyed every section I've read so far...
In the end I don't really agree with the author's conclusions that we shouldn't recommend books we haven't read at all. Passing on recommendations of others is defensible--after all, if someone asks for a recommendation they usually want one, not a response of "I don't know" or "Go do your own research!"
Tufte's books are actually very readable and approachable, unlike say TAOCP (which is very well written but so unbelievably dense…). I don't think it's unreasonable to expect people to actually read them.
I think many people consider CLRS (Intro to Algorithms) to be far more daunting than it actually is. I have read 80% of it (wasn't interested by some parts, maybe will go back to them) and I have several friends who have done similar read-throughs. Doing all of the proofs is a bit much, but a lot of the exercises are quite good and I would hope that most programmers were familiar with the majority of algorithms described in CLRS. Essentially, I think many people are far too intimidated by CLRS. I actually found it to be quite readable, as textbooks go. Note that I did this before actually taking any algorithms class.
Perhaps the post should be rephrased to "However, unless you have at least a Masters degree in Computer Science (and in Algorithms specifically), I doubt you've HAD TO read more than a few selected chapters from Introduction to Algorithms."
While some schools do suggest the students to buy CLRS, how many actually use it religiously as opposed to the instructors going back to their own lecture notes?
At UBC, we use CLRS for 2 undergrad courses: 3rd and 4th year Algorithm courses. I'm not sure what they use in grad level. Probably still covering CLRS.
That book is very thick and I have my own doubt a 3-month long semester can cover a lot from 1000 pages.
The first list includes books that professionals read 2+years into their careers, the latter is a list of books that higher-level students read while doing an undergrad or masters degree.
I'm guessing people lie about the latter because:
a) they're much drier, and take more discipline to read
b) they indicate a more rigorous training.
I'm about a year into professional programming with no education, and decided a couple of months back to buy Intro to Algorithms. I've worked through about 3/4 of the chapter, including the exercises (with no answers :-\). It is actually not very dry at all, considering the material!
I was sitting in Steve's office when Lynn Takahashi, Steve's assistant, announced Knuth's arrival. Steve bounced out of his chair, bounded over to the door and extended a welcoming hand.
"It's a pleasure to meet you, Professor Knuth," Steve said. "I've read all of your books."
My current list of most recommended books (and that I have read) are, in no particular order:
Seven Languages in Seven Weeks
The Elements of Computing Systems: Building a Modern Computer from First Principles
The Pragmatic Programmer
Programming Challenges
Statistics: A Gentle Introduction (not exactly a programming book, but statistics is good for everyone to know and this is book is easy to read and good at explaining the concepts)
I may also recommend SICP, CTM, The Art of Multiprocessor Programming, The Joy of Clojure, the OReilly book on Intel Threading Building Blocks, Reversing: Secrets of Reverse Engineering, Test Driven Development for Embedded C and others in certain situations but the above list is a general list I would recommend regardless of the persons proficiency level or programming interests.
I pretty much assume that anyone who claims to have read Introduction to Algorithms or TAOCP is using the claim colloquially. I've read parts (large parts, in the case of Introdcution to Algorithms), but neither is a book that I want to read cover-to-cover. They're best used as reference books.
That said, there's definitely a huge number of people who claim to have read Design Patterns, but actually have only read about Singletons and Factories in a Java book. It's a shame, because Design Patterns is one of the most formative books I've read as a programmer. Everyone should read it -- observing the way that patterns are (mis-)used in Java is a poor substitute for wrapping your head around the insights in GoF.
My data stuctures course used AOCP but we skipped the first section on MIX, and didn't use MIX at all. "Just ignore that junk," our prof said.
I have fond memories of the second half of the first volume. I've used the other two volumes as references. The fourth volume I bought, but haven't had time to read in any detail; I might never get to it.
Personally I liked Sedgewick's books on algorithms ("light and fluffy and readable") though I can't stand his coding style.
I'm the author of that post. SICP is definitely the book that people most often tell me I missed when they read this. I hadn't even cracked it open at the time I wrote the post, so I didn't feel qualified to comment on it. (I've started reading it since. I haven't finished it yet, but I'd still recommend it to anyone who wants to learn Scheme or functional programming.)
SICP is also oft-recommended, and very hard to work your way all through. But even reading (and working through -- that's essential) selective parts is an excellent experience.
The C++ Programming Language and the ARM(Annotated Reference Manual) won me many interviews. After reading those I could claim that I know the language. Sadly, I could never find such concise reference for Python or Java (or Erlang, but there was no documentation anyway).
Christopher Alexander's A Pattern Language: Towns, Buildings, Construction is a candidate. It is cited as the inspiration of the Design Patterns book. But it is actually a very good (though long-winded) book.
I've read a good chunk of both the Dragon Book and CLRS. I can't even understand why someone would recommend the dragon book as a 'must read', if I was going to write a compiler again (outside of class) I would definitely search for a good alternative. It's good on theory, but I've never found it particularly enlightening. If you're not actually writing a compiler I can't think of any reason to read it.
The CLRS on the other hand I really recommend anyone interested in CS and programming purchase a copy of. It's not a book you read cover to cover, but get the first 1/3 well understood, and then when you have some downtime pick it up, scan the chapters, pick one the piques your interest and either learn a new algorithm or refresh on something you're getting fuzzy on.
To be fair I haven't spent any serious time with other recommended algorithms books, which I should. But every few months I find my self reading the CLRS and enjoying it.
The Dragon book is not necessarily for people wanting to write compilers. That's an easy task for simple languages that gets even simpler by the usage of modern tools. Any developer that understands regular expressions and remembers some material from their Theory of Computation classes should have no problem building compilers.
The Dragon Book is however for people wanting to build parser combinators.
Well, in my compilers course, we used the Dragon Book and had programming assignments in Lex and Yacc/Bison (which the latest edition does cover). TBH, I found those assignments quite fun to solve. Of course, that isn't writing a compiler from absolutely nothing, but it did make us more confident of the stuff we were learning.
Dragon book is something a compiler writer should read, but after he's gone through a compiler construction book first (I like Wirth's book; short and to the point). Definitely not an intro to compilation, it would scare me away.
I'd be tempted to add Numerical Recipes in C to the second list. I've often referred to it for various algorithmic problems thinking that it will be helpful and practical (examples in C!), but I'm usually disappointed. Most of it is targeted at very technical, math heavy problems. But hey, should my job require use of Toeplitz Matrices, NR is just an arm's length away!
This is NOT at all a knock on the book, since the title makes quite clear what it's about. But for whatever reason this one seems to end up on various "good to have on your shelf" lists when it probably isn't.
The problem with Design Patterns is that much of the information in the book (but not enough of it) is accessible elsewhere.
Maybe now, but I don't think this was true when the GoF book was published in 1995. My recollection is that there weren't a lot of books on software architecture (code- or system-level) back then because it wasn't so much of an issue. Most of us were writing monolithic C code or trying to get reuse of C++ libraries. The whole "architecture astronaut" thing hadn't got started.
That is was so ahead of its time is what makes it an important book.
You're absolutely right. Maybe that should have been "The problem with design patterns..." That is, it's not a problem with the book itself at all, but a problem with the message in the book being disseminated and often watered down.
Anyone who's working in industry (particularly if you're in any danger of being promoted to project lead) should read Brooks. The others are more language-dependent, but the lessons in MMM and NSB are applicable to everyone in software industry or any kind of project management.
Anytime I'm a little unclear or need a refresher on a sorting algo or how a data structure is implemented, I've found CLRS to be an extremely useful resource. It has been a life saver in my algorithms class (undergrad)...I think it works best as a supplement to lectures and exercises you would encounter in any data structs/algo class. It's especially useful for exam practice. I would guess that the exercises would also be really helpful practice for job interviews..But its not the kind of book I'd sit and read cover to cover.
[+] [-] mahmud|14 years ago|reply
K&R was my second C book, and I love it for its authenticity, but I learned more from Kelly & Pohl's "A Book on C".
The Mythical Man Month I read in anger after a project failed. It not only resonated with me, but cheered me up.
Programming Pearls can't be "read" in the usual way, it's something I flip through when facing particular problems, but generally I savor it (ended up selling my copy after my 2 year backpacking trip, back when I swore I'll never write software again .. oops!)
Effective Java (C++) are practitioner lore. Their teachings have been subsumed by the language community and you can see it in code bases.
My advice is to learn to use your favorite editor with a TAGS file, then go navigate through a large open source project, and extend it in some minor way. That's more profitable than enduring any book on "design".
I never cared for "Pragmatic" or "Test-driven" or "Agile" publications.
[+] [-] blacksmythe|14 years ago|reply
I have to admit I thought it worth the time to read. It is an easy read. There are certainly books on this list that provide >10x the value, but take >10x the effort to assimilate.
Experience is a harsh teacher.[+] [-] sanxiyn|14 years ago|reply
This is the truth.
On the other hand, I learned from experience that people do not take this advice when you give it. Maybe plunging into large codebase is daunting, I don't know. Now I give them http://www.aosabook.org/en/ and tell them to choose an interesting project and then read it.
[+] [-] anthonyb|14 years ago|reply
I also recommend "Rapid Development", by the same author. It sounds like a fuzzy, Agilish cliche, but a more accurate title is probably "How not to fuck up your project." All of the usual bugbears are there - technical debt, creeping requirements, gold plating, etc.
[+] [-] powertower|14 years ago|reply
I was about to say the same exact thing, but was too afraid to because of the backlash.
That book has little to no use. It's a book you would give to someone that's a -1 level programmer on a 1 to 10 level scale, to bring him up to a 1. Really, it is.
I've always wondered if its recommended because people were not reading it, or if there is a case of general incompetence (the type that would get you fired, or not hired) in the general programming pool.
[+] [-] Negitivefrags|14 years ago|reply
If this were a book, it would probably go on the "Books Programmers Claim to Have Read" list.
[+] [-] tsotha|14 years ago|reply
[+] [-] buff-a|14 years ago|reply
[+] [-] kragen|14 years ago|reply
[+] [-] mustjoinsiiiite|14 years ago|reply
[+] [-] cletus|14 years ago|reply
I totally agree about Design Patterns. That is perhaps the driest (I mistyped that as "direst"; Freudian slip?) technical book (or any book for that matter) I have ever tried (and failed) to read.
Thing is, technical books don't have to be that way. The early Michael Abrash books (eg [1]) are actually highly entertaining. Effective C++ and Java are eminently readable.
I lot of people recommend CLRS and I've certainly studied from parts of it but I found Skiena's The Algorithm Design Manual to be far more approachable and enjoyable. If your goal is to learn I suggest that. CLRS seems more aimed at people who want or need to know mathematical proofs or are bound for postgrad CS.
TAOCP and the Dragon book are classic examples of books that get recommended all the time (on SO, here and elsewhere) but I'm convinced only a handful have actually read them.
[1]: http://www.amazon.com/Zen-Assembly-Language-Knowledge-Progra...
[+] [-] gregjor|14 years ago|reply
I nominate Stepanov's Elements of Programming to the second list. Beautiful, dense, and a perpetual shelf ornament. Stepanov's papers, especially the one that launched the STL, Fundamentals of Generic Programming (with James Dehnert) is a masterpiece.
I have some favorites that show my age:
Software Tools by Kernighan and Plauger. Can be thought of as the poor-man's Dragon book.
The Practice Of Programming by Kernighan and Pike. As if the UNIX way needed any defending after almost 40 years.
Reliable Software Through Composite Design and Composite/Structured Design by Glenford Myers. You have to get past the ancient languages and flowcharts. These books describe modularity and module strength and coupling and are full of good ideas that still apply.
Database In Depth by C.J. Date, for programmers who haven't read Date's textbook on databases and probably don't need to. I do wish the NoSQL weenies would read Date's Introduction To Database Systems for some history and humility. Database technology has been there, done that, moved on.
[+] [-] Jach|14 years ago|reply
Another commenter mentioned SICP, I'd add Let Over Lambda and On Lisp which while I haven't read cover to cover I've enjoyed every section I've read so far...
In the end I don't really agree with the author's conclusions that we shouldn't recommend books we haven't read at all. Passing on recommendations of others is defensible--after all, if someone asks for a recommendation they usually want one, not a response of "I don't know" or "Go do your own research!"
[+] [-] jcromartie|14 years ago|reply
[+] [-] gchpaco|14 years ago|reply
[+] [-] lightcatcher|14 years ago|reply
Perhaps the post should be rephrased to "However, unless you have at least a Masters degree in Computer Science (and in Algorithms specifically), I doubt you've HAD TO read more than a few selected chapters from Introduction to Algorithms."
[+] [-] edwinnathaniel|14 years ago|reply
At UBC, we use CLRS for 2 undergrad courses: 3rd and 4th year Algorithm courses. I'm not sure what they use in grad level. Probably still covering CLRS.
That book is very thick and I have my own doubt a 3-month long semester can cover a lot from 1000 pages.
[+] [-] tricolon|14 years ago|reply
[+] [-] sceptre|14 years ago|reply
[deleted]
[+] [-] klochner|14 years ago|reply
I'm guessing people lie about the latter because:
[+] [-] mattdeboard|14 years ago|reply
[+] [-] martininmelb|14 years ago|reply
I was sitting in Steve's office when Lynn Takahashi, Steve's assistant, announced Knuth's arrival. Steve bounced out of his chair, bounded over to the door and extended a welcoming hand.
"It's a pleasure to meet you, Professor Knuth," Steve said. "I've read all of your books."
"You're full of shit," Knuth responded.
(http://www.folklore.org/StoryView.py?project=Macintosh&s...)
[+] [-] dubya|14 years ago|reply
[+] [-] dkersten|14 years ago|reply
Seven Languages in Seven Weeks
The Elements of Computing Systems: Building a Modern Computer from First Principles
The Pragmatic Programmer
Programming Challenges
Statistics: A Gentle Introduction (not exactly a programming book, but statistics is good for everyone to know and this is book is easy to read and good at explaining the concepts)
I may also recommend SICP, CTM, The Art of Multiprocessor Programming, The Joy of Clojure, the OReilly book on Intel Threading Building Blocks, Reversing: Secrets of Reverse Engineering, Test Driven Development for Embedded C and others in certain situations but the above list is a general list I would recommend regardless of the persons proficiency level or programming interests.
[+] [-] timr|14 years ago|reply
That said, there's definitely a huge number of people who claim to have read Design Patterns, but actually have only read about Singletons and Factories in a Java book. It's a shame, because Design Patterns is one of the most formative books I've read as a programmer. Everyone should read it -- observing the way that patterns are (mis-)used in Java is a poor substitute for wrapping your head around the insights in GoF.
[+] [-] kabdib|14 years ago|reply
I have fond memories of the second half of the first volume. I've used the other two volumes as references. The fourth volume I bought, but haven't had time to read in any detail; I might never get to it.
Personally I liked Sedgewick's books on algorithms ("light and fluffy and readable") though I can't stand his coding style.
[+] [-] charlieok|14 years ago|reply
[+] [-] cruise02|14 years ago|reply
[+] [-] Shorel|14 years ago|reply
It makes the book a totally different and more complete experience.
So, this can be a book people read, but not really read. If this makes sense...
[+] [-] mturmon|14 years ago|reply
[+] [-] tumanian|14 years ago|reply
[+] [-] soiryx|14 years ago|reply
Java: http://www.amazon.com/Java-Language-Specification-The-Editio...
What do you mean you can't find them?
[+] [-] cpeterso|14 years ago|reply
[+] [-] edwinnathaniel|14 years ago|reply
This is the equivalent to The C++ Programming Language. Written by Ken Arnold, James Gosling, etc.
[+] [-] cpeterso|14 years ago|reply
[+] [-] andyjohnson0|14 years ago|reply
[+] [-] lhnz|14 years ago|reply
[+] [-] willvarfar|14 years ago|reply
Aside, in every programming job I've been in, there's been other programmers keen to lend me Terry Pratchett books.
[+] [-] Homunculiheaded|14 years ago|reply
The CLRS on the other hand I really recommend anyone interested in CS and programming purchase a copy of. It's not a book you read cover to cover, but get the first 1/3 well understood, and then when you have some downtime pick it up, scan the chapters, pick one the piques your interest and either learn a new algorithm or refresh on something you're getting fuzzy on.
To be fair I haven't spent any serious time with other recommended algorithms books, which I should. But every few months I find my self reading the CLRS and enjoying it.
[+] [-] bad_user|14 years ago|reply
The Dragon Book is however for people wanting to build parser combinators.
[+] [-] pm90|14 years ago|reply
[+] [-] gnuvince|14 years ago|reply
[+] [-] raffi|14 years ago|reply
[+] [-] LVB|14 years ago|reply
This is NOT at all a knock on the book, since the title makes quite clear what it's about. But for whatever reason this one seems to end up on various "good to have on your shelf" lists when it probably isn't.
[+] [-] andyjohnson0|14 years ago|reply
The problem with Design Patterns is that much of the information in the book (but not enough of it) is accessible elsewhere.
Maybe now, but I don't think this was true when the GoF book was published in 1995. My recollection is that there weren't a lot of books on software architecture (code- or system-level) back then because it wasn't so much of an issue. Most of us were writing monolithic C code or trying to get reuse of C++ libraries. The whole "architecture astronaut" thing hadn't got started.
That is was so ahead of its time is what makes it an important book.
[+] [-] cruise02|14 years ago|reply
[+] [-] grout|14 years ago|reply
Programmers don't stand on each others' shoulders, but each others' feet.
[+] [-] cruise02|14 years ago|reply
[+] [-] capkutay|14 years ago|reply
[+] [-] statictype|14 years ago|reply