71–80 of 100 posts
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 le…
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 le…
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 fr…
Man, still Code Complete? I dunno. Wasn't that big a fan, honestly. I think I got more out of the first three chapters than the sum of the rest of the book. If we're talking about technical books, Refactoring is easily the most beneficial read I can remember having. I was pleased to see it (barely) trump Design Patterns... a book that I think (through no real fault of it's own) has spoiled more developer-years than i…
While I have never read Code Complete , I know of at least one very smart guy who read it, highly recommends it, and is utterly incapable of maintaining legacy code he did not write. He simply refactors everything he touches, which is not to be recommended. There are no books I know of that teach you how to work in legacy code. It's a dying art.
I'm not sure that all those people on Stackexchange have read the question properly. The question is "What is the single most influential book every programmer should read?" I.e. given the set of books that every programmer should read, which one is the single most influential? As a programmer, lets consider the answer to the question, as parsed logically (regardless of intent). Typing 'most influential books' into G…
I'm not sure that all those people on Stackexchange have read the question properly. The question is "What is the single most influential book every programmer should read?" I.e. given the set of books that every programmer should read, which one is the single most influential? As a programmer, lets consider the answer to the question, as parsed logically (regardless of intent). Typing 'most influential books' into G…
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 le…
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 fr…
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.
Earlier quoted context omitted.
The value of the GOF book is in the way of thinking, not in the actual patterns themselves.
Very much so. However, it's much less successful at instilling that way of thinking than Refactoring is. Worse yet, many readers becomeoverly enamored with the "canonical" design patterns, seemingly not realizing that most of them are special purpose constructs and only useful in very specific circumstances (and in some languages wholly obsolete). They also often don't understand that those examples are but a drop in…
That's why I like PoEAA - Fowler is better writer than the GOF so his books do a better job of bringing the ideas across.