Team Geek, by Brian Fitzpatrick and Ben Collins-Sussman, can reasonably said to be summed up by one word: asshole. Though the this authors don't frame the discussion in quite this way, this is largely a book about the damage that assholes and the culture of assholes does to individual programmers, programming and businesses.
This is, then, not a technical manual. It is a management manual, a book dedicated to helping programmers and managers build effective teams and this build effective products. That last point is important: this is not a book aimed at MBAs or meant to instruct managers in the art of working programmers just to the point of death before making them train their -- usually outsourced -- replacements. The two authors care about creating good, even great, products and all of their advice is aimed at people who want to do the same. They have years of experience making good to great products, and their desire to allow people the space to make those good to great products shines through the text.
Their advice essentially boils down to "don't be an asshole, don't tolerate assholes, and don't hire assholes." They express the sentiment quite a bit more eloquently but I think I have captured the essence of the argument. They spend a good portion of the opening book discussing why what they call the myth of the genius programmer hamstrings both individual development and team effectiveness If you believe that single, solitary genius are what programmers aspire to, then you are less likely to be open to exposing yourself to criticism form your peers, making your work less likely to be successful. Further, if you believe in the idea that a solitary genius is necessary for great products, you are often willing to overlook poor behavior in the mistaken belief that such behavior is required to ensure the success of your product. In reality, assholes don;t teach anyone anything useful, don't listen to others, and drive good people away by the sheer dint of their unpleasantness. Assholes, unsurprisingly, turn out to be bad for business.
So why buy this book, if the message is so simple? Because it can be surprisingly hard to break out of these patterns, to shrug off such a widely accepted myth. The real genius of this book, the real power of it, stems from the wealth of practical advice the authors have to avoiding these patterns. As I mentioned before, the authors have worked in these trenches, as developers and as managers, and have seen these patterns and successfully overcome them in their own careers. Whether they are discussing code reviews, or commenting systems, or fostering collaboration in a team, they focus on the one goal of eliminating assholes. And their advice is almost unfailingly useful to that mission. Reading this book, then, is a practical guide to asshole elimination, whether the asshole is you or a member of your team. It is solid advice about an overlooked and often difficult to deal with aspect of programming. I highly recommend this book.