Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The ranking of this list is extremely suspect.

Code Complete is a fine book. The Pragmatic Programmer is okay. But neither book holds a candle to Introduction to Algorithms for career-long usefulness. For that matter, neither one holds a candle to Design Patterns for the ability to expand your mind and improve your ability to think about code (I read both at the same time, and Design Patterns is the only one whose lessons I remember distinctly, years later).

I think the main problem here is that the easy, mechanical reads get more votes than books that are harder, but more valuable. It's the technical equivalent of a lolcat photo.



Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable.

Also, it should have a short appendix explaining that you do not get geek brownie points simply by using as many patterns as you can think of.

I realize these are not problems with the book per se, and it's worth reading, but some developers seem to get the wrong message from it.


"Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable."

Not really. I've found a use for design patterns in just about every language I've used. They're not all equally useful, but that was never the book's claim.

It's become a little fashionable to be cynical about Design Patterns, but most of them have held up well. A few of the patterns were always obscure (even at the time of writing), and a few others are trivially implemented in newer languages, but honestly, there are a lot of people who are doing a poor job of re-implementing the patterns, then doing an worse job of communicating their work. There's something useful about the notion of a consistent engineering vocabulary.

Also, I talk to a lot of people who claim to hate Design Patterns, but haven't actually read the book. They've used Java, decided that they hate Singletons and Factories, and thrown the baby out with the bathwater. There's a lot more to the book than just Singletons and Factories.


> trivially implemented in newer languages

Well this is just wrong! I would call them good languages but that just my opinion.

I have never really found it helpful to think about these patterns. Witch one do you find helpful to think about?


A lot of them are still useful abstractions (for vocabulary, if nothing else). In particular, I see Strategy patterns used all over the place (but not referred to as such), as well as Adapters, Bridges, Decorators, Facades and Proxies...but most people who have claimed to have read the book couldn't tell you the differences between those ideas.

Lots of people seem to independently "re-invent" the Observer and Visitor patterns (badly), which is a shame, because there's lots of room for subtlety in their implementations. And of course, Ruby makes use of Interpreter all over the place, and frameworks like Rails use Command, Chain of Responsibility, Mediator, Template Method, and so on...but don't really call them by their names. Blargh.


I read Design Patterns and was unimpressed. Maybe it's because I'm used to large codebases that are already well designed, but all I got out of Design Patterns was formal names for patterns that I already used in my code because they're intuitively the correct thing to do.


Indeed, that is the only correct use of Design Patterns.


I agree. I would place Dijkstra's 'A Discipline of Programming' and Feijen and van Gasteren's 'A method of multi-programming' right up there with 'Introduction to Algorithms'.

What sets these books apart is that they try to tackle the problem of _how_ to design elegant algorithms. In the process they introduce crucial concepts like invariants which, once you understand them, become indispensable tools in reasoning and designing algorithms.

More generally, their stress on elegant proofs develops a taste for mathematical elegance which would serve all programmers well as they design new systems.

These books are much too under-appreciated, in my opinion.


Personal preference I guess.

I reread Pragmatic Programmer every year.

The other two you mention I find pretty poor, to be honest. I may reference them once in a while, but to really understand the topics they cover I'll rely on a well written, colorful article over those books.

In general I've found books written by more than 2 authors to be quite boring, impersonal, and oftentimes misleading.

Code Complete and Pragmatic Programmer are two of my favorites alongside C, and the Practice of Programming.


It is SICP for me.

Design Patterns are only needed if your language is not powerful enough.

In assembler subroutines and classes are design patterns.


At least they remembered K&R.


Judging by the "The Pragmatic Programmer" book on subversion alone, this series of books has got to be absolutely horrible because they literally half-copied the svn redbook and dumbed it down so you pay good money for so very little information which you could all very easily find by spending 10 minutes with the svn redbook.


You can't really judge a book solely by the imprint it belongs to or, in the case of "The Pragmatic Programmer", stated. They're all written by different authors so their style and quality will naturally differ.

For what it's worth, it's the same imprint that gave us the pickaxe book (Programming Ruby), so perhaps that ought to be a point in it's favour.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: