I don't know if you're familiar with this book, but it is the definitive catalogue on the most common design patterns that are in use in object oriented systems.  You will often hear these four authors referred to as "Gang of Four".

Perhaps the biggest name in this space is one Martin Fowler.  His book, Patterns of Enterprise Application Architecture, is the definitive book on building enterprise class applicaitons (and what that means is open for debate).  This book and the concepts are important as you will find, repeatedly, that many of the projects that come out of Microsoft's Patterns and Practices Group reference patterns that are documented in this book (see the bibliography) section of the Enterprise Library.

Note that both of these books are language agnostic and, instead, cover the concepts that go into building interoperable, maintainable, and reusable code.  In fact, you will find that both of these books and the concepts mapped out within are extremely common in the J2EE world and are only slowly trickling down in the .Net/MS space due to the leadership position that the Patterns and Practices group has taken with the release of Enterprise Library, but more importantly, the birth of .Net.

While I've read through the GoF book, I have not had a chance to delve into the PEAA book yet (it's next on my list of books this year).  And, as I mentioned at lunch, even with a full understanding of these concepts, it's rare that people will come with a full design first.  It's an organic process of building, refactoring, rebuilding, and so on.  You must absolutely have the right type of working environment and leadership to make it work.

One common problem that arises when you read this book is that the concepts in it are fairly useless unless you can get everyone in your team to buy into it.  For that to happen, everyone has to understand the common language.  And for that to happen, everyone will have to have read the books.  Since very few consultants that I've met actually read text on this level (abstract, general principles), it's a rarity to be able to discuss design patterns with other developers and it's simply not worth the effort unless the development team is really looking to learn (I've been in one environment where the GoF book was purchased for every member of the dev team and required reading).  Actually, prior to coming here, my plan was to do a "book of the month" deal with one of my co-workers at [Company A] whereby we'd consume one book a month on software engineering practices (be it architecture, programming philosophy, computer science "classics", or whatever) and discuss on a daily basis (a chapter a night, 30-45 minutes of discussion in the morning).  I think this is really the only way to improve the development practices of an entire organization...you must have people that are willing to learn (and sacrifice time to do so) and you must have leadership that is willing to sponser and encourage such learning. 

In most environments, like [Company B], when consultants are hired, they are not hired to bring in best practices and build reusable code or act as software engineers; there is no concept of fostering better development practices because the leadership cannot see the value in it (indeed, the value is abstract and is only tangible in the future).  In these environments, consultants are viewed as extra hands to write code.  It becomes the decision of the individual consultant as to whether he/she chooses to utilize these design patterns (or any OOP practices at all).  When used in such a way, the power of building reusable code is highly limited as developers are essentially working in isolation until integration (which defeats the purpose going through the trouble of creating reusable software).  In all honesty, you will only see such practices in software development shops, smaller companies that have leaders that buy into these practices and patterns, and places where there has been a "grass roots" movement by developers to improve their skills.  In the large organizations that I've worked with, including [Company C], [Company D], [Company E], and [Company F], only [Company F] had developers that were actively pursuing better development practices.  And even there, only a small group of them (only two that I met) were capable enough to do so.  I briefly worked with one developer at [Company Z] (before we were [Company A]) whom also shared a passion for software engineering practices and design principles.  Unfortunately, he left the company in May/June of last year in what was a very disappointing day for me (it's always upsetting when a company cannot retain top talent like this guy).

In my situation, as I've mentioned, I'm not one to force my views on other developers, especially ones that I've not worked with.  Even beyond that, as I've mentioned, it's a collaborative effort; it's pointless to speak the language of design patterns, abstraction, and building reusable code when no one else understands and no one else has interest in learning it and this culture at [Company B] does not encourage it.

So, that's my take.