Team Geek: A Software Developer’s Guide to Working Well with Others By Brian Fitzpatrick and Ben Collins-Sussman O’Reilly Media, £18.99
Of all the stereotypes about those who work in IT, social ineptitude in the office is perhaps the most enduring. The most successful programmers offer little evidence to the contrary. Bill Gates’s approach to management was once described as “armed truce”; Mark Zuckerberg’s success at diffusing conflicts can probably be measured in lawsuits.
So this primer in office survival skills might be in order. In Team Geek, Brian Fitzpatrick and Ben Collins-Sussman, both with years of experience at Google, seek to deliver it. Their target is not the next Silicon Valley genius but the everyday software developer who is now as essential as air-conditioning to most business.
The authors’ approach is to patronise the hapless nerds as much as console them. People don’t have flaws, they have “bugs”. These bugs mean some people are “often annoying to interface with”. In dealing with them, “do not underestimate the bandwidth of a face-to-face conversation”.
Strip the language away and it turns out that software developers face a familiar office tension. They are creative people trying to pursue the path of artistic purity. “We’re obsessed with truth,” the authors modestly proclaim.
But paths of purity often diverge, not least from an employer’s route to profit.
This leads to a general exasperation at the uninitiated. “Communication isn’t typically the strong point of most engineers, who would rather spend an afternoon with a (predictable, logical) compiler than spend three minutes with a (unpredictable, emotional) human being.” (Note for the uninitiated: “compilers” are programs that developers use.)
So how can techies and non-techies get along? The authors endorse the strategy of Chade-Meng Tan, a former Google engineer whose current job title is “Jolly Good Fellow” and who acts as a sort of life coach for the company: “I do the Right Thing for Google and the world, and then I sit back and wait to get fired. If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win.”
This stance sits uneasily with the more mainstream advice in Team Geek. The authors stress the need for a culture of trust and for different designers to cast off their egos and write a shared mission statement. Indeed, most of the authors’ advice is about engaging with the corporate bureaucracy, not ignoring it. However good you are as a developer, working in isolation simply increases the chances of making mistakes. On every project, bear in mind the bus factor – “the number of people that need to get hit by a bus before your project is completely doomed”.
At one point, the authors tell their audience of introverts that “you’re going to accidentally trip and fall into a leadership position”. When that happens, make sure no more than half your team’s time is taken up with defensive work such as correcting mistakes. Otherwise there won’t be enough glitzy output to impress superiors.
Such advice is easily digested but perhaps also easily forgotten. Only occasionally do the authors really engage with the nuances of the digital office. Colleagues may increasingly interact on chat functions, excluding other members of the group. So they suggest making it clear that only discussions that occur in shared emails will count as binding.
Developers are also warned to be wary of attaching their names to the pieces of code that they write as doing so only risks conflicts. Credit should be sought at the project level instead.
It is a shame that most of Team Geek treats developers as if they have never actually met another human being. The book may be scratching at a real problem, but some readers will find it a little irritating.