New book review forTeam Geek: A Software Developer's Guide to Working Well with Others, by Brian W. Fitzpatrick and Ben Collins-Sussman, O'Reilly, 2012, reposted here:
Arguably the best text on the software development process that focuses on the individual contributor within the context of a team. When I initially discovered this text, I was wary whether it would have anything to offer, and if so, whether it would cater to new development staff or seasoned professionals, but after a reading I am convinced that Fitzpatrick and Collins-Sussman have something to offer regardless of technical career stage, and even offer significant insights to managers who are willing to learn.
After discussing the myth of the genius software developer, the authors present their thoughts on a healthy team culture, followed by discussions on effective team leadership, working with difficult people, using organizational manipulation to get things done effectively, and user engagement. At first glance, the discussion on user engagement might seem out of place, but my consulting experience has shown that this aspect of the software development process is important, and the authors tie it in very well.
The best part of this text is that Fitzpatrick and Collins-Sussman, both at Google at the time of writing this book (they have worked with each other at three jobs, and also written three books together), simply tell it like it is, and offer no fluff. Some of the topics that the authors touch are not really found anywhere else to any significant degree, and I hope that a signficant portion of the software development profession has a chance to read what they have to offer at some point in the near future.
Judging by the number and distribution of dog ears resultant from my reading of this text, the strength of the content is consistent throughout, unlike many other texts in this genre which tend to offer good content up-front, but then taper off over the course of the second half. While the reward for this quality will result in this book sitting alongside the best of the best on my bookshelf, it also adds difficulty to the review process, because I do not have the space for a "The New Yorker" magazine review here, so I offer a few quotes that will hopefully increase potential reader interest.
In Chapter 1 ("The Myth of the Genius Programmer"), the authors recount their speaking engagements over the past six years, and point out the distinctive trend in the types of requests they were getting for Google's open source Project Hosting service, which revolved around hiding specific code branches, hiding new open source projects until they are ready to be seen, and deleting code version history.
"The key motif here is insecurity. People are afraid of others seeing and judging their work in progress. In one sense, it's just a part of human nature - nobody likes to be criticized, especially for things that aren't finished. This attitude tipped us off to a trend within software development. Insecurity is actually the symptom of a larger problem." The resultant discussion then leads to their presentation on the foundation that all healthy interaction and collaboration is based (humility, respect, and trust), and point out the following important maxim: "Don't equate your self-worth with your code quality."
In Chapter 2 ("Building an Awesome Team Culture"), the authors discuss an important aspect that is all too often ignored in books of this genre: team culture. "Calm, easygoing cultures built on respect are more vulnerable to disruption by aggressive people than aggressive cultures are vulnerable to disruption from more easygoing people. Easygoing cultures need to be aware of this and not let the aggressive newcomer take over, typically by refusing to engage this person in an aggressive tone. In some cases, one or more of the more senior team members may have to meet the aggressive newcomer head-on to prevent her from harming an easygoing team culture."
In their discussion of the team leader in Chapter 3 ("Every Boat Needs a Captain"), the authors address risk in their presentation of team leader as catalyst. "Risk is a fascinating thing - most humans are terrible at evaluating risk, and most companies try to avoid risk at all costs. As a result of this, the usual modus operandi is to work conservatively and focus on smaller successes even when taking a bigger risk might mean exponentially greater success."
"One thing we often say at Google is that if you try to achieve an impossible goal, there's a good chance you'll fail, but if you fail trying to achive the impossible, you'll most likely accomplish way more than you would have accomplished had you merely attempted something you knew you could complete. A good way to build a culture where risk taking is accepted is to let your team know it's OK to fail."
Chapter 5 ("The Art of Organizational Manipulation") contains one of the many important take-aways from this book. "As an engineer, try to focus your energies on launching products over just about everything else. Shipping things gives you credibility, reputation, and political capital more than just about anything else in a company. Launching your product is a high-visibility event that shows you've accomplished something."
"As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled."