Live data from Hacker News

Books Programmers Don't Really Read (2008)

billthelizard.com

21–30 of 169 posts

Re: Books Programmers Don't Really Read (2008)

#21

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…

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.

Re: Books Programmers Don't Really Read (2008)

#22

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…

Upvote for Interview Cake, that website has been more helpful than most of my CS courses.

Re: Books Programmers Don't Really Read (2008)

#23
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.

Re: Books Programmers Don't Really Read (2008)

#24
post #6

> 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... flaw…

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?

No. Save for the appendices, K & R can be completed and understood in a weekend. It's kind of fun to read and to work through the problems, even if you rarely use C. The Sepples book, on the other hand, is an encyclopedia. I don't know why anyone would want to read that unless he had to.

In 2016, however, I think that a lot of people would have read CLRS, even if they haven't read ALL of it. It's used as the reference text by a lot of university courses on algorithms.

Re: Books Programmers Don't Really Read (2008)

#25
post #20

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.

Give SICP a try. Then, pick up the dragon book if you enjoyed SICP. It's a different experience after that.

Re: Books Programmers Don't Really Read (2008)

#26
post #20

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.

Give SICP a try. Then, pick up the dragon book if you enjoyed SICP. It's a different experience after that.

Thanks. I've heard good things about SICP and that it pairs well with "The Little Schemer" and "The Seasoned Schemer".

Re: Books Programmers Don't Really Read (2008)

#27
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.

Re: Books Programmers Don't Really Read (2008)

#28
post #7

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 desc…

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.

Re: Books Programmers Don't Really Read (2008)

#29
post #6

> 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... flaw…

I don't believe the author intended to insult you. It's very likely you do know much of what those books have to offer. It's also possible you think about the topics in those books in a different manner. One of the benefits of a group of programmers reading the same book is the shared language.

Re: Books Programmers Don't Really Read (2008)

#30
post #8

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, Structur…

Heh, sounds like the classic undergrad approach to textbooks. Having skipped out in CS as an undergrad I am currently reading SICP to fill in gaps that I have missed and have found it to be a great read and the problems to be enjoyable. Frankly, I can't imagine going to class being more effective than reading the text (assuming you do the problems in either case).
Post reply on HN