> 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.
Books Programmers Don't Really Read (2008)
41–50 of 169 posts
Re: Books Programmers Don't Really Read (2008)
#42Re: Books Programmers Don't Really Read (2008)
#43Re: Books Programmers Don't Really Read (2008)
#44Wow, amazing insight!
Re: Books Programmers Don't Really Read (2008)
#45Is Code Complete still worth reading for a working developer?
Re: Books Programmers Don't Really Read (2008)
#46> 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.
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)
#47The 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…
> 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>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…
Re: Books Programmers Don't Really Read (2008)
#49> 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!)
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)
#50I'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 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.