How to Work Well On Teams
Overview
This week’s chapter in the Software Engineering at Google book focuses on teamwork. Working well in teams results in the development of better software. This chapter focuses on humility, respect, and trust as it discusses the best practices for working with others. The best software developers have mastered the art of teamwork and collaboration. In contrast with this, Brian Fitzpatrick highlights requests he received when building Google’s first open-source software platform, “Can you make it possible to create open source projects that start out hidden to the world and then are revealed when they’re ready?”
Activity: Think about all of the bugs in yourself as a software developer.
Summary
Teamwork is definitely one of the most overlooked aspects of software engineering. Strong teams not only create better software but also foster a more dynamic, supportive environment that helps developers grow and solve complex problems more efficiently. This chapter contrasts the “Genius Myth,” which idolizes individual achievements while neglecting collective efforts, with the “Bus Factor,” which aims to reduce a project’s dependence on a single individual.
Working alone increases the risk of mistakes, slows progress, and isolates knowledge, making collaboration essential for success. Throughout the article, Fitzpatrick stresses that even though individual focus is necessary for coding, frequent communication with the team is critical. By embracing teamwork and avoiding the tendency to hide work, software engineers can maximize their potential and avoid wasting time on misguided efforts. A genius myth is when someone thinks it is bad to share their work before they are done and ready. However that is not the case. Usually people feel scared and insecure to share their work early on due to making mistakes. Making mistakes is what makes you a genius. SE Radio 609: Hyrum Wright on Software Engineering at Google (00:14:24), “A lot of engineers, myself included, a lot of early career engineers specifically can struggle with getting concrete and sometimes critical feedback on their code or their designs. It’s not that you’re a bad person, it’s that how can we help you improve your system? And the reaction to that is oftentimes we tend to hide things; we tend to keep it hidden until we think that we have the best product.” While independent work may seem appealing, it can lead to unnecessary failure, missed opportunities for feedback, and slower progress. The “Bus Factor” stresses the need for shared knowledge to ensure a project’s survival if key contributors become unavailable. If Professor Kapfhammer gets hit by a bus, what would we do? How would we make new releases? How would his projects be maintained? This section draws analogies to rapid feedback in programming, advocating for teamwork to quickly detect flaws and adapt to changes. Earlier problems are in fact “cheaper” to solve and addressing them sooner minimizes the impact on overall project progress. Collaboration not only reduces risk but also accelerates problem-solving, ensuring that projects stay on track and are resilient to unexpected disruptions. Activity: What would our class do if we lost access to Professor Kapfhammer and/or his laptop? If we lost access to Professor Kapfhammer’s laptop we would not be able to push our work since we need his login to PyPI. This stresses the “Bus Factor” where it would be better to have an automated way to deploy our system. However, if you can push from any computer, then people might start pushing when we are not ready to actually deploy. What is the best strategy to ensure that we can effectively deploy our system? These pillars represent the non-negotiables when it comes to developing software in a team environment. An important way to learn from a mistake you make is to take note of your failures. You should not just blame people for their failures but you should be able to explain what you got out of the failure and then what you are going to do with experience now. Usually, you write a post-mortem document to go over the failure it includes: Activity: A person does not write a comment on code. People in the group start guessing what the code meant. In the end, it causes bigger problems. Go through the list above to think about a simple post-mortem. First you would explain that the there was code with no comment. Also state that people started just taking guesses on the what it meant. Then you would state what got you to discover it which was it was causing bigger problems and to solve it figure out what the code really means and put a comment. Next you would do damage control and figure out what problem came from this. Then to not have this happen again make sure each person writes code comments for their code and that other people can explain it. In the end you learn that writing code comments is very important so that bigger problems do not develop. It is also important to not point fingers and say that person has to fix it. You need to work as a group to fix it and make sure it does not happen again. In the end of this chapter it talks about being “Googley”. At first it had a meaning but over time it got confused. As a result, Google made a set definition for what it meant. It means:The Genius Myth
The Bus Factor
Click to Expand for the Answer
Three Pillars of Social Interaction
Blameless Post-Mortem Culture
Click to Expand for the Answer
Being Googley
Key Takeaways
The most important takeaway from this chapter is that the best software engineers are the people who can work well with others. The “Genius Myth” and “Bus Factor” both demonstrate the importance of shared work and collaboration. By taking note of your failures as well, you can ensure you are constantly learning from your mistakes. All while considering these tips, it is important to remain respectful and follow the three pillars of social interaction.