Everybody says that software development is a team sport – and they’re right! When young, inexperienced, developer (i.e. like me) starts working for the first time in this profession (no matter if it’s small startup or big corporation), he quickly discovers that when he plays well with other developers in his team (and not only them!), his work is of better quality and quickly achieved. After that he starts to wonder how this effect can be sustained or even enlarged. On the other hand – when we enter some kind of toxic environment, most common thought is how to remove this toxicity from team (or maybe project? client? company?) and work more efficiently and in more pleasant surroundings. And with these thoughts we start searching for an answer. First our friends and coworkers, then Internet and finally we find books which title says it’s ‘A Software Developer’s Guide to Working Well with Other’. Sounds perfectly, right? But will we find some answers there? In my humble opinion – not so much.
From the beginning, this book mission statement is very clear: “The goal of this book is to help programmers become more effective and efficient at creating software by improving their ability to understand, communicate with, and collaborate with other people”. With goal so clear and precise you could ask what’s wrong with it? For me it’s target group. Team collaboration is so vast and complex that (in my opinion) can’t be covered widely (and properly) enough on 158 small pages. Playing well with other teammates often means different thing, depending on our position. Because “Team Geek” tries to describe potential problems and solutions for people in broad spectrum of employes, none of those are covered sufficiently.
At this time you probably think that I hated this book, but that’s not the truth. When I started reading book written by two widely known Googlers and open source projects contributors, with years of experience on different positions, I suspect that this book will be at least as good as “Rework” from guys from 37Signals. Even more, I expected that I will read it breathlessly in one night. But unfortunately that was not the case. Fortunately that doesn’t means I hadn’t learned something new.
There are few topics which were explained perfectly and just for them reading this book is not a time waste. The first chapter (“The Myth of the Genius Programmer”) should be required reading in college! It describes common problems of inexperienced programmers like desire to work in separation from rest of the world on their “open source” project or idealization of known people instead of teams their work with. Before this book I never seen any article about those problems and it hit me with like a Thors hammer. Losing our own ego, being patient, humble and open for criticism is just a tip of the iceberg.
After reading this book twice I can recommend parts of this book (chapters 1, 2 and 4) for everybody and whole book only for those who have a lot of spare time and forbearance.
Review author: Łukasz Rybka
Mark: 3.5 / 5