Team Geek

I just finished reading Team Geek by Brian Fitzpatrik ("Fitz") and Ben Collins-Sussman. The subtitle of the book is "A software developer's guide to working well with others", which was pretty much what got me interested in it. I'm generally not a fan of the slew of self-help / laundry-list-of-things-to-do-to-be-better-at-X books out there, but decided to give this one a shot. Especially because the other book I've read by the two of them -- The SVN Redbook -- is arguably one of the best technical manuals out there. Speaking of geek-cred, in addition to writing the manual, both of them were fairly involved in the Subversion project, and that certainly has to mean something.

Image credit: O'Reilly Media

Now, back to the book. It is written explicitly for software developers and tries to target the human element of the process of creating great software. It is structured as a series of "patterns" and "anti-patterns" in that the authors' point of view. It covers some technical essentials (code reviews, means of communication, uninterrupted development time, ...), as well as some purely soft categories, especially for developers who ended up in a management role (trusting your team with responsibility, trying to get out of the way as much as possible, removing obstacles, ...).

Overall, the authors propose a "framework" of humility, respect, trust (HRT) and base most of their patterns and anecdotes on applying it. They argue that these principles shift focus from success of "the genius programmer" to building a great product, as a motivating factor. In any sense, even if you don't completely agree with this framework, the book is definitely an interesting read, and provides a nice discussion on both technical and soft skills. If nothing else, just reading it as a bucket list of good/bad practices might is also interesting.

A few points that caught my attention, in no specific order:

• While the HRT framework that the authors base their advice on certainly sounds nice, it did leave me with a certain utopic feeling. The main premise -- that everyone wants to focus on building a great product, as opposed to their own ego -- could be quite hard to achieve in practice. I  think the authors' experience is slightly biased in this sense, because most of their time was spent on Subversion (where the open-source nature of the project makes sure that contributors really believe in it) or at Google (where the recruiting process explicitly focuses more on people who prefer building things; and where projects are quite technically interesting). But I find it hard to believe it's easy to motivate a 9-to-5 accounting software team in the same way.

• Early on in the book the authors define the bus factor - how many people need to get hit by a bus in order for a project to go bust. Of course they use that to motivate that in a successful project, people should be dispensable (or the bus factor, high) and to discuss keeping documentation, mission statements, etc. For some reason I found the whole notion of the bus factor very amusing. Especially because for my current pet project (XIOSim) it is strictly equal to one. Though that's very close to the number of users, so it should be ok.

• The chapter on software developers who ended up in a management role is quite interesting. Even though I haven't had much experience in that respect (other than our toy robocup team), several "patterns" in this respect resonated with me. In no particular order: letting team members figure things out by themselves, even when you can offer a solution; focusing on removing obstacles; eliminating yourself as an obstacle for trivial things (the authors focus quite a lot on managing vs. leading).

In any case, the book is an interesting read. If you have been in the software development world for a while, chances are you have figured most of the "patterns" out by trial-and-error.  But nevertheless, it is still a lot of fun to read and relate your personal stories to the ones described.