How to work in a software engineering team

This post is a summary of Chapter 2, "How to work well in teams", from Software Engineering at Google.

Software development is a team endeavor. To succeed in a team, you must reorganize your behavior around the core principles of humility, respect, and trust. What makes or breaks your career is how well you collaborate with others.

Solicit feedback early

You're not a genius who can vanish into a cave for weeks or months, slaving away at a perfect implementation of your idea, and then unleash your software to the world. Even if you are a genius, you still make mistakes, and having brilliant ideas and elite software development skills doesn't guarantee your software will be a hit.

Many programmers are afraid to share their work early because it means peers will see their mistakes and know the author of the code is not a genius. The natural reaction is to hide in a cave, work, work, work, and then polish, polish, polish.

Hiding code is harmful. You don't know if you're on right track without showing it to others. You easily make fundamental design mistakes early on. You risk reinventing wheels. The more feedback you solicit early on, the lower the risk of wasted work.

Fail early, fail fast, fail often.

Sharing knowledge and know-how increases the bus factor: the number of people that need to get hit by a bus before your project is doomed. People in your team might move away, leave the company, and take sick leave.

It's better to be one part of a successful project than the critical part of a failed project.

Working with other people directly increases the collective wisdom behind the effort. The fastest way to solve roadblocks is having a couple of peers look over your shoulder and have them tell you how you goofed. This is why teams sit together and do pair programming in software engineering companies.

Programming is hard. Software engineering is even harder. You need that second pair of eyes.

Always take small steps

Programmers work best in tight feedback loops: write a new function, compile. Add a test, compile. Refactor code, compile. This is how we keep code quality high and make sure our software is evolving correctly, bit by bit.

Remember the DevOps philosophy:

• Get feedback as early as possible
• Test as early as possible
• Think about security and production environments as early as possible

The earlier we find a problem, the cheaper it is to fix it. This applies to projects as well. Tight feedback loop and many eyes make sure your project stays relevant and on track.

Working alone is inherently riskier than working with others. Your primary concern should be wasting huge swaths of your time toiling away on the wrong thing. Don't become another statistic.

Team rules

Software engineering is a team endeavor. You need to work with other people.

Share your vision. Divide the labor. Learn from others. Create a brilliant team.

Healthy social interaction and collaboration are based on three pillars:

Humility

You're not the center of the universe. You fail like everyone else. You're open to self-improvement.

Respect

You genuinely care about the people your work with. You treat others kindly and appreciate their abilities and accomplishments.

Trust

You trust others are competent and will do the right thing. You're OK letting others drive when appropriate.

Human relationships outlast projects. When you've got richer relationships with your coworkers, they are more willing to go the extra mile when you need them.

Lose the ego

Do you always feel like you need to have the first and last word on every subject? Do you feel the need to comment on every detail in a proposal or discussion? Do you know somebody who does these things? Nobody wants to work with someone who consistently behaves like they're the most important person in the room.

There's nothing wrong with self-confidence, but don't come off like a know-it-all. Try to go for a collective ego instead: build a team that takes pride in its accomplishments.

Learn to give criticism. Understand the difference between a constructive criticism of someone's creative output and flat-out assault against their character. Learn to respect your peers and give constructive criticism politely. Choose tactful, helpful phrasing.

A good way to give criticism in code reviews can be, for example, like this: "Hey, I'm confused by the control flow in this section here. I wonder if the xyzzy code pattern might make this clearer and easier to maintain?" This makes the question about you: you're having trouble understanding. The suggestion is offered as a way to clarify things for poor little you and to help the long-term sustainability goals of the project. The discussion stays on the code itself.

Learn to take criticism. Trust that the other person has your best interests and those of your project at heart. Your self-worth shouldn't be connected to the code you write.

You are not your code.

Failure is an option. If you're not failing every now and then, you're not being innovative enough or taking enough risks. Failure is a golden opportunity to learn and improve for the next go-around. By the same token, if you do the same thing over and over and keep failing, it's not failure, it's incompetence.

Be open to influence. The more open you are to influence, the more you are able to influence. It's OK for someone else to change your mind. To be heard, you need to listen. Do not make decisions and put your stake to the ground before listening to others.

The more vulnerable you are, the stronger you are. Expression of vulnerability is an outward show of humility: it demonstrates accountability and willingness to take responsibility, and that you trust others' opinions. Sometimes the best you can say is, "I don't know". You don't need to be on the defensive: you and your collaborators have the same goal.

Be Googley

Googleyness is defined as a set of attributes and behaviors that represent strong leadership and exemplify humility, respect, and trust. A Googley person is someone who:

Thrives in ambiguity: can deal with conflicting messages, build consensus, and make progress against a dynamic problem.

Values feedback: has humility to receive and give feedback gracefully.

Challenges status quo: is able to set ambitious goals and pursue them even when there might be resistance from others.

Puts the user first: has empathy and respect for the users and pursues actions that are in their best interests.

Cares about the team: has empathy and respect for coworkers and actively works to help them.

Does the right thing: has a strong sense of ethics, willing to make difficult and inconvenient decisions to protect the integrity of the team and product.

TL;DR

• Do not hide code
• Solicit feedback early
• Take small steps
• Build on humility, respect, and trust
• Lose the ego
• Learn to give and take criticism
• Listen to be heard