Live data from Hacker News

Books Programmers Don't Really Read (2008)

billthelizard.com

41–50 of 169 posts

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

#41

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

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

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

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

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

#46
post #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.

That incidentally is the idea behind Patterns... not this "pick a pattern to solve the problem" - or worse yet, "here's a Pattern, find the problem to solve."

The shard language. The GoF wanted that shared language, but people missed the ideal behind it and thought it was a cookbook instead.

The GoF draws from A Pattern Language ( https://www.amazon.com/dp/0195019199/ ) and I believe does a better job at communicating what Patterns should be - a common language and broad brush strokes of solving common problems (though almost always require some tweaking to make it fit just right).

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

#47
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. Inso…

Having seen far too many questions on sites about software design where someone starts out with "How do I use a Factory to solve...", I would contend that the GoF had far too much influence and missed the designer's original goals.

> Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

From an interview with Erich Gamma ( http://www.artima.com/lejava/articles/gammadp.html )

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

#48
post #40

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

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

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

#49
post #41

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

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

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.

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

#50
post #38

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

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…

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.

Post reply on HN