
Books Programmers Don't Really Read (2008) - jotto
http://www.billthelizard.com/2008/12/books-programmers-dont-really-read.html
======
nanolith
I've read the books on both of those lists, among many others. Not because
these are all required reading, but because I've had a long career and I've
fought to continually improve my knowledge in Computer Science. It seems
rather arrogant of the author to decree that one list is canon and the other
list is not. Each of those books has its use. Does this mean that someone
needs to read _any_ of those books to be good at software? Probably not. But,
studying each of those books will improve skills in the particular domains
that the books cover.

Also, why is it suddenly in vogue to bash TAOCP and CLRS? When I read these
sorts of posts, I generally think that the author really means, "I didn't
understand these books, so therefore, they must be crap." I started reading
TAOCP very early in my career, and Knuth's low-level approach of analysis has
served me quite well over the years. It's why, for instance, I don't balk when
I need to optimize a computationally heavy algorithm on an 8-bit
microcontroller, or when I have to hand-tune a cryptographic algorithm to
avoid cache side channel attacks, I can approach the problem logically. Knuth
is an excellent teacher for the right sort of student. He's not for everyone,
and there's nothing wrong with that. Software ceased being a one-size-fits-all
field decades ago. For that reason, among many others, decrees of what is
canon or not -- such as the one made by the author of this post -- are nothing
but bunk.

~~~
phaus
He praises almost all of the books on the second list, he just thinks a large
percentage of the people that recommend them haven't read much of them.

He also doesn't seem to make the claim that the first list represents "canon"
and that the second list represents "non-canon". The first list is a list of
great books that are easily understood by most students. Many of the books on
the second list are far more advanced.

I agree that some students can learn using any of these resources. However,
most people would struggle with books like TAOCP.

~~~
nanolith
He gives some rather backhanded praise for TAOCP, if you can consider noting
that a set of books look impressive on a bookshelf as praise. For instance,
"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."

He insinuates pretty strongly that the first set of books is the canonical set
with this statement: "If you're interested enough in programming that you're
reading this blog, you've probably read most, if not all of the books in this
list, so I won't spend time reviewing each one individually."

While not being explicit, he's being pretty implicit regarding his judgement
of value for these books.

I don't necessarily agree that TAOCP is especially difficult, but I did say in
my original comment above that TAOCP is not for every student. For the right
student, working on the right set of problems, I would not hesitate to
recommend TAOCP.

~~~
phaus
You only mentioned the parts of his statement about TAOCP that, when taken out
of context, seem to prove your point.

He did note that it looks impressive on a shelf, but he also followed it up
with "and it is impressive." Furthermore, he goes on to state that it is so
comprehensive that if you have a computer science problem that falls in a
category covered by one of the published volumes of TAOCP, and you cannot find
a solution in TAOCP, that a solution likely does not exist. That's pretty high
praise IMO.

>It's very dense and academic.

Is it not a dense text written in an academic style by an academic known for
dense, academic writing? Its likely the greatest reference in existence, but
it isn't an easy book to read at all. If it doesn't seem like a challenging
read to you, then as the author already stated, you aren't one of the people
that he was talking about.

>He insinuates pretty strongly that the first set of books is the canonical
set with this statement: "If you're interested enough in programming that
you're reading this blog, you've probably read most, if not all of the books
in this list, so I won't spend time reviewing each one individually."

IMO, his statement doesn't attempt to canonize them at all. If you look at
both lists, one list is obviously far more accessible to the average
programmer than the other list. It doesn't make them better, just suitable for
different people.

>For the right student, working on the right set of problems, I would not
hesitate to recommend TAOCP.

I'm not saying that you're wrong. However, the article is about books that are
often recommended to beginners. Most people will struggle if they start with
TAOCP.

~~~
pvg
_Is it not a dense text written in an academic style by an academic known for
dense, academic writing?_

It's not. It's much more mathematical than your typical programming book and
it might not be suitable for beginners (it says so itself) but that's not
because it's 'dense and academic'. It comes with exercises, historical asides,
nerdy jokes and so on.

------
doctorpangloss
Cue the circus of people who argue over the contents of this list, despite
having actually used the learnings from books only in job interviews.

There are so many developers (like your peers at work) who have literally read
none of these books. In a Darwinian sense, isn't that evidence that there's
nothing so special about these texts for what you do?

Skip the books and just memorize what's on Interview Cake. I love that site.
It so brilliantly subverts the academic pretensions of every industrial
software development shop.

So many people will have memorized so precisely the solutions to programming
test questions that they stop being useful. Engineering managers will be
unable to come up with novel questions, because they will have no benchmarks.
Then the madness will end: Computer Science will get less popular in
university again, and this notion that these Gospels have All the Answers will
go away.

~~~
Godel_unicode
I genuinely feel bad for people who have only used the learnings from these
books in job interviews.

Either they've never had to work on a really Hard Problem, or worse they have
tried to solve such a problem without the hard-won lessons present in these
books.

~~~
doctorpangloss
> a really Hard Problem

I've heard senior recruiters express skepticism about candidates who say
they're into "Hard Problems." Experienced engineering managers usually hear
that phrase when you're looking for a lifestyle and you don't really care what
the application is.

For example, "I have no qualms that your business arbitrages nonconverting
clicks from bots and sketchy web traffic (i.e., 99% of the Internet) into
Google AdWords revenue, using up a Google customer's ad budget until the
customer has barely made a profit... You see, I'm into Hard Problems. Besides,
bots don't click twice! It must be real traffic!"

It turns out that junior people on the interview team care a lot more about
Hard Problems and the stories in these books than senior people do. And you'd
never want your hiring pipeline run by junior people.

In my opinion, Google's focus on Hard Problems has robbed academia of all the
sincere Hard Problems people. Then, they've ruined the interview process for
everyone else, ironically with the book How Google Works, convincing CEOs that
they should be asking about C.S. fundamentals and Hard Problems totally
unrelated to their Actual Problems.

~~~
tracker1
To me the funny thing is the small companies with 2-3 developers hiring like
they are google with interviews over the course of weeks, with google/amazon-
like gauntlets. You aren't google, you aren't paying google-level salaries,
why are you pretending you are.

That said, I happen to like problems in general... not necessarily "hard"
problems, but just new problems. I also like working in new domains... I mean
what other industry of work allows you to work in education, aerospace,
banking, security and marketing in a decade and a half.

~~~
ssalazar
> To me the funny thing is the small companies with 2-3 developers hiring like
> they are google with interviews over the course of weeks, with
> google/amazon-like gauntlets.

Hmm. Arguably small operations need to be more stringent if they are deciding
who will make up the next 25%-33% of their engineering workforce. At small
companies one bad hire can really poison the well.

~~~
tracker1
True, but they'd probably be better with a hire/fire fast attitude than draw
out the interview process... Interviews take time away from the people doing
the interviews that can be spent doing other things... do you really want to
allocate more than half your company for weeks vs. getting stuff done.

I mean, have a trial period of a week or three... That will tell you far more
than a gauntlet interview process with a lot of false negatives.

~~~
wilbo
For me, as a CEO, hire/fire fast is definitely more costly than a well-
designed interview "gauntlet"

Before starting my own company I was a bar raiser at Amazon. Interviews were
not supposed to last weeks (though many did and there were internal metrics
aimed at driving interview to offer cycle time down).

I'd much rather spend a few hours per interviewer per candidate getting a
solid candidate than hiring, onboarding, training, learning the candidate is a
poor fit, and ultimately going through the not-fun-for-anyone firing process.

High turnover isn't worth the lost productivity from other employees or the
hit to morale. On top of that, while learning whether or not the candidate
will make it through the trial, you're burning precious cash.

Learn how to interview and teach your people how to interview. It will save
you heartache and money.

~~~
tracker1
But do whiteboard exercises that consist of concepts that someone is unlikely
to _ever_ touch really count for the quality of code one is likely to output?

Especially when many of those concepts necessitate code that is less than
discoverable, well documented and easy to follow?

------
GuiA
The Gang of Four patterns book is one of those books that you should probably
only read when you already have decent experience writing non trivial
software.

If you do so, it will formidably crystallize knowledge you've been acquiring
subconsciously. You'll have probably been having gut feelings about why
certain things are wrong or clunky and others are elegant, and _Design
Patterns_ will give you a vocabulary to describe these things.

If you read it as a beginner, the subtleties of it all will go over your head,
and you'll end up trying to cram design patterns everywhere without much sense
or reason.

~~~
johan_larson
The problem with the design patterns books (including the GoF one) is that in
the end they didn't have much influence. Think of how few of their patterns
have become part of the vernacular of our field: Iterator, Singleton, Factory,
Adapter, and maybe one or two more. It's not a long list. If you insist on
talking in terms of design patterns, you are going to have to explain nearly
all of them to your listeners. Insofar as the authors' goal was to create a
shared language of patterns we could use for clearer communication of designs,
they fell well short.

~~~
InclinedPlane
The GoF design patterns book has two core, very closely related, problems.

The first is that it doesn't make enough of an effort to present "design
patterns" as a conceptual framework. Can you program without using design
patterns? No, you cannot. You are always using design patterns whether you
know it or not, you're just using ad hoc design patterns without realizing it
when you don't think you're using patterns. The book's failure to elucidate
commonly used ad hoc patterns as well as common anti-patterns is one of its
principle shortcomings. This is something that the refactoring book did much
better, by providing examples of how things can be engineered in different
ways and why one way might be desirable over another (and how to transition
between them). Instead the GoF book largely presents a canonical list of some
design patterns, giving people the false impression that these are special and
unique versus merely a sampling of ways one might do things.

Additionally, the GoF book doesn't make it clear that each design pattern
exists to work around specific constraints, and thus doesn't educate the
reader when and why the design pattern should be used, and when not. The GoF
list of design patterns is very much tightly coupled to the peculiarities of
Java at the time the book was written. Many of the design patterns aren't
necessary outside of that environment. For that reason, a lot of the design
patterns in the book are either obsolete or so seamlessly built in to popular
languages that it's not necessary to implement them as described in the book.
Many of the more advanced "behavioral" patterns from the book are essentially
ways to work around the fact that Java didn't have first class function, when
that changes the design patterns that you end up with become very different.

A lot of the GoF's list of design patterns just aren't that useful anymore in
modern languages, even though many of them are as applicable as ever (modern
languages bake iterator support into the language, for example).

Additionally, the GoF design patterns break down into two categories: everyday
patterns (like iterator, factory, proxy, or adapter) and sometimes patterns
(like flyweight). This means that most of the patterns shouldn't be used in
every project. Because the design patterns in the original book are somewhat
out of date and because there's been so much cargo culting around the GoF
patterns there's grown a substantial backlash against patterns. So people tend
not to describe new patterns in such a way, even though they should. The
concept itself is quite sound, but it requires diligent effort to ensure
you're applying it well.

~~~
rhapsodic
_> Additionally, the GoF book doesn't make it clear that each design pattern
exists to work around specific constraints, and thus doesn't educate the
reader when and why the design pattern should be used, and when not._

Quite to the contrary. I don't have my copy handy and haven't cracked it open
in years, but I recall clearly that they presented design patterns as reusable
solutions to commonly occurring problems. And for each pattern they outlined,
they explained what the problem was that it was intended to solve.

Alas, the part about patterns being solutions to _specific problems_ was lost
on many developers, who shoveled in applications of patterns where their
corresponding problem didn't exist. And rather than a more modular,
understandable, maintainable codebase, an inscrutable mess was often the
result.

~~~
InclinedPlane
I do have my copy at hand. While they do try to get across the concept that
not all patterns are suitable for all cases they do a remarkably poor job of
it. The "applicability" section of most described patterns is a simple bullet
list of 3 or 4 very vaguely worded sentences. This is, as evidence has proven,
wholly insufficient. There should have been much more effort into trying to
educate readers on the applicability, and non-applicability!, of each pattern,
explaining the constraints that made the pattern necessary or desirable,
laying out examples of other ways to achieve the same functionality, and also
explaining the costs and extra complexity of relying on a specific pattern.

~~~
rhapsodic
YMMV, I guess. I thought they laid it out all pretty clearly.

------
jfoutz
I think those books have a specific time* in people's careers. My first real
programming job, a couple years in i got a large project. I'd go home and flip
through the design patterns book every day. Some days, rereading the
introduction, some days rereading patterns. The project came out pretty well.

If i'd gotten a C++ job instead, i'd probably have torn up the C++ programming
language book. My copy is fairly worn, but not like that gof book.

CLRS probably isn't as helpful as it once was, because the vast majority of
time you just use an ADT from whatever library your language provides. Sure,
maybe go review some subtleties from time to time, but if you're writing an
algorithm for work, you probably do that all the time, CLRS isn't going to be
that insightful.

The dragon book was opaque to me. Just about every thing in that book, i had
to go find another discussion of. I'm just not smart enough to parse those
words and math into code.

I dunno. I'm a pretty mediocre programmer. They've been helpful to me at
various points in my career, but i don't think they are much help in modern
programming.

* I've only been able to chew through a couple chapters of TAOCP. I think the only programmers these books help are people like Fabrice Bellard. Find someone who's worked through those books, hire them. Well, if you really need to solve problems and you're not just hooking a submit button to mysql.

~~~
SloopJon
> I think those books have a specific time in people's careers.

Agreed. _Code Complete_ gave me a huge boost as a liberal arts refugee in
computing. Having given away my copy, I bought the second edition, thinking it
would be worth a reread. Not so much. _Pragmatic Programmer_ didn't do much
for me either, probably because I read it too late.

On the flip side, plodding through TAOCP just because? Better to read the
relevant chapters when you've got an actual project to chew on.

~~~
blub
Interesting. After reading Code complete (2nd) I felt that I didn't get much
out of Pragmatic programming either.

One question that keeps popping into my mind is what books and in what order
should one feed an inexperienced junior to turn them into a mature software
engineer.

~~~
jfoutz
I don't think there's a curriculum you can set up. For me, the best books were
books that talked about problems i was having at the time.

For example, my biggest take away from Code Complete was the stupid slow but
easy to test implementation of the excel calculation engine. I was working on
a print system at the time, building a stupid system and a fancy system and
comparing the results gave me a lot of insight about what was wrong with the
fancy system.

Me personally, i got a ton out of the lisp books PAIP, SICP, On Lisp, and even
the CL spec. Thinking about something in terms of stream processing or
unification from the various prolog implementations would get me started on
answers to problems i was facing (they never required unification).

Just blindly handing out reading, i'd probably give people _The Phoenix
Project_. Most organizations are a mess, and new programmers don't understand
that. The down side is, new programmers can't do much about it. It can help
explain why you do some painful stuff though, like on call or code reviews.

------
perrygeo
> I've read all of these books myself, so I have no difficulty believing that
> many moderately competent programmers have read them as well. If you're
> interested enough in programming that you're reading this blog, you've
> probably read most, if not all of the books in this list

That is some gross arrogance on full display right there. If you're as good as
me, surely you've read all these books. Any other books... flawed in ways you
should be ashamed of.

~~~
justinlardinois
Agreed. At risk of sounding like an idiot, the K&R C book and Mythical Man-
Month are the only books on that list I've even _heard of_ , and I haven't
read either of them.

Also, he gives "more of a language reference" as a reason for not reading
Stroutstrup's C++ book. Doesn't the same apply to K&R?

~~~
TheOtherHobbes
K&R actually describes C. You can pick up the original K&R from way back, and
it's not so different to the latest ANSI C. The differences aren't quite
trivial, but they're not so big they're going to distract anybody for long.

It's probably impossible for any book to fully describe C++ because it'a a
perpetually moving target on a three year update cycle.

There are always new idioms and techniques to learn, but they keep being
changed/added without any obvious coherent design strategy or logical goal.

Books can barely keep up. Stroustrop's own C++ introduction is for C++11,
which is already five years and nearly two releases old.

~~~
rtpg
For a long time this wasn't really the case. In between C+98 and C++11,
Stroustrop's book contained essentially everything you would want to know
about C++, including details on how to implement the STL yourself!

The end of the book even included a grammar for C++ (with a slight comment
about how the grammar wasn't exact because of C++ context sensitivity)

------
CalChris
I'd put SICP on the better read when dead list. Fundamental Algorithms
shouldn't be read anymore but at least I liked it when I read it. SICP was the
text in 61A at Berkeley but there were no assigned readings from it. It was
meant to be worshipped rather than read. I rather like the Dragon book but
compilers have come along. The 2nd edition is an improvement.

I'd add that EE20N used a Berkeley written text, Structure and Interpretation
of Systems and Signals. I was in the minority and liked that book. I still
have it.

~~~
smikhanov
I read SICP for the first time in February this year, 15 years into my
programming career and 12 years after graduating from a CS department. It's a
very easy and enjoyable read, even the code blocks are readable, unlike coding
examples in most (all?) modern programming books. I literally loved every page
of it.

There's just something special in the way material is presented in SICP, in
the order of topics, in the text's tone: it remains enthralling without being
difficult, it teaches without being indulgent. It absolutely is meant to be
read.

~~~
sotojuan
The tone of the book is that of learning programming and computer science for
enjoyment, learning, and fun. That's what makes it timeless.

A "stronger" example of this tone would be The Little Schemer series.

~~~
catnaroek
Sadly, SICP is lacking in mathematical rigor. Often, the book rushes to give
broken code snippets based on insufficiently deep analysis of the problem at
hand (e.g., interval arithmetic in chapter 2), and the exercises consist in
fixing the code after taking additional information into consideration. It
would be preferable to first carefully write a formal specification, and then
write the right program without so much trial and error.

~~~
sotojuan
To be fair, it was written to be a student's first introduction to computer
science. I think it's fine if you don't have to prove everything.

Ironically, Chapter 1's reliance on math for examples and exercises turns
people off!

~~~
catnaroek
This is getting it backwards. The first introduction to CS is precisely when
proofs matter most.

I agree that, ultimately, not everything has to be proven correct. Often there
isn't even a well defined criterion for software correctness. But proofs
absolutely matter in certain domains (algorithms, databases, compilers, etc.),
and there's no way you can be ready to prove things about moderately tricky
programs if you don't have practice proving things about toy ones.

------
sytelus
I've read CLRS page-to-page 3 times and doing pretty significant chunk of
exercises. It takes on average about 4-8 months with 2 hours each day. I still
think the title is accurate, i.e., its just "introduction". These days at work
I frequently bump in to algorithms that would be qualified as advanced and
CLRS content now looks fairly introductory to me. In fact book hasn't even
scratched 10% of the stuff that we use regularly in our work. I think most
people active in CS research feel the same way but if you were programmer
doing regular LOB or iOS apps then OP's view may feel more closer.

~~~
zodiac
I'm curious, what do you do at work and what kinds of algorithms do you bump
into?

~~~
sytelus
computer vision, machine learning, control software and things around that.

------
bigtunacan
The whole article just seemed like one silly anecdote. "Well these are the
books I actually read so it must be the same for everyone."

I think the author's next read should be a good statistics book.

Here's my anecdotal evidence. I have read 8 out of 10 from his first list. I
have read everything except for TAOCP from the second list. Some of the ones
from the second list I have read multiple times and I still go back too as
reference from time to time.

I have started reading TAOCP on several occasions, but I'm not going to lie;
that shit is complicated and the dry academic nature makes it even worse to
parse. I still plan to get through it in my lifetime, but I keep prioritizing
easier reading.

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

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

I don't think that's quite true. The only C++ compilers I know of are:

1\. cfront C++ (from which many C++ compilers were derived)

2\. Digital Mars C++ (the one I wrote)

3\. g++

4\. clang++

5\. EDG C++ (from which many other C++ compilers are derived)

6\. Microsoft C++

7\. Taumetric C++

It's a pretty thin list for 30 years. (I apologize if I neglected any.)
Contrast that with C - at one time in the 1980s I counted over 30 of them (I'm
not sure how many were independent creations).

Edit: removed Borland C++ as that was derived from Taumetric.

~~~
csl
Maybe Intel C++ as well? But most people who have that book didn't buy it to
write a compiler. Isn't C++ ridiculously hard to write a compiler for? While I
haven't written one, I think it'd be _much_ easier to write one for C — and
for that I imagine it would very nearly suffice to have the K&R book.

~~~
WalterBright
Every C++ front end I know of has at least 10 man years in it. I'm pretty sure
it's the hardest language to implement, by far. (The core language.)

Ironically, one of the hardest things about a C compiler is the preprocessor.
You'd think a text macro processor would be simple, and it should be simple.
There's an amazing amount of subtle complexity in just the handful of pages
describing it in the Standard.

I and many others implemented a C compiler based on K+R, and I can attest that
a lot of rework can be avoided if following a Standard instead (C89 did not
exist at the time).

~~~
mafribe

       I'm pretty sure it's the 
       hardest language to implement
    

Harder than languages that require JIT compilers to achieve reasonable
performance?

Even scalac and ghc are pretty complex beasts in order to Scala and Haskell
reasonably speedy.

~~~
WalterBright
I've written a Java compiler, and a friend of mine (Steve Russell) wrote the
JIT for it (for Symantec). It was the first JITting Java compiler, and took
only a few months to complete.

Of course, I should have said "front end". Working on the optimizer/codegen is
an endless process.

~~~
mafribe
Yes, C++ has a baroque syntax, and I wish lexing/parsing C++ on nobody.

------
userbinator
I have a hard time believing Petzold's _Code_ is in the first list, or even
the second, because its content is so very different from most of the other
books. It's not particularly directed at programmers either.

As for the design patterns book, I've glanced through it and didn't find it
all that useful; that being said, I was never a fan of that school of thought
(OOP, UML, patterns, etc.) either.

~~~
napsterbr
I bought Code as a gift to my mother, who is absolutely illiterate on computer
science. She was thrilled to have learned about morse and binary code. She
didn't get too far on the book, though, mostly because she is not completely
fluent in English (and it's definitely a difficult read for non-programmers).
But yeah, I agree this book shouldn't be on either list.

------
kuharich
Previous discussions:
[http://news.ycombinator.com/item?id=1297536](http://news.ycombinator.com/item?id=1297536)
[http://news.ycombinator.com/item?id=3754545](http://news.ycombinator.com/item?id=3754545)

~~~
orsenthil
Wow! did not know that this surfaces time and again. I think, we need meta-
post which says Posts that HackerNews readers don't really read.

~~~
chuymax
Add the article on Big O notation to that meta-post please!

Maybe it's the influx of new people to the site that upvote these articles?

------
Myrmornis
> If you're interested enough in programming that you're reading this blog,
> you've probably read most, if not all of the books in this list

oh, really?

> it's intended for the multitudes who are trying to appear smarter by
> pretending to have read them.

As opposed to trying to appear smarter by issuing decrees to the internet
about what everyone who is "interested in programming" has read.

~~~
randlet
I think part of it was that this was written in 2008 which is forever ago in
internet time. I think book learning for programmers was maybe more prevalent
back then. I know I was significantly more likely to read a programming book 8
years ago when the quality of information on the internet was much lower (2008
was the year Stack Overflow was founded!)

~~~
gozur88
I was thinking that too. The younger developers I know haven't read most of
those books because the information is easily accessible on the web.

When I started coding professionally you had to buy books because the
information wasn't anywhere else, but today even for the more difficult
subjects you can find papers and blog posts and wiki articles that cover what
you want to know at different depths and from different angles.

~~~
vizeroth
Most of the information that makes some of those books worth reading is only
easily accessible on the web in the sense that it's pretty easy to find ebooks
of many of those books on the web.

Many people learn a lot of their development knowledge from the web (and I
certainly do as well), but the majority of the web sources for material beyond
basic language reference simply extract the easiest to digest parts of the
major texts. This is why so much of what many people know about patterns,
algorithms, data structures, and even OOP, TDD, Agile, Scrum, etc. is
fragmented or even wrong.

------
kazinator
From the first list, I've only read (3) _The C Programming Language_ and only
partially (5) _Mythical Man-Month_.

From the second: (1) _Intro to Algorithms_ , absolutely cover to cover once,
and selected readings additional times; based the Kazlib "dict" module closely
on the Red Black tree algorithm (with a slight improvement); (2) _Compilers:
Principles, Techniques and Tools_ : Ditto, and in recent years, implemented a
regex compiler based on the graph-based descriptions in that book; (3) _TAOCP_
: selected readings only, too huge; (4) _Design Patterns_ : cover to cover,
when OOP was fashionable in the 90's; (5) nope, but I read the Stroustrup and
Ellis _Annotated C++ Reference Manual_ cover to cover (weekend before starting
first C++ gig). That counts as a 1:1 substitute, more or less.

~~~
vizeroth
Most of the books on the first list represent those I would only read once,
and never again (or never at all, like "Head First [Anything]"). The C
Programming Language and Refactoring are the exceptions. K&R was one of the
textbooks in my first CS class, and the first CS book I read which was still
useful to me 10 years later.

The books on the second list which I have read (at least partially) are books
I have had reason to go back to at some point in my career, and any of them
which I no longer have, I will likely purchase again.

~~~
kazinator
About the K&R2; I have no idea where my old copy is, but I know the precedence
table is on page 53, and that I found an ISO conformance bug in example code
on page 117: modifying an argv[] pointer.

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

Reminds me of the Caltech required 3rd year math course "AMa95 Introductory
Methods in Applied Mathematics", that came with the dry comment that
"Introductory does not mean elementary." It had a reputation as one of the
toughest classes.

~~~
c3534l
It sounds like they're actually conflating the two words in question.
Introductory means an introduction, like the thing that helps you get into a
subject. Elementary means basic or foundational. Logic and set theory are
elementary to the rest of mathematics. They're not introductory to the rest of
mathematics.

~~~
WalterBright
They meant do not infer it to be an easy class.

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

That's almost certainly wrong. TAOCP is very outdated in many ways and doesn't
really cover modern algorithms. It's great for classic CS upto 90ies(?) or so,
but there has been a lot of progress since then.

~~~
taeric
What do you feel it is missing? Better, where has it really been left behind?

~~~
nn3
\- probabilistic algorithms (like all the modern bloom filter variants or skip
lists or treaps) \- parallel algorithms \- cache oblivious (or just aware)
algorithms. This made a lot of difference in designing trees or graphs. \-
modern hashing (like cuckoo or robin hood hashing), or min hashing \- data
mining algorithms ...

~~~
taeric
Are you sure those are not covered? I know he covers Bloom's filter. And half
his treatment on trees is how frequency of access matters on tree creation.
(He specifically does not advise just balanced trees.)

For hashing, he does cover things at arms length.

~~~
nn3
All these things only came out after 2000. Basic bloom filter is earlier, but
modern bloom filters (and varieties like cuckoo filter) have improved quite a
bit. The standard paper on modern bloom filters came out in 2006.

It's also true for other areas. Let's take sorting. The best general purpose
comparing algorithm is timsort. timsort came out in 2002.

Keep in mind TAOCP was originally published in the early 70ies (first book
came out in 68) and even though there were some new editions (upto late 90ies)
they didn't really change all that much.

You can just scan over TAOCP's bibliography and see the average year of the
cites. It is usually 60ies.

Claiming that CS has not improved since the 60ies is fairly absurd.

~~~
taeric
I won't claim it hasn't improved. I will claim there are a lot of
rediscoveries.

Still, your point is fair. The section on secondary key retrieval is very high
level. Bloom filters get just two paragraphs.

I think the biggest change in cs is the view towards memory. In much of TAOCP,
care is given to the memory footprint. Much of day to day programming is
completely ignorant of memory. Scarily so.

------
lucidguppy
I do like the C++ programming language book. It has a really nice introduction
in the first quarter of the content. It has good no nonsense examples.

------
anexprogrammer
Let's see.

Never come across Code, Head first Design Patterns - WHY? GoF book is much
better, and well written and explained. Read all the rest, though K&R 1st
edition. Bought 2nd when someone 'borrowed' original from my desk and never
returned.

Of the rest:

Never heard of the first one, but I'm British.

My green dragon book was read cover to cover a couple of times, and I tried to
build a compiler off the back of it. I used another compiler book in equal
amount, I forget the book though.

I've three volumes of Knuth. I should have bought one at a time - I got about
1/2 way through the first volume.

Design patterns was extremely well used.

C++ was mainly reference, unlike K&R it wasn't a good read to learn from.
Pretty heavy going if I remember. The Design and Evolution of C++ was much
more interestng. Then the 2 Scott Meyers books (Effective C++ 1&2). Thinking
in C++ was the book recommended to learn from at the time, though I've not
read this.

------
tylorr
What does it say about me if I haven't read any of those books?

~~~
pjscott
It says that you have not exhausted the wonders of this world, and that good
times are ahead of you.

------
dmalvarado
Who claims to have read a book they didn't? "Yea I read that." (No I didn't).
That's straight lying.

I think what's more likely is, someone will say, "YOU should read this book.
It's awesome." The implication being, the suggestion comes from first-hand
experience.

------
rtpg
When I started programming, I first read "Beginning Programming For Dummies"
(QBasic), "C++ for dummies" (before STL, so implementing your own linked lists
was fun), and... The C++ Programming Language

I spent maybe 3 years as a kid flipping through the C++ Programming Language
book, trying to figure out how to do stuff with that + the Allegro tutorial.
Totally a programming language reference.

It's one of those weird books that you could spend years just looking at on a
desert island and find things to do with it. But you basically need to flip
through all of it to get what is happening most of the time (at least I needed
to when I was a kid).

Really wish I knew about Python back then....

------
QuadrupleA
Wanted to second the ambivalence around the CLRS Intro to Algorithms book -
having learned a few algorithms by poring through its chapters, I can
definitely say it's a long, out-of-the-way route to take for a practicing
programmer. I may not have enough hindsight (bought it a year ago) to truly
say whether the dense mathematical approach was valuable to me long-term, but
for now I'd say a wikipedia article or a less formal, more to-the-point book
like Jon Bentley's Programming Pearls is time much more well spent, unless you
are actually aiming to work in academia for a computer science department.

------
rampage101
TAOCP is so much superior to CLRS it is not even close. At the end of each
section of CLRS they ususally mention Knuth anyways.

Knuth's writing is clear and amazing. It really makes the history of computer
interesting.

Pretty typical of the author of the post who did not complete TAOCP to say it
is somehow flawed for being too cryptic.

Why is the author concerned about what others have read or not anyways? It
seems he more concerned about proving he has read more than others.

------
drew-y
Is there a good alternative to "Compilers: Principles, Techniques, and Tools"?

I've been programming for a few years now and I'm looking to more formally
educate myself in general computer science. I've been told having a good grasp
on compilers and interpreters can be useful for a wide variety of problems.

So far "Language Implementation Patterns" looks like it might be a promising
alternative.

~~~
stass
I highly recommend Modern Compiler Implenentation in ML by Andrew Appel (he is
also an inventor of a number of important modern compilation techniques).

I also rather enjoyed Crafting a Compiler. I found the explanations and
excercises to be much more practical and enjoyable than the dragon book, but
the code authors present is mostly garbage and full of global variables, state
mutations and design pattern heavy. Ignore the code and do the excercises
yourself.

I always found the Dragon book to be too parsing-heavy which gets boring
quickly. The books I listed spend far less time on parsing and much more on
code generation and optimization which I find more enjoyable. YMMV.

~~~
wtetzner
Another book that's really good it Types and Programming Languages. It goes
over how to define the operational semantics of a programming language, and
then gives examples of how to implement them.

It pretty much just glosses over parsing etc., and focuses on the semantics of
a language, which IMHO is much more interesting.

Sure, if you're building a real language implementation, you will need a
parser, but in a lot of ways it's the least interesting part.

------
pmontra
I read the Dragon book, actually studied it for a CS course. I read C for the
same reason and because it was the time when either you read books or you
didn't know stuff. Most of the other books are more recent and the web was
already there and good enough, especially for references. Those get old fast
on paper.

~~~
thomasahle
CLRS and TAOCP don't really get old that fast.

~~~
pmontra
CLRS is from 1990, too late to my party: I was through most of my CS courses
by then and who could have known about it on my side of the Pond and in a
different language? Some of my teachers probably, but maybe nobody as soon as
I graduated and got a job.

Instead I knew about TAOCP, also because of TeX. Not a required read in my CS
course. We had a smaller book, Wirth's Algorithms + Data = Programs. I skimmed
through the TAOCP volumes available online but it takes really a lot of
dedication to read substantial part of those books and I think that the impact
on my work would be minimal nowadays.

But yes, by the look of them both those books will be relevant for a while.

------
bordercases
Reading these books leads to the opportunity to take on jobs related to these
books. So people saying, "oh, I use this in my job all the time" without
reading the books _after_ they took the job, ultimately have less to say on
the matter.

------
nchelluri
Is Code Complete still worth reading for a working developer?

~~~
gozur88
I didn't think it was ever worth reading. Steve Maguire's "Writing Solid Code"
was much better, though TBH it's been so long I have no idea how it holds up.

~~~
pkroll
I've read both, and while Code Complete covers a LOT of ground, I like
Maguire's style and his practical information. I wouldn't want to be without
Code Complete, but Writing Solid Code (and his followup, Debugging the
Development Process) has plenty of decent info. And some dated.

Much of Maquire's coverage is VERY C++ centered, so people using anything else
are going to skip a bunch. It's a short book, 250 or so pages, and an easy
read.

------
marme
all 5 of the books mentioned that programmers dont read were required reading
for my CS degree. Did I read them cover to cover? no but i did read enough to
say which are useful to read and which are not. I would guess the majority of
programmers who have completed a CS degree have only read those books because
they were required reading, does that make the books less important or useful?

------
jcoffland
Wow I've read many more of the books in the second list.

The second list should also include Structure and Interpretation of Computer
Programs.

------
dudul
I missed the part where the author provides a reference/source to claim that
developers don't really read some books.

------
hilop
I've read all of 3/10 books on the first list "everyone reads", and 3/5 on the
"no one reads" list.

Most of the books on the first list were published after veterans already
learned the relevant materials -- the author must be under 30 (so under 25 at
the time).

Certainly a weird sample among popular books, the author thinks everyone reads
the same arbitrary subset of books he had.

------
good_sh_t
>programmers tend to read programming books instead of computer science books

Wow, amazing insight!

------
szines
How about Clean Code?

~~~
randlet
It was only published a couple months before this blog post was written.

------
ajarmst
Ah, another entry for the "I didn't read the books people say I should have---
here's my nationalisation" genre.

~~~
ajarmst
Sigh. *rationalisation. Doesn't really help your snark when you emit a silly
typo.

------
ori_b
Interesting. I've read almost none of the books on the first list, and
everything but TAOCP on the second.

