As I've mentioned numerous times in my blog, I'm a huge fan of continuous self improvement and being a student of your chosen profession. One of my favorite ways to constantly improve is to read books. I find that my favorite topics nowadays aren't necessarily technology or API specific, I tend to be drawn more to principles and practices that can be applied across any programming language (design patterns, agile development practices, etc.). For API specific type information, that sorta stuff changes so fast I find the information on the web to be much more useful and current. A good recent example would be my foray into Linq to SQL the past few months, I never bought a book on it and instead used Scott Gu's and other folks' blogs to get up to speed on it.
So this leads me to today's book review. This isn't a programming specific book or even technology related, but I think most developers would find it a really good read anyway, at least if you've ever worked, currently working, or will work in a team environment (I think that's 99% of us). The book is titled The Five Dysfunctions of a Team
by Patrick Lencioni. The majority of the book is a fictional tale (although you'd swear you've been in situations and know people exactly like the ones in the book) that illustrates the five dysfunctions in a real world manner. The book is a very easy read (I finished in a couple of hours one evening) and really puts into words exactly why some of the teams I've been on just didn't feel right. I now more easily understand why we never achieved our full potential as a team and while there's no easy solutions, at least by now knowing the why, I can start monitoring future teams for these five dysfunctions and nip them in the bud as early as possible. The book has also changed some of my views regarding conflicts (or lack thereof) and the collaborative process.
So there you have it, the first (of many, hopefully) book review on this (somewhat) technical blog isn't even about a technical book! But that just goes to show that self improvement doesn't necessarily mean technical skills improvement, it's also about improving processes that you're involved with (in this case, improving the team process). That may be the reason why I find myself so drawn to agile software development, it not only focuses on improvement with one's technical skills (applying standard OOP principles, TDD, KISS, etc.) but also improving outside processes (iterative development, constant communication with the customer and within the team, etc.) as a whole.