Book Summary - Team Geek: A Software Developer’s Guide to Working Well with Others

Team Geek - A Software Developer’s Guide to Working Well with Others - is a book focusing on the social aspects of software engineering and gives general guidelines on working with other people and leading a team.

Notes

• “Let’s do a reality check. You’re probably not a genius. No offense, of course - we’re sure you’re a very intelligent guy or gal. But do you realize how rare actual geniuses really are? Sure, you write code, and that’s a tricky skill that probably puts you in a bracket above a lot of the human population. But even if you are a genius, it turns out that that’s not enough. Geniuses still make mistakes, and having brilliant ideas and elite programming skills doesn’t guarantee that your software will be a hit. What’s going to make or break your career is how well you collaborate with others.”
• Fail early, fail fast, fail often. Get early feedback, don’t hide your code. Don’t be embarrassed. Don’t personally identify with your code.
• Software Engineering is a team sport. Be humble, respect and trust your team members. This idea - abbreviated HRT- is a recurring theme throughout the entire book.
• Keep meetings short, focused on the agenda, and only invite people that actually benefit from it. For everything else, there’s Ma… use emails to broadcast it to the whole team.
• Paul Graham’s idea of a Maker’s / Manager’s schedule
• ”If you’re working remotely, overcommunicate with your team using every available medium

(e.g., online chat, instant messages, email, video chat, phone calls, etc.) to make sure everyone knows not only that you exist, but also what you’re working on. ”

• Code Comments should be focused on why the code is doing what it’s doing, not what the code is doing.
• “The cost of finding the right person - whether by paying recruiters, paying advertising, or pounding the pavement for references - pales in comparison to the cost of dealing with an employee you never should have hired in the first place. This cost manifests itself in lost team productivity, team stress, time spent managing the employee up or out, and the paperwork and stress involved in firing the employee.”
• People are the happiest and most productive if their motivation is mostly intrinsic instead of extrinsic (e.g., throw piles of cash at them), Intrinsic motivation can be increased by giving people three things: Autonomy, Mastery, and Purpose.
• Dealing with poisonous people / trolls: Stay calm, ignore the hate, focus on the technical aspect, respond with niceness. They will either leave or calm down themselves.
• If you don’t take risks you ‘ll fail less, but will have fewer big successes along the way. “If you don’t fail at least once a year, you’re not taking enough risks.”
• Don’t be afraid to talk to your manager to address eventual problems early on and keep them updated on what you’re doing.
• “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’re accomplishing 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.”
• If you e-mail an executive or another high level person that you never met before, don’t make the mistake to ramble. They are busy people. Keep it short, 3 bullet points and a call to action.
• “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. That is my career strategy.” - Chade-Meng Tan
• Look at your UI/UX from your user’s perspective who will not be as technical competent as you. How hard is it to get going when first starting out with your software. Is he overwhelmed by too many options or has to create an account first to even use it?
• Your software should feel fast and solve a specific problem well instead of many problems badly.

Personal opinion

It’s a nice quick read with tips on working well in a team and how to handle conflicts, whereas most of the advice is just common sense in my opinion. Don’t expect this book to blow your mind or to learn a lot of new things if you ‘ve already read other books on human psychology / social aspects before. As they say in their epilogue, most of the advice is actually not specific to software engineering, and can be generalized to pretty much any social setting.
The authors both worked for Google and throw in a personal anecdote every now and then or show some amusing illustrations underpinning what ‘s being said. However, the praising sometimes goes over the top and feels like a glorification of Google:

“In contrast, during Fitz’s first week at Google he found a typo in Gmail. He

opened the source code, fixed the typo, then emailed a patch to the Gmail team, who thanked him heartily. Big companies don’t always have to have friction!”