My rule of thumb has always been that anyone can program, even a two year old, but only a few are really good programmers. Then there are the elite. Hopefully, by educating the bad programmers, they will do a better job of the legacy they leave behind. Most programmers end up looking at other people's code and say, WTF did he do there? Why did she do it that way? Where did he get that variable? No comments! no documentation!
OO is good in that it is as simple as A PIE Abstraction, Polymorphism, Inheritence, Encapsulation.
That being said, I have seen really, really bad OO Design, which employed none of the above reasons to use OO. Moreover, poor uses of Try/Catch (Sending your exception to oblivion), but that's another discussion.
I have read this book, and it is a pretty good read. It has also been difficult to apply some of the concepts, and I see where people are getting at, and I have used certain patterns in the past, and it has helped me to refine them. I will read the other books that this blog recommends.
I believe that most projects don't allow for anyone to write excellent code, but the natural progression of programming is to:
v1. Write the code in spagetti, maybe using classes here and there, to see if it works.
v2. Fix bugs, and see where patterns can apply.
v3. Continue to fix bugs, and add enhancements, reapplying patterns when useful.
v4. You get to the point where you can't just provide a band-aid solution anymore, and it's time to refactor. Taking all the knowledge you've learned in the past, and build a better OO solution.
v5. Add enhancements, and fix bugs, reapplying patterns can apply.
v6. At this point, you hopefully have a Stable version, that you are just creating enhancements, fixing less bugs. You may have provided an API, and it's easy for your clients to customize the software.
OO has a huge initial cost, and can be geared toward large software development, so my advice is this: strike a balance between using hard to manage spagetti code, and good (not bad) OO design. Time is a huge factor on this scale, and can affect where your project lies on this scale.
The two most useful patterns I think are the State Pattern and Template Method.