I disagree that Patterns of Enterprise Application Architecture is an excellent book. I found it to be poorly written and appallingly edited. (Martin Fowler is capable of much better.) More importantly, the patterns themselves give an impression of coherence and well-understoodness to a space that is in fact incoherent and poorly understood. This results in people thinking and talking more about patterns than about the problems they're actually trying to solve with software. In other words, the whole enterprise (pun intended) is premature optimization at a meta level.
Refactoring is better because it's on a smaller scale and thus able to deliver roughly what it promises.
As far as the enterprise-OO space goes, though, the best book by far IMO is Eric Evans' Domain Driven Design. One reason it's better (apart from being superbly written) is that it's much more exploratory: it doesn't pretend to have figured things out, but rather offers principles you can use to figure things out. Also, the principles, though deep, are easy to understand (as opposed to "enterprise application architecture patterns" which get more confusing the more you try to understand them). In fact, the only weak spots in DDD are the points at which it veers closer to the PEAA approach.
(Disclosure: I worked with Eric for several years. But my high opinion of his book was not caused by this; it was the other way around.)
God don't read anything about patterns or refactoring. That'll sap all of your creativity and cover you in a tight fitting straight jacket. Read a language spec. That gives you the building blocks. Then go away and play with them.
I read the Gang of Four Design Patterns book straight out of college when I had a job as a dev lead at a small lifestyle software startup. Man, I tried to make every problem fit into that mindset.
I'd do things like hand-roll my own XML parser in PHP (never mind LibXML bindings, etc) while trying to make sure I was observing the Visitor and Command patterns, oblivious to the silliness of the situation.
I also missed the understanding of dependency injection (or just management in general) that would have made that hellishly large Flash project so much easier to test and assemble.
Somehow I still managed to get a lot done. I feel in retrospect, that the Design Patterns are good to know about, but I don't know about whether anyone should intend to implement them.
Patterns are primarily useful when you refactor to a pattern once you've gotten through the implementation to the point where you realize that applying the pattern would improve the code you've already written and make it clearer/more flexible/easier to extend. Starting with the intention of implementing a given pattern is almost always the wrong thing; recognizing when you've inconsistently half-implemented something very similar to a well-established pattern can actually help improve your code.
Unfortunately, people do often attempt to start from the pattern, which gives the whole idea of patterns a bad name, since most people's primary exposure to them comes from Some Guy In The Office Who Just Read The Gang Of Four Book And Now Tries To Use Patterns For Everything He Does. And everyone, rightly, hates working with that guy or his code. The same thing happens with XP/Agile/TDD, where most people's exposure to them is from some annoying zealot rather than someone a little more experienced and pragmatic.
Also, I remember interviewing with an early Bubble2.0 startup, and spouting tons of Design Pattern rhetoric to a Smalltalk guru. Also I tried to make small talk about wife and kids, when in retrospect, it should have been obvious that in SF, that isn't always the way people are wired.
The CTO at a startup I worked at read some book about patterns sometime before I got there. Guess what ? They HAD to start on a new version of their VoIP client right away, and it HAD to be architected using patterns. Right. The v1 is still the best.
> don't read anything about patterns or refactoring
Actually, I wish I had done so. Then, after dumping it in disgust, I wouldn't have allowed programming to burn my youth, and would perhaps now be in an honest and not yet intellectually-stunted field like chemistry - where cube farms are unknown and the subject has some actual (vs. accidental) depth (see: http://tinyurl.com/lfzb58)
Glad to hear I'm not the only one with a copy of The Pragmatic Programmer on its way to tatters as a result of chronic re-reading; I'd begun to think I wasn't getting out of it what I should be. I likewise recommend it to other programmers, new or otherwise.
I avoided The Passionate Programmer when it was called My Job Went To India, deterred by the title and lack of reader recommendation. Maybe I'll give it a look now. Somewhat related, I found Land The Tech Job You Love to be a comprehensive and insightful resource.
I avoided the first edition too. Dave Thomas' blog post about the new edition is what got me to read it.
I've yet to read Land the Tech Job You Love. I know I should, I just sort of have the tech job I love :-) At any rate, they're both supposed to be very complimentary.
How does one know a great book with out consuming some junk? We learn when we do it wrong up much more often than when do it right. It is not always clear in the beginning that putting business logic in with the view or the data layer code will later be impossibly difficult to untangle. I would suggest read what you want then do what you think is best. It doesn't matter if it is completely correct. (whatever correct is) Some good peer review will keep the bad trouble away, or at least the decision to keep it will be made with the eyes open. Nothing will create a great programmer faster than untangling those darn tangles.
I understand that this is off-topic, but is it really necessary to downvote it to invisibility? It's a silly joke. It costs you two seconds of your life to read it, and none for laughing if you don't find it funny. Just move on.
I think it's meant to be. Much as I love a bit of humour, take a look at reddit. Endless pun-threads and stupid jokes do drag down the quality of conversation - and people are no doubt afraid of the slippery slope.
As things stand, I like HN the way it is, and if I feel like something a bit more laid back then i read proggit.
A reasonable answer, but I keep thinking that there has to be some middle ground between pummeling the occasional (and clearly not mean-spirited or cruel or nasty) joke and the barbarian hordes of pick your least favorite other place.
Edit: Based on the voting, I'm clearly in the minority, so I'll leave it alone in the future.
Refactoring is better because it's on a smaller scale and thus able to deliver roughly what it promises.
As far as the enterprise-OO space goes, though, the best book by far IMO is Eric Evans' Domain Driven Design. One reason it's better (apart from being superbly written) is that it's much more exploratory: it doesn't pretend to have figured things out, but rather offers principles you can use to figure things out. Also, the principles, though deep, are easy to understand (as opposed to "enterprise application architecture patterns" which get more confusing the more you try to understand them). In fact, the only weak spots in DDD are the points at which it veers closer to the PEAA approach.
(Disclosure: I worked with Eric for several years. But my high opinion of his book was not caused by this; it was the other way around.)