Book: SE@Google Ch 2: How to Work Well on Teams

[ckcherry23]

Book: Software Engineering at Google Chapter: 2. How to Work Well on Teams

Summary

TL;DRs

• Software engineering is a team endeavour.
• What will make or break your career is how well you collaborate with others.
• Be aware of the trade-offs of working in isolation.
• Understand the personalities and working styles of your team to improve productivity.
• The 3 pillars of social interaction are humility, respect and trust.

Summary

1. The Genius Myth
   • Many programmers love to idolize lone "genius" programmers who create groundbreaking software.
   • Hence, they are afraid to share work in the early stages because others will see their mistakes and know the code's author is not a genius.
   • However, most successful software, like Linux and Unix, is the result of teamwork and collaboration by thousands of smart people, not just one person.
2. It Hurts to Hide Your Code
   • Early detection: Early feedback and collaboration help you catch mistakes early and avoid reinventing the wheel.
   • The Bus Factor: The "bus factor" is the number of people who need to get hit by a bus (figuratively) before your project is completely doomed. Sharing knowledge and working in teams increases the bus factor and gives the project a better chance to thrive.
   • Pace of progress: Rapid feedback loops at the project level help projects stay relevant to changing requirements.
3. The Three Pillars of Social Interaction
   • Pillar 1 - Humility: Be open to self-improvement.
   • Pillar 2 - Respect: Genuinely care about others you work with.
   • Pillar 3 - Trust: Believe others are competent and will do the right thing.
   • A root-cause analysis of almost any social conflict would trace back to a lack of these 3 pillars.
   • Some tips to apply these ideas in real-life situations:
   • Lose the ego: Don't come across as arrogant. Avoid dominating discussions and respect others' opinions.
   • Give and take criticism well: Focus on improving the project, not attacking someone's skills. Be open to feedback.
   • Learn from your mistakes: Practice blameless post-mortem culture to understand the root cause of your failures and improve.
   • Practice patience: Be patient with colleagues who have different working styles. Find ways to collaborate effectively despite these differences.
   • Be open to influence: Listen to others' ideas and be willing to change your mind when presented with new information.
   • Show vulnerability: It's okay to admit you don't know something. Vulnerability builds trust and respect among teammates.

Relevance to NUS-OSS and RepoSense

1. Open draft PRs with confidence Often, I've found myself and others hesitant to open draft PRs, and the reason could be fear of judgment for our code with mistakes. However, this could cause more harm in the long run, as any issues cannot be detected early and we duplicate unnecessary work. Letting go of the "Genius Myth" can help us be less insecure about our code and more open to collaboration.
2. Be open to feedback Working with NUS-OSS projects requires that we accept criticism well. We need to trust that the reviewer has our best intentions at heart and does not think we are "incompetent".
3. Give useful code reviews Give constructive feedback with tactful and helpful phrasing - which takes practice to develop. Be patient with contributors who have different working styles and be open to influence from others, the contributor possibly knows more about the problem than you, as they worked on it first-hand.
4. Improve processes with blameless post-mortems When something goes wrong (for example, a serious bug pushed to production), figure out what can be done to avoid it in the future instead of finding someone to blame it on.
5. Increase bus factor We should share knowledge with more people on our team with the help of good documentation to ensure our projects continue, especially because contributors come and go for NUS-OSS projects.

Random trivia I learned while reading

• X, the moonshot factory (formerly Google X)
  • A division of Google that works on “moonshots” like self-driving cars and internet access delivered by balloons —failure is deliberately built into its incentive system.
• There was a time when "Googleyness" was not even defined but was used as an informal test for culture fit when hiring, which led to unconscious bias as interviewers tried to find candidates "just like themselves".