7 of 7 people found the following review helpful
on December 31, 2013
Strengths: Geek "mentality" (hide my code until it's perfect) is summed up well, the team experience and culture are explained throughout with useful metaphors.
Weaknesses: Much advice is based on utopic premises, i.e., oriented towards large open source projects or Google (where candidates with dysfunctional team culture are theoretically weeded out during job interviews). It would be good if there was more realistic advice that applies to the 99% other software companies, e.g., where customers are government, military, etc. and companies are small businesses operating outside of silicon valley without the biggest talent pool.
5 of 5 people found the following review helpful
People are a giant pile of intermittent bugs, say the authors. People are messy and difficult and hard to apply logic too. If you believe that and are a software engineer (or know one) then this book is for you. The authors then proceed to solve problems in a funny, logical, and concise way.
They start out using many arguments to convince us that software development is a team sport, e.g. you must get feedback early on; fail early; fail fast; fail often; your team's hit by a bus factor, genius myth, tight feedback loops - never do 50,000 lines of virgin code.
The underlying model for making teams work is what they call the three pillars of humility, respect, and trust. The rest of the book uses the three pillars and addresses various challenges of software. The chapters are:
- How to build an awesome team culture
- Every team needs a captain
- Dealing with difficult people
- The art of organizational manipulation
- Users are people too
Each chapter has humor, anecdotes, clever logic, pictures, and charts to prove their points, here are some examples:
- Serious - when to fire someone
- Helpful - how to write a complaint letter
- Funny - grandma is a user, her Mac and pencil sharpener have a relationship
I enjoyed this! I wish I had this book thirty years ago, when I was a practicing software engineer. I am giving this book as gifts for the all the amazing and talented software people in my life.
3 of 3 people found the following review helpful
You'd think that in IT, the most important component of a team would be its technical prowess. Wrong... it's the ability to work with each other. Team Geek: A Software Developer's Guide to Working Well with Others by Brian W. Fitzpatrick and Ben Collins-Sussman make the case that respect, personality, and team culture is just as important (if not more so) than the ability to come up with the "perfect" code that passes geek inspection. After 30+ years in the industry, I have to agree...
Introduction; The Myth of the Genius Programmer; Building an Awesome Team Culture; Every Boat Needs a Captain; Dealing with Poisonous People; The Art of Organizational Manipulation; Users Are People, Too; Epilogue; Further Reading; Index
I don't think this book would be nearly as good if it were written by an "expert" in organizational team dynamics (or some other vaguely worded title). IT people are... different. Fitzpatrick and Collins-Sussman live in that world, so their advice is based on real-world experience. The style and language of the writing is perfect for the audience, and everything is grounded in practical terms with real-world examples of teams that work on well-known projects.
One of the points that resonated with me was the insistence that culture *must* be considered the primary driver for the direction of and choices during projects. There are a number of examples where teams, especially open-source teams, were faced with individuals who wanted to inject their own ideas into the mix. That's a good thing, unless it's done in such a way that goes against the grain of how the team functions and what they value. It may be tempting to take their code and overlook their personality. But a single attitude can destroy a team far faster than you'd expect, and it's not worth making the exception. Team Geek reinforces the reasons why establishing *and* protecting a culture is worth the effort.
While it may not be a "sexy" read in terms of learning a new coding trick or hardware setting, Team Geek may be the one read that keeps you sane and happy over the life of your career. This is a book that I'd strongly recommended...
Obtained From: Publisher
2 of 2 people found the following review helpful
on July 11, 2013
As a software developer and a team member, I know how difficult is dealing with people in
respect of writing code sitting comfortably at my desk, so I am usually very skeptical of
technical books that promise to teach you how to deal with this "human stuff" like it was a
programming language. I had the pleasure to meet Brian Fitzpatrick at a conference and I was
very impressed by his brilliant personality and his fascinating personal story and this somehow
convinced me on reading this book. And I was not disappointed because since the first pages
you have the strong feeling you're reading something written by developers, so you mostly and
easily get the point of the authors.
The book is full of good advices, best practices and even a list of antipatterns you better avoid to
apply to your team. Some of the advices derives from common sense and you or your team
likely apply them already, nevertheless it was very useful realizing how important some
behaviours, habits or attitudes me and my team already have but wrongly take for granted, or
worst, miss to improve.
The authors keep saying a sort of mantra during the book: HRT, an acronym that stands for
Humility, Respect and Trust. Apply this mantra and you will soon become an excellent team
player, whatever your job is. For this reason in particular I'll do my best to make my colleagues
read this book.
5 of 6 people found the following review helpful
on July 13, 2012
A handy guide of best practices for all stakeholders of a project. Revolves around simple, commonly accepted principles of being a good human being first with intention of delivering something useful for others.
Recipe for channeling individual energies towards achieving the common goals, and increasing productivity by reducing friction.
This book is applicable not just for software developers; but to any group of individuals having supposedly/ intended common goals, and having a potential for conflicts about how to achieve those while also guarding individual interests.
It's déjà vu for experienced (> 7 years) folks. Listing of all the best practices in an organized manner in one place is the value of this book.
Equivalent of the books 'Code complete', and 'Writing solid code' for nurturing great teams. Those two book had profound impact early in my career. I wish this book was available way earlier for me and to those I worked with so far. I would've named this book 'Team complete' or 'Developing productive teams'.
Speaking in the software metaphor, I wish I could write a country specific localization of this book. While most of the ideas expressed are valid, some nuances of recommendations made do vary across world cultures, company type, and regions.
Meaningful cross references provided at the end of each chapter. Good that they are hyperlinked in the soft copy form.
Kindle edition likes: digital index of topics at the end of the book makes post-reading, future reference a charm. Also, hyperlinked cross-references provided at the end of each chapter.
Gripes: two-column view was not available with Kindle for PC, though the reader supports it for other books.
Glad that I read it: assuring that I was not alone to have some special experiences while doing productive work with people, that these are patterns, and that many of the antidotes have worked well for others, too. People with structured minds always like patterns, so that those can be tackled with some predictability ;-)
2 of 2 people found the following review helpful
on July 31, 2012
Brian Fitzpatrick leads Google's Data Liberation Front and Transparency Engineering teams.Ben Collins-Sussman is one of the founding developers of SVN and now manages the engeneering team for the Google Affiliate Network.
Both have a lot of experience with Open Source Projects.
The Book has a clearly defined goal - to help programmers become more effective
and efficient at creating software by improving their ability to
understand, communicate with, and collaborate with other people.
And that is the essence of this book. It explains why each relationship (not only related to Software projects) should be based on Humility, Respect and Trust (HRT).
The message of the book also applies to the relationship between team mates, team leader and team and above all to the relationship with end users.
The book gives useful tips on how to cope with complicated team mates and how managers should lead their team.
Brian and Ben explain why a team culture is so important and should be protected right from the start.
Last but not least the reader gets some tips on how to promote himself better within his company.
I really enjoyed reading this book.
2 of 2 people found the following review helpful
on July 24, 2012
I stumbled upon this book while walking the Expo Hall at OSCON 2012: Brian Fitzpatrick and Ben Collins-Sussman were at the O'Reilly booth signing their new book, and I jumped at the chance to check it out. What a great decision.
This is a short, entertainingly written, guide to working in, and leading, teams. Sure there's a geeky theme to the examples, but it's generally just good, practical, advice. Coming in at just 160 pages this is the kind of book I'd like to see every new hire at Return Path get: Let's all start knowing that we'll be working within the same framework of humility, respect and trust.
1 of 1 people found the following review helpful
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."
1 of 1 people found the following review helpful
on January 2, 2013
The bottom like for this book is: If you're a software engineer who wants to do great things, enjoy your work, and work on a super team, read this book! I've been going through a lot of books on the subject of technical leadership, soft skills for engineers, creating great development teams, and so on. I've found a few that I thought were quite good and they either have become or will become part of the material for my software engineering, and other software engineering based courses. But this book trumps them all so far. If you only read one book in the next year on this topic, read this book.
The authors, Ben and Fitz, work at Google. They've held several positions with Google and other companies. They have been associated with the Subversion open source project for years. In short, they're real engineers who know how to build and shop software. They also have a great insight into what it takes to build a great team, how to keep it together and growing, and how individuals can become a part of such teams.
Ben and Fitz have clearly experienced many of the same types of organizations and personalities that I've encountered over the course of my industrial career.When I read an early section, "The Contents of this Book are not Taught in School," I was hooked. They say "At press time, we're not aware of any curriculum that actually teaches you how to communicate and collaborate in a team or a company. Sure, most students are required to participate in a group project at some point in their academic career, but there's a big difference between teaching someone how to successfully work with another person and throwing him into a situation of forced collaboration. Most students end up jaded by the experience." Well, if you've been in one of my software engineering classes, you know this isn't true. That's exactly what I try to teach and pretty much the way I do it. These two and I share a similar mind set.
The book describes several types of people, and provides stories of how to get these different types working well with a team while maintaining a team's culture. They have great stories that I was able to identify with. They don't try to mold these stories into patterns. They just tell it like it is--and it works for me. I finished the book in a few hours of enjoyable reading.
Ben and Fitz have had the opportunity, it seems, to have been able to choose the types of teams they work with as well as the type of companies that they've been employed by. Not everyone has that luxury. What the authors think dysfunctional companies and organizations are simply the norm for a lot of folks. Don't let that put you off if you're in one of those type of organizations. You'll find good advice on how to navigate through the bureaucracies and get things done.
If you are a software engineer--whether you're starting out or have been at it for years--read this book if you want to be better at what you do and if you want to get more satisfaction from your job. If you don't get anything out of it, you are either the perfect software engineer (which is about as real as the Easter Bunny) or you're in the wrong profession and should probably look for something else to do. The time spent reading this book will yield many rewards.
1 of 1 people found the following review helpful
One of the stock phrases people use to deride their place of employment is to say, "It is all politics there." The phrase is used to claim that more time and effort is spent in human interactions with the goal seeking advantage rather than actual work. While this of course does happen, the reality is that the modern world of software development is often more an exercise in effective human interaction than it is the writing of quality code. The days of the single "cowboy coder" slogging away in isolation and creating a brilliantly effective program are past. All programs of any size are a collaborative effort among many people, often not even in the same country, much less in the same building.
Politics can be defined as the art of leadership of the governed via their consent, input and directing their function, which is what a software team leader must do. The employees give their consent by remaining employed there and doing the work, their input is their output and the questions they pose concerning what is expected of them. The leader must then effectively and fairly parcel out the tasks, provide benchmarks of achievement, encourage the slackers and praise the achievers.
The leader and the led must both work towards the desired goal, adapting their behavior and learning when to challenge and when to submit. The authors of this book give some very sound advice regarding how to do this, including how to accept failure, both personal and among your employees. The advice is of course sound and effective, it is also a bit unrealistic. While it is true that the most effective people are those that intelligently speak their mind and are not afraid to fail; many people find it difficult to follow that path.
When a person has a family, mortgage and car payments and the unemployment rate is over 8%, one must be very brave and confident to risk displeasure and failure that could lead to loss of employment. It is one of the most destructive features of economic downturns in that it turns many people into sycophants, unwilling to challenge higher powers when they should be challenged. This leads to the introduction of inefficiencies as well as their being baked into the process, leading to a decline in innovation and lowered improvement in economic productivity.
Working well with others means having mutual respect, but it also means standing up for principles when it is necessary. This is an excellent book in describing the sociology of software development and how to drive it in the right direction. I strongly recommend it for all members of development teams, for the directed and gentle manipulation of people is how the business of software creation is done.