
Books Programmers Don't Really Read But Recommend - ashishgandhi
http://www.billthelizard.com/2008/12/books-programmers-dont-really-read.html
======
mahmud
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.

~~~
blacksmythe
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.
    

Experience is a harsh teacher.

~~~
anthonyb
"Experience keeps a dear school, but fools will learn in no other, and scarce
in that" \-- Benjamin Franklin

------
cletus
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.

[1]: [http://www.amazon.com/Zen-Assembly-Language-Knowledge-
Progra...](http://www.amazon.com/Zen-Assembly-Language-Knowledge-
Programming/dp/0673386023)

~~~
edanm
"How many have actually read Code Complete (HN is probably a bad sample)?"

Honestly, how many programmers have actually read _any_ book about programming
outside of University classes? I'm guessing not many.

On another note, Effective C++ is not only a great book, it is the book which
single-handedly made me a _much_ better programmer, and made me understand
C++. This is after half a year of training/working in C++. It is my most
highly recommended book for really grokking C++. My only regret is that there
isn't a similar book for most of the languages I know.

~~~
zukhan
Why wouldn't people read programming books outside of university classes? How
do you improve your craft? Reading is an instrumental part in growing as a
developer and as a human being.

~~~
edanm
You're talking about whether people should. I'm talking about whether people
actually do. As for why people wouldn't read, there's one giant reason: people
don't care about programming.

Obviously you care, and I care, and arguably most people reading HN care. But
I believe that for a large percentage of programmers, programming is just
their job. They do it, they get paid for it, and as long as they can keep
getting paid for it, they don't need or care to "grow as a developer". It's
just not a priority in their life, or even a goal.

------
gregjor
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.

~~~
Jach
I second _The Practice of Programming_. I was also forced to read _Pragmatic
Programmer_ for a class in school, I was happy to find that this review sums
up my thoughts perfectly about that:
[http://www.amazon.com/review/R3KBSGSQDBND0N/ref=cm_cr_pr_per...](http://www.amazon.com/review/R3KBSGSQDBND0N/ref=cm_cr_pr_perm?ie=UTF8&ASIN=020161622X&nodeID=&tag=&linkCode=)

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!"

------
lightcatcher
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."

~~~
tricolon
CLRS is essential to any good undergrad CS programme.

~~~
thelastnode
Why?

While I have worked through a decent amount of CLRS myself, I think there are
much better ways to learn how to solve algorithmic problems. For example,
programming competition books like Programming Challenges[1] forces students
to solve real-world-ish problems according to performance constraints - a time
constraint, either artificial (e.g., problem statement requires execution
within 2 seconds) or actual (e.g., choosing an algorithm that is too slow
means the sun will burn out before the algorithm terminates).

Books and contests of this nature teach algorithmic _thinking_ , which is far
more important than the actual algorithms themselves. It also provides a
context for implementing these algorithms, which means the student gets to see
the more practical aspects as well: testing it on corner cases, fighting with
the chosen implementation language, relying on compiler optimization, etc.

If the goal of the undergraduate program is to develop practitioners of
computer science, or even graduates headed for academia, algorithmic thinking
is essential. I don't think CLRS is necessarily the best way to teach that,
and it certainly isn't the only way.

[1]: <http://www.programming-challenges.com/pg.php?page=index>

~~~
ek
It's possible that you're confusing programmers with computer scientists. Not
all programmers are computer scientists, and vice-versa.

I understand that the title of the post is about books _programmers_
recommend, but computer science extends far, far beyond programming and
learning how to engineer solutions to real-world problems using algorithms.

The important parts to people doing research in algorithms are well-covered in
CLRS, and that's part of why it's such an excellent book. It's full of
rigorous proofs and a lot of theory, but that's because the point of the text
is the design and analysis of _algorithms themselves_ , rather than the
application of them.

A university has an obligation to its undergraduate students majoring in
computer science to teach them about computer science, and learning to think
about designing algorithms, rather than merely learning about using them, is
something that I would fully expect as an undergraduate majoring in computer
science at any major university.

I suspect this is part of why more and more universities are offering degrees
in Software Engineering, where the theoretical aspects of the field are not as
important.

------
klochner
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.

~~~
mattdeboard
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!

~~~
Revisor
As suggested elsewhere, read The Algorithm Design Manual, it's much more
readable (even if not as rigorous, with math proofs and such).

------
martininmelb
This story about Steve Jobs is probably relevant:

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...](http://www.folklore.org/StoryView.py?project=Macintosh&story=Close_Encounters_of_the_Steve_Kind.txt))

~~~
dubya
I sort of wish this were true, though it doesn't sound like something Knuth
would say, but apparently it's a myth: <http://www.catonmat.net/blog/don-
knuth-steve-jobs/>

------
dkersten
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.

------
timr
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.

------
kabdib
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.

------
charlieok
Funny that SICP isn't on either of the author's lists...

~~~
cruise02
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.)

------
tumanian
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).

~~~
soiryx
Python: [http://www.amazon.com/Python-Essential-Reference-David-
Beazl...](http://www.amazon.com/Python-Essential-Reference-David-
Beazley/dp/0672329786)

Java: [http://www.amazon.com/Java-Language-Specification-The-
Editio...](http://www.amazon.com/Java-Language-Specification-The-
Edition/dp/0321246780/ref=sr_1_1?s=books&ie=UTF8&qid=1332729944&sr=1-1)

What do you mean you can't find them?

~~~
zackattack
688 pages is not concise.

------
cpeterso
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.

~~~
andyjohnson0
His book ___A Timeless Way of Building_ __is also good. Nothing thats really
applicable to software though, but very insightful.

------
willvarfar
Tangentially, I recently made a list of books I think every programmer would
_enjoy_ reading:
[http://williamedwardscoder.tumblr.com/post/19794076450/a-few...](http://williamedwardscoder.tumblr.com/post/19794076450/a-few-
books-you-must-read)

Aside, in every programming job I've been in, there's been other programmers
keen to lend me Terry Pratchett books.

------
Homunculiheaded
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.

~~~
bad_user
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.

~~~
4ad
I mistakenly upvoted you instead of downvoting you.

You can't parse context-free or context-sensitive languages with regular
expressions. You probably mean that there are _lexer_ generators that generate
a lexer based on a regular expression specification, but you still need to
provide a grammar to the _parser_ generator if you don't write a parser by
hand.

To be able to produce a grammar specification for the parser generator you
need to understand formal grammars. To be able to produce an _useful_
specification you really need to understand the general parsing algorithms and
how the specific parser generator works.

All of this is vastly more involved than just understanding regular
expressions. And this is just parsing, arguably the easiest part, not
generating code or interpreting or all the other steps compilers might do.

Yacc is at least 33 years old, newer tools are better in some ways, for
example Bison can generate a GLR parser, but they are just as easy (or hard)
to use and require the same knowledge.

> The Dragon Book is however for people wanting to build parser combinators.

You probably meant parser generator, parser combinator is a different thing:
<http://en.wikipedia.org/wiki/Parser_combinator>

~~~
bad_user

         You can't parse context-free or context-sensitive 
         languages with regular expressions
    

I didn't say that.

Also, to add to your point, current regexp libraries have capabilities that
far exceed the concept in the formal languages theory. Features like capturing
buffers or look-ahead assertions cannot describe a finite-state machine.

Also, Perl has had support for recursive regular expressions. Perl 5.10 even
has support for recursive capture buffers.

    
    
         To be able to produce a grammar specification
         for the parser generator you need to understand 
         formal grammars
    

IMHO, that's the same as saying that in order to be a programmer then you need
to know lots of math, which is in general bullshit. Even before the formal
theory was available, people have been building compilers the good-old
fashioned way - by writing top-down LL(k) parsers, without necessarily having
a name for this technique.

But I also said that one should remember some basics from its theory of
computation class, as it is helpful to know what a pushdown automaton is and
the difference between it and a finite-state machine.

    
    
         All of this is vastly more involved than just
         anding regular expressions
    

It involves functions calling each other, sometimes recursively and loops and
switches and remembering where you are in the text and doing repetitive
transformations. It's as if you're doing real programming.

    
    
         You probably meant parser generator, parser combinator 
         is a different thing
    

No, I meant parser combinator.

~~~
sb
I wonder how often you looked at a compiler's implementation to make such
claims. First of all, there are many parts in a compiler that are not fully
automated (lexer and parser generators making frontend development easier;
basically BURS systems for backend automation (w.r.t. instruction selection),
but then in optimization you have to deal with instruction scheduling,
register allocation, etc.)

Then, I also think that your comment about people having written top-down
recursive descent parsers for a long time without concrete historical
reference is suprising, particularly when we all know of a prominent example
(C) that you cannot parse with LL techniques (I rememeber a professor at
university remarking on K&R probably not knowing about LL -- though I can't
attest to this being true or not.)

I can also not figure out how you connect the Dragon book to Parser
combinators. Having implemented parsers in both, monadic and combinatoric
style (both of which btw. are a mess to debug) the best connection I can think
of is translating formal grammar descriptions using parser combinators. Is
this what you are referring to?

I like your characterization of compilers being just calling functions and
loops plus switches and pointers to text. While we know about Church-Turing
thesis, I am positive that the intricacies of database system implementation,
operating system implementation and programming langauge implementation
deserves distinction (which is supported by many of them having dedicated
special interest groups.)

~~~
bad_user

          I also think that your comment about people having 
          written top-down recursive descent parsers for a long 
          time without concrete historical reference is 
          suprising
    

I do not have concrete knowledge or evidence about it, it was a statement
based on intuition alone, sorry about that.

The reason why I said it is because the first parser I ever wrote (something
like 10 years ago), was a top-down LL(k) parser and I had absolutely no idea
about what I was doing, but in the end it worked. Many programmers are
choosing LL(k) implementations for their manually-built parsers because they
are so easy to reason about and build manually.

I was under the impression that C can be described as LL(k). C++ definitely
can't be.

About a compiler's implementation, I realize that it can get really messy,
especially for statically typed languages and especially if you want to add
type inference to it. Also agree on optimization. But the thing is, most
people don't need to build turing-complete languages or need efficient
translations to the target representation, they just need to parse DSLs or
network protocols (hence my original comment).

------
raffi
Don't forget to add Goedel, Escher, Bach to the list of books most recommend,
claim to have read, but haven't.

------
LVB
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.

~~~
Maro
I think Numerical Recipes is more of a reference.

Eg. my professor owned NRC, and he did use it, especially the CD, to take
algorithms as a plug-and-play starting point when doing some numerical
analysis. Of course, you can also get similar algorithms off the web, but some
professors are old-school like that.

------
andyjohnson0
From the article:

 __ _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
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.

------
grout
Mythical Man Month and Silver Bullet essay ought to be mandatory. K&R as well,
and Stroustrup (both C++PL and Design and Evolution of C++).

Programmers don't stand on each others' shoulders, but each others' feet.

~~~
cruise02
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.

------
capkutay
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.

------
statictype
I'm surprised that GEB isn't on the list of 'recommended but not read'

------
phzbOx
I'm an avid reader but was disappointed with the dragon book. I felt like once
finished, I still couldn't write a simple interpreter! I guess it's a good
reference.. or maybe a second book, but that's definitely not the best book to
get started and learn compilers.

I did actually read The C++ Programming Language when I was in high school..
at that time I thought it was a very important book. Now, with the insight,
how dull it was and useless!

------
calloc
I can honestly say that I have not read any single one of those books. My
first C++ book was C++ for dummies, after that everything I learned was from
online tutorials, from actually doing it, and then by the time I reached
college my knowledge was already above what the instructors were teaching in
class.

I have quite a few programming books, mostly cookbooks though, that show
little examples/snippets and or O'Reilly reference books that I used to
purchase when starting a new language to get an idea for the syntax. The best
book that I have ever bought and read was "Advanced UNIX Programming" by Marc
J. Rochkind. It helped me get a much firmer grasp on Unix programming and
along with it C which I was lacking at the time.

I've got a copy of the Dragon book sitting on my desk, it is waiting to be
read, waiting to be devoured and played with, but so far I just haven't had
the time.

One book I would like to read and wrap my head around is the Gang of Four
book, it seems like it is important to know the various different design
patterns, but so far I don't feel like I have missed out and can recognise
good design practices based solely on how they feel while I am writing them.

------
revertts
To me, a lot of this divide is between books I read cover to cover and books I
consider references or pick up for very specific sections (like "Algorithms on
Strings, Trees and Sequences").

CLRS, TAOCP, and Gang of Four are all books I haven't read in their entirety,
but have been indispensable for certain topics. I still recommend them to
people all the time, and feel perfectly justified doing so.

~~~
mturmon
Agreed. But, a lot of the recommendations are written not with the tone you
mention, but the tone of, "yeah, I worked my way through the whole book."

In fact, very few do more than read selective chapters (which is OK).

------
cjdrake
Some of the people responding to this thread might consider that they are
proving "Bill the Lizard" correct :).

I laughed when I read the article because I have checked out every one of the
books he says programmers claim to have read (TAOCP, etc) from my company's
internal library, and though I skimmed interesting parts (Go4, especially), I
hardly _read_ them.

------
npsimons
_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._

Really? Because I still have mine from undergrad, and when I was using it to
prep for a Google on-site, I was surprised that I had forgotten how far into
it we had gone (there are dog ears back to chapter 36). Of course, that class
was over ten years ago, and I (unfortunately) don't get to use it much these
days, being that I mostly deal with RF and E&M.

------
sixtypoundhound
At the risk getting flamed to a crisp for even suggesting the language or the
title, I'd recommend PHP for Dummies and the companion book, everyday projects
in PHP, as a starting point for a completely new web developer.

It's highly digestible, covers many basic concepts (HTML, loops, control flow,
variables, sessions, databases, oop), and has a number of good projects to
walk through. While I've moved on to significantly more advanced topics
(Python, functional programming), it took me a long way and laid a pretty
solid foundation for the future. They actually went relatively deep in the
details of how a website works.

BTW - I'd avoid ASP.Net for dummies. Relatively little code contained in that
one...

------
noarchy
My first programming book was K.N. King's "C Programming, a Modern Approach"
That remains one of the few programming-related books I own that has endured
some wear.

I actually have read the GoF book, but I'm not sure that I'd recommend it to
anyone.

------
alephnil
I have read none of the books on the first list, but 4 of 5 on the second, is
it something wrong with me?

To be more serious. All the books on the second list comes from people that
were signinficant contributors to the field the book is about. That does not
automatically make them good writers. All of the books on the second list is
on the dryer end of the scale. I would recommend Appel's compiler book instead
of the Dragon Book for example, even if it is less comprehensive. The Dragon
book is written in an extremly confusing way (some oldtime compiler people
have even described it as confused, esp in first edition).

------
BonoboBoner
Despite the author mentioning it, I could not get through Effective Java. It
was well written and informative, but I got the feeling that it mostly taught
me about deficiencies of JVM or the language design.

~~~
grey
I've always found that knowing the deficiencies of a language is the best way
to know the language. Anything that works well should be pretty intuitive and
comfortable, but knowing exactly where the trouble spots of a language are let
you be aware when you approach them, and know how to handle them.

------
anonymoushn
CLRS is a great book, I have read it, and other people should read it too. The
first time I tried to read it I couldn't do the necessary math, so it took a
bit more than two times through to grasp it.

TAOCP I generally recommend as a reference because I can only speak to its
usefulness when used as a reference.

Edit: By "Other people" I do not mean "Other people who are doing graduate
work" or "Other people who are in a senior level algorithms course." Really
anyone who plans to do a significant amount of programming should read CLRS,
even if he or she is still in high school.

------
xarien
This is so true and I'm completely guilty of it. I have a signed copy of The
C++ Programming Language and often find myself recommending it when in fact,
I've only read bits and pieces myself.

~~~
protomyth
My problem with that book is the italic, thin, proportional font all the code
is in (I have he hard cover). It hurts my eyes and I keep missing punctuation.

~~~
xarien
I started nodding my head when I read your post. That must say something...

------
pbiggar
I try as hard as I can to turn even aspiring compiler writers away from the
Dragon Book. You don't need a the theoretic underpinnings of 5 types of
parsing to write a compiler, and I doubt anyone could use the Dragon Book to
actually write a compiler.

I give an emphatic thumbs up to "Engineering a Compiler" (Cooper/Torczon) and
also to the Appel books. They are fantastic, readable and digestable, and
actually help get a compiler written.

------
officemonkey
I can't believe "Structure and Interpretation of Computer Programs" isn't on
that list anywhere.

~~~
tripa
See there: <http://news.ycombinator.com/item?id=3754747>

------
stephan83
I read most from the second list, but only two from the first... hipster
coder.

------
rpearl
I am an undergrad and have read most of CLRS and the dragon book.

And I will certainly read TAOCP once I have the money to reasonably justify
spending it on the set.

I wouldn't really _want_ to ever read a book on design patterns.

~~~
lwat
I bet you $50 you'll never finish reading even book 1 of TAOCP.

~~~
papaf
All the volumes are a good read - just skip the maths and assembly sections in
the first book. The rest of the work is understandable/readable without them.

~~~
dubya
Skip the maths?! I bought volume 4 because the math was interesting. I just
skip all of the coding bits. Reading Knuth, for me, is similar to reading
Martin Gardner's books.

------
nwmcsween
I've read quite a few of these, the problem with most of the ones listed is
simple - they are technical or seemingly so simple (K&R) that reading them all
the way through is a test of attention.

------
oskarth
> 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.

Really? I find that articles, blog posts and comments like to point out that
this is something people actually say. I think _that_ is untrue _. It feels
like one of the standard pseudo-oppositions that people take in order to write
a piece - as if it was controversial - even if it isn't.

_ Obviously it's placed on greatest CS books list, or something that is
valuable to have as a reference, but that's not the same thing as it being
recommended reading for programmers.

------
irahul
Among the books "programmers have read", I have read K&R, Programming Pearls
and bits and pieces of Effective Java and C++. I thoroughly enjoyed these
books.

The other books on the "have read" list are on my "don't bother reading" list.
Code Complete, Pragmatic Programmer, Mythical Man Month et al aren't my kind
of books. As far as design patterns go, I believe if you code in
Python/Ruby/Perl etc, books covering them in Java/C++ are needlessly verbose
and boring. I recommend Alex Martelli's talks

<http://www.youtube.com/watch?v=0vJJlVBVTFg>

<http://www.youtube.com/watch?v=1Sbzmz1Nxvo>

And this book which covers design patterns using Ruby.

[http://www.amazon.com/Design-Patterns-Ruby-Russ-
Olsen/dp/032...](http://www.amazon.com/Design-Patterns-Ruby-Russ-
Olsen/dp/0321490452)

Both approaches actually show you practical examples of design patterns in the
standard library or real world problems, and shuns patterns which aren't
applicable to the language or are too trivial. These talks aren't the end-all,
but they will give you a good overall knowledge, and will make further
exploration easy.

And from the "haven't read" list, CLRS is a good book and isn't as dense as it
is generally taken to be. It does have sections on proofs, but you can skip it
and jump directly to the data structure/algorithm. The pseudo code used in the
book is extremely clear, and will convert to simple python in most of the
cases. Use it as a reference, or read first few hundred pages. If the book
isn't for you, you will know it after you have read the first 100 pages.

Another book I recommend is Sedgewick's book on Algorithms. I have read the C
version. It mostly covers basic data structures and some accompanying
algorithms. The code is succinct(sometimes needlessly so) and more
importantly, it works. It doesn't sit well with everyone, but I liked it - it
helps me see the whole picture without bombarding me with a lot of code.

Skiena is another obvious favorite.

Dragon book is decent, but you need guidance and discipline to make anything
out of it. Consult your peers or teachers while using the book, or use another
book.

I haven't read TAOCP and it's low on my list for now. I have read bits and
pieces and I didn't find it as fascinating as I had hoped. It's dense and
extensive, and can be used as reference.

"Effective C++" will be a better alternative to "The C++ programming
language". But I must say, when I first read "The C++ programming language", I
found it fascinating - lengthy, but fascinating. That would be mainly because
I was beginning programming when I first read it.

------
signa11
no recommendation for 'c interfaces and implementation', surprised...

------
leon_
Huh, seems I'm a strange guy. From the "everybody has read" list I just read 2
books (pragmatic programmer and the 2nd edition) but from the list "everybody
recommends but no one actually reads" I only haven't read introduction to
algorithms.

------
nn2
I read programming pearls about halfway until I discovered that a several of
the samples were using gets() and could be trivially exploited for buffer
overflows.

Calling programs like that "pearls" just seemed too wrong to me to go on.

~~~
edwinnathaniel
As to my understanding, Programming Pearls focused lies between the range of
elegant code and algorithms/problem solving as opposed to secured coding
practice in the C programming language.

~~~
lwat
Still, someone like Knuth will argue that correctness should not be sacrificed
for elegance.

~~~
edwinnathaniel
Feel free to crucify John Bentley.

I know I'll learn more out of the book if I don't care of the small nitpicks
like "gets()".

