More on this book
Community
Kindle Notes & Highlights
Started reading
August 4, 2020
Nobody wants to work with someone who consistently behaves like they’re the most important person in the room.
rather than worrying about whether you’re personally awesome, try to build a sense of team accomplishment and group pride.
In a professional software engineering environment, criticism is almost never personal — it’s usually just part of the process of making a better project. The trick is to make sure you (and those around you) understand the difference between a constructive criticism of someone’s creative output and a flat-out assault against someone’s character.
In the same way, your self-worth shouldn’t be connected to the code you write — or any creative project you build. To repeat ourselves: you are not your code. Say that over and over. You are not what you make.
At Google, one of our favorite mottos is that “Failure is an option.” It’s widely recognized that if you’re not failing now and then, you’re not being innovative enough or taking enough risks. Failure is viewed as a golden opportunity to learn and improve for the next go-around.
A proper postmortem should always contain an explanation of what was learned and what is going to change as a result of the learning experience. Then, make sure that the postmortem is readily accessible and that the team really follows through on the proposed changes. Properly documenting failures also makes it easier for other people (present and future) to know what happened and avoid repeating history.
The more open you are to influence, the more you are able to influence; the more vulnerable you are, the stronger you appear.
Admitting that you’ve made a mistake or you’re simply out of your league can increase your status over the long run. In fact, the willingness to express vulnerability is an outward show of humility, it demonstrates accountability and the willingness to take responsibility, and it’s a signal that you trust others’ opinions. In return, people end up respecting your honesty and strength.
When you’re writing software, however, you don’t need to be continually on the defensive — your teammates are collaborators, not competitors.
Be aware of the trade-offs of working in isolation.
Acknowledge the amount of time that you and your team spend communicating and in interpersonal conflict. A small investment in understanding personalities and working styles of yourself and others can go a long way toward improving productivity.
Your organization understands your problem domain better than some random person on the internet; your organization should be able to answer most of its own questions. To achieve that, you need both experts who know the answers to those questions and mechanisms to distribute their knowledge,
Sharing expertise across an organization is not an easy task. Without a strong culture of learning, challenges can emerge.
Information fragmentation Each island has an incomplete picture of the bigger whole. Information duplication Each island has reinvented its own way of doing something. Information skew Each island has its own ways of doing the same thing, and these might or might not conflict.
Software engineering can be defined as the multiperson development of multiversion programs.
People are at the core of software engineering: code is an important output but only a small part of building a product. Crucially, code does not emerge spontaneously out of nothing, and neither does expertise.
Every expert was once a novice: an organization’s success depends on growing and ...
This highlight has been truncated due to consecutive passage length restrictions.
Tribal and written knowledge complement each other. Even a perfectly expert team with perfect documentation needs to communicate with one another, coordinate with other teams, and adapt their strategies over time.
Train, focus on learning and growth, and build your own stable of experts: there is no such thing as too much engineering expertise.
An enormous part of learning is being able to try things and feeling safe to fail. In a healthy environment, people feel comfortable asking questions, being wrong, and learning new things.
indeed, our research has shown that psychological safety is the most important part of an effective team.
If you take away only a single thing from this chapter, it is this: always be learning; always be asking questions.
It’s especially critical for those in leadership roles to model this behavior: it’s important not to mistakenly equate “seniority” with “knowing everything.” In fact, the more you know, the more you know you don’t know
Learning is not just about understanding new things; it also includes developing an understanding of the decisions behind the design and implementation of existing things.
what questions should you be asking? Consider the principle of “Chesterson’s fence”: before removing or changing something, first understand why it’s there. In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more
...more
Many Google style guides explicitly include context to help readers understand the rationale behind the style guidelines instead of just memorizing a list of arbitrary rules. More subtly, understanding the rationale behind a given guideline allows authors to make informed decisions about when the guideline shouldn’t apply or whether the guideline needs updating.
Expertise is a multidimensional vector of what you know: everyone has varying levels of expertise across different areas.
The first time you learn something is the best time to see ways that the existing documentation and training materials can be improved.
At Google, engineers feel empowered to update documentation regardless of who owns it — and we often do — even if the fix is as small as correcting a typo. This level of community upkeep increased notably with the introduction of g3doc,8 which made it much easier for Googlers to find a documentation owner to review their suggestion.
As your proficiency grows, write your own documentation and update existing docs. For example, if you set up a new development flow, document the steps. You can then make it easier for others to follow in your path by pointing them to your document.
Suppose that team members always ask you for help debugging certain kinds of production failures. Documenting your procedures requires an upfront investment of time, but after that work is done, you can save time in the future by pointing team members to the documentation and providing hands-on help only when needed.
Writing documentation also helps your team and organization scale. First, the information in the documentation becomes canonicalized as a reference: team members can refer to the shared document and even update it themselves. Second, the canonicalization may spread outside the team. Perhaps some parts of the documentation are not unique to the team’s configuration and become useful for other teams looking to resolve similar problems.
Code reviews (see Chapter 9) are often a learning opportunity for both author(s) and reviewer(s). For example, a reviewer’s suggestion might introduce the author to a new testing pattern, or a reviewer might learn of a new library by seeing the author use it in their code.
Although a measure of technical leadership is expected at higher levels, not all leadership is directed at technical problems. Leaders improve the quality of the people around them, improve the team’s psychological safety, create a culture of teamwork and collaboration, defuse tensions within the team, set an example of Google’s culture and values, and make Google a more vibrant and exciting place to work. Jerks are not good leaders.
People react to incentives over platitudes, and so it’s important to put your money where your mouth is by putting in place a system of compensation and awards.
Because peer bonuses are employee driven, not management driven, they can have an important and powerful grassroots effect.
A system in which people can formally and easily recognize their peers is a powerful tool for encouraging peers to keep doing the awesome things they do. It’s not the bonus that matters: it’s the peer acknowledgement.
Static analysis tools are a powerful way to share best practices that can be checked programmatically.
Static analysis tools augment engineers’ knowledge. They enable an organization to apply more best practices and apply them more consistently than would otherwise be possible.
These are a good way to communicate information that is of interest to engineers but isn’t mission critical. For this type of update, we’ve found that newsletters get better engagement when they are sent less frequently and contain more useful, interesting content. Otherwise, newsletters can be perceived as spam.
Readability covers a wide breadth of expertise, including but not limited to language idioms, code structure, API design, appropriate use of common libraries, documentation, and test coverage.
Readability is both an enforcement and propagation mechanism for these standards.
The longer timescale of the benefits comes with the expectation that code is written with a potential lifetime of years, if not decades.
Knowledge is in some ways the most important (though intangible) capital of a software engineering organization, and sharing of that knowledge is crucial for making an organization resilient and redundant in the face of change.
Psychological safety is the foundation for fostering a knowledge-sharing environment.
Start small: ask questions and write things down.
Make it easy for people to get the help they need from both human experts and...
This highlight has been truncated due to consecutive passage length restrictions.
There is no silver bullet: empowering a knowledge-sharing culture requires a combination of multiple strategies, and the exact mix that works best for your organization will likely change over time.
No team can function well without a leader, especially at Google, where engineering is almost exclusively a team endeavor.
At Google, we recognize two different leadership roles. A Manager is a leader of people, whereas a Tech Lead leads technology efforts.
