[book review] Team Geek
I really wanted to write a review of “Team Geek.” I wanted to do it, but I struggled for a few days. I didn’t even know how to start such a review. The book is filled with good ideas, but nothing surprising. Nothing that could be called revolutionary.
The book is written quite well, and that is just one more problem. It keeps you in suspense. You keep reading it and waiting for that one gem of wisdom. It is not there.
On the other hand, there is nothing outrageously wrong about this book. I can’t complain about it. I can’t tell anything good about it either. The book is just disgustingly average.
I had a communication problem last week. I got terribly misunderstood, and I wanted to find something which can help me avoid such situations. Not in this book.
I started thinking that maybe “Team Geek” is not for me. Fortunately, the authors described the desired audience and even wrote their mission statement. The authors claim the book is written for software developers who work in a team with other programmers and enjoy software engineering. That’s me. So why am I so disappointed?
First of all, a part of the book seems to be written for people who work on an open-source project. It has chapters about effective usage of mailing lists, using online chats and cooperation in a distributed team. It is so similar to a group of software engineers working in a company, yet so different in practice. There are also chapters about being an efficient team in a company and creating a company/team culture. So maybe the book is not only for open-source developers?
Who should read the book? I think that is the problem. The authors tried to write something that is good for everyone, so the final result is just “meh”… for everyone.
I really tried to recall one example from this book, and I can’t do it. I don’t remember anything worth mentioning. I can’t describe the content, so I must focus on my feelings. In particular, the feeling of indifference.
I can’t say I wasted time reading this book. I did not. I enjoyed reading it, but I did not learn anything. I expected to learn something because of the mission statement written by the authors: “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.” I can’t say the goal has been achieved. I did not learn anything. I don’t feel inspired to try something new. I have already forgotten most of the book.
I still think I can’t say that you should not read this book. It would not be fair. That is a huge problem for me. A book worth reading should be polarizing. It should make you either love or hate the author.
I believe there are people for whom it will be a life-changing book. After all, it has a lot of good reviews on Amazon. I am just not one of the people who benefit from reading it.
In my opinion, “Team Geek” deserves a 3-star review on Amazon. It is negligible. You can read it, but why would you do it? There are better books you can buy for the same price and “life is too short to read a bad book.” Maybe “Team Geek” is not a bad book but is not a good book either.
Did you enjoy reading this article?
Would you like to learn more about leveraging AI to drive growth and innovation, software craft in data engineering, and MLOps?
Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!
You may also like
- MLOps engineer by day
- AI and data engineering consultant by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz
- Mastodon: @email@example.com