A key insight we share in this book is that software engineering can be thought of as "integrated programming over time." We have tried to make the discussions in this book more about engineering and less about programming.
Using Code Examples
O’Reilly Online Learning
How to Contact Us
Acknowledgments
Unit Testing: Andrew Trenk, Adam Bender, Dillon Bly, Joseph Graves, Titus Winters, Hyrum Wright, Augiue Fackler. Compute Services: Tim Hockin, Collin Winter, Jarek Kuśmierek Additionally, we would like to thank Betsy Beyer for sharing her insights and .
Thesis
What Is Software Engineering?
In a software engineering project, engineers should be more concerned about the passage of time and the eventual need for change. Team organization, project composition, and the policies and practices of a software project all dominate this aspect of software engineering complexity.
Time and Change
Over time, we should be much more aware of the difference between "coincidentally works" and "it just so happens". This is a very simple example of the difference between "it works" and "it works". For a short-running program, depending on the iteration order of your containers will not cause any technical problems.
Scale and Efficiency
Grows the amount of work our engineer has to do as a function of the size of. One of the broad truths we have seen to be true is the idea of finding.
Tradeoffs and Costs
Most of the time, our main themes of time and scale overlap and work together. This means, in essence, that decisions will need to be revisited from time to time during the lifetime of the system in question.
Software Engineering versus Programming
We believe it is important to distinguish between the related but different terms "programming" and "software engineering". Much of this change stems from managing code over time, the impact of time at scale, and decision making in the face of those ideas. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and to allow collaboration in a team.
Conclusion
Similarly, all our long-term concerns are about semantic versioning (SemVer) and dependency management in software engineering projects. see Chapter 21) don't really apply for short-term programming projects: use what's available to solve the task at hand.
TL;DRs
We found that most projects seem willing to upgrade within five years. 17 This is not to say that decisions should be taken unanimously or even by broad consensus; in the end, someone has to be the decision maker.
Culture
How to Work Well on Teams
But before you can understand the faults in your colleagues, you must understand the faults in yourself. And to succeed on an engineering team—or in any other creative collaboration—you need to reorganize your behavior around the core principles of humility, respect, and trust.
Help Me Hide My Code
Humans are inherently imperfect - we like to say that humans are mostly a collection of intermittent bugs. Recognizing this theme led us to a more general trend within software development: uncertainty is actually a symptom of a larger problem.
The Genius Myth
This is a very common feeling among programmers, and the natural reaction is to hide in a cave, work, work, work and then brush, brush, brush, sure no one will see your blunders and that you still have a chance to reveal your masterpiece when you're done. In this case, we're claiming you're doing it wrong, and that's a big deal.
Hiding Considered Harmful
Another few months go by and you're having trouble getting your prototype to work properly. You can have all the uninterrupted time in the world, but if you use it to work on the wrong thing, you're wasting your time.
It’s All About the Team
Knowledge Sharing
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.
Challenges to Learning
In this scenario, knowledge and responsibilities continue to pile on those who already have expertise, and new team members or novices are left to fend for themselves and grow more slowly. This is usually characterized by thoughtlessly copying patterns or codes without understanding their purpose, often under the assumption that said code is needed for unknown reasons.
Philosophy
Documented knowledge, on the other hand, can be better scaled not only to the team, but to the entire organization. If we document that knowledge and maintain it, it is now available not only to someone with direct one-to-one access to the expert today, but to anyone who can find and view the documentation.
Setting the Stage: Psychological Safety
The most important way to achieve this safe and welcoming environment is to make group interactions collaborative, not adversarial. These anti-patterns can occur unintentionally: someone may be trying to help, but is accidentally condescending and unwelcoming.
Growing Your Knowledge
But instead of thinking "I don't understand" and ending your thoughts there, dig deeper: what questions should you be asking. Follow the "Chesterson's Fence" principle: before you remove or change something, first understand why it's there.
Scaling Your Questions: Ask the Community
Topic-driven group chats are typically open so anyone can walk in and ask a question. At Google, mailing lists are also indexed and can be discovered by Moma, Google's intranet search engine.
Scaling Your Knowledge: You Always Have Something to Teach
Office hours are almost never the first choice for knowledge sharing: if you have an urgent question, it can be painful to wait for the next session for an answer;. That said, after a class is created, it can be scaled relatively easily because many instructors can teach a class from the same course material.
Scaling Your Organization’s Knowledge
Perhaps some parts of the documentation are not unique to the team's configuration and become useful for other teams looking to solve similar problems. It is also common for the awardee's manager to forward an email to the team to celebrate each other.
Readability: Standardized Mentorship Through Code Review
Engineering for Equity
As new as the field of software engineering is, we are even newer to understanding the impact it has on underrepresented and diverse people. It is important to share and reflect on what we have learned so far with the next generation of software engineers.
Bias Is the Default
In previous chapters, we have explored the contrast between programming as the production of code that addresses the problem of the moment, and software engineering as the broader application of code, tools, policies, and processes to a dynamic and ambiguous problem that may span decades . or even. In this chapter, we discuss the unique responsibilities of an engineer when designing products for a wide range of users.
Google Misses the Mark on Racial Inclusion
Google's tests did not catch these errors; as a result, our users did, which embarrassed Google and harmed our users. In this example, our product was inadequately designed and executed, failing to properly consider all racial groups, and as a result, failed our users and caused Google bad press.
Understanding the Need for Diversity
The first order of business is to disrupt the notion that as someone with a computer science degree and/or work experience, you have all the skills you need to become an exceptional engineer. To address this challenge, engineering teams must be representative of their existing and future users.
Building Multicultural Capacity
We need to understand if the software systems we build will eliminate the potential for entire populations. To continue to be competitive in the technology sector, we must learn to engineer for global equity.
Making Diversity Actionable
Although the software is developed and deployed at ever-increasing speeds, the independent testing is not. Part of building multicultural capacity requires a more comprehensive understanding of how systems of inequality in society affect the workplace, especially in the technology sector.
Reject Singular Approaches
However, it's critical to move beyond the academic conversation and focus on quantifiable and actionable steps you can take to drive fairness and honesty. For example, if you're a tech executive looking to hire more women, don't just focus on building a pipeline.
Challenge Established Processes
This applies to everything from a critical data migration to hiring a representative workforce. Focus first on the most difficult or least represented use case. the system supports both external employment and internal mobility.
Values versus Outcomes
Stay Curious, Push Forward
How to Lead a Team
A piece of software is like that boat: if no one steers it, you're left with a group of engineers burning up valuable time just sitting around waiting for something to happen (or worse, still writing code that you don't ) need). Although this chapter is about people management and technical management, it is still worth reading if you are an individual contributor because it will probably help you understand your own managers a little better.
Managers and Tech Leads (and Both)
At Google, it's common for larger, well-established teams to have a couple of managers, a TL, and a head of engineering working together as partners. The theory is that it's really hard to do both jobs at the same time (well) without burning out completely, so it's better to have two specialists crushing each role with dedicated focus.
Moving from an Individual Contributor Role to a Leadership Role
If you've only been exposed to bad managers your entire career, why would you want to be a manager. Even if you're great at writing code, there's still an upper limit to the amount of code you can write.
The Engineering Manager
A good way to build a culture in which risk-taking is accepted is to let your team know that it's okay to fail. In addition, it is important to see failure as an opportunity to learn and not to point fingers or blame.
Antipatterns
You can be sure the team knows the low performer is there, even if you ignore it. If you're still being handed sub-par engineers, it might be time to look for another job.
Positive Patterns
If you want to get your team moving quickly in one direction, you need to make sure every team member understands and agrees on what the direction is. To have clear goals, you need to set clear priorities and help your team decide how to make trade-offs when the time comes.
The Unexpected Question
If you ask this every time you have a one-on-one, you'll find that your team will eventually remember it and. Pursuing happiness comes down to not only tracking careers, but also allowing your team members to improve, get recognition for the work they do, and have a little fun along the way.
Other Tips and Tricks
It could be the engineer on your team whose technical chops aren't up to par. When you step into a leadership role, the first thing you'll usually discover is that outside of your team is a world of chaos and uncertainty (or even insanity) that you never saw when you were an individual contributor .
People Are Like Plants
Leading at Scale
You are gradually forced to "level up". This means that you are less and less able to get into. The process is often demoralizing—until one day you realize that you actually have far more influence as a leader than you ever had as an individual.
Always Be Deciding
So now we're ready and we go out to the runway and the captain comes back on the PA again. The gate agent says, “Well, there was another flight at 8, but it's all full now.
Identify the Blinders
Sometimes the trade-off is obvious ("if we work on this project, it delays the other..."); sometimes the trade-off has unpredictable consequences that can come back to bite you, as in the previous story. First, identify the shutters; Next, identify the trade-offs; and then you have to decide and repeat one. you – with fresh eyes – have a big advantage.
Identify the Key Trade-Offs
Decide, Then Iterate
Case Study: Addressing the “Latency” of Web Search
For years, thousands of Google engineers have worked on the common problem of making search results better—improving the "quality" of the results page. At some point, we took a step back, identified the blinders, and did a complete re-evaluation of the trade-offs.
Always Be Leaving
If you intentionally reduce a cluster's traffic (run it "cooler"), you'll have less server capacity overall, but it will make each query faster. If you can do that, you are given the freedom to move to a new problem (or organization), leaving a trail of self-denial behind.
Your Mission: Build a “Self-Driving” Team
You are building a plan for how the unclear problem is solved and how your organization can manage the problem over time. You are constantly mapping the forest and then assigning the felling of trees to others.
Always Be Scaling
Anchoring a team identity to a specific solution (“We're the team that manages Git repositories.”) can lead to all kinds of anxiety over time. If the team owns the problem (eg, "We're the team that provides version control to the company"), it's freed up to experiment with different solutions over time.
The Cycle of Success
You are repeating the compromises and the organization is starting to solve the problem. We refer to this final step as the compression phase: you're taking everything you've made and compressing it to half the size.
Important versus Urgent
The spiral of success is a mystery—it's something that's hard to manage, and yet it's the main paradigm for scaling a team of teams. But it's good training for them, and it frees up your time to work on important things that only you can do.
Learn to Drop Balls
And so now that you're doing your tasks, don't try to tackle the top 80% - you'll still be overwhelmed and mostly working on urgent but unimportant tasks. At first this might seem awful, but when you deliberately drop so many balls, you will discover two amazing things.
Protecting Your Energy
Measuring Engineering Productivity
A culture of data-driven decision-making using relevant metrics has some drawbacks, but overall reliance on data makes most decisions objective rather than subjective, which is often a good thing.
Why Should We Measure Engineering Productivity?
The addition of people from the social sciences allows us to not only study the software artifacts that engineers produce, but also to understand the human side of software development, including personal motivations, incentives. structures and strategies for handling complex tasks. After a project is selected, we review how the research team identifies meaningful metrics that will identify the problematic parts of the process.
Triage: Is It Even Worth Measuring?
Note that an action may actually be "maintain status quo" if there is a planned change that will happen if we didn't have this outcome. Technical compromises are not evaluated in a vacuum - in a case like this it is important to realize that.
Selecting Meaningful Metrics with Goals and Signals
By identifying these missing metrics, we can assess whether it is worth creating new metrics or even worth measuring. For each metric, we should be able to trace back to the signal for which it is intended to be a proxy and to the objective it is trying to measure.
Goals
Engineers learn about the Google codebase and best coding practices as a result of the readability process, and they receive guidance throughout the readability process. Engineers see the benefit of the readability process and have positive feelings about participating in it.
Signals
Metrics
At Google, we use qualitative data to validate our metrics and ensure they capture the intended signal.
Using Data to Validate Metrics
Engineers learn about Google's codebase and coding best practices as a result of the readability process. Percentage of engineers reporting that learning or gaining expertise was a strength of the readability process.
Taking Action and Tracking Results
A good metric is a reasonable approximation for the signal you are trying to measure and can be traced back to your original goals. Qualitative metrics should also match quantitative measurements; if they don't, the quantitative metrics are likely to be inaccurate.
Processes
Style Guides and Rules
Our style guides are more than that; they are the complete set of conventions that govern our code. Some of our style guides are concise and focus on a few overarching principles such as naming and.
Why Have Rules?
The wide variation between even our own style guides makes it difficult to pin down the exact description of what a style guide should cover. This chapter discusses the principles and processes that guide the development of our rules and guidance, drawing examples primarily from Google's C++, Python, and Java style guides.
Creating the Rules
Another principle of our rules is to optimize for the reader of the code rather than the writer. Some of the best practices enforced by our style guides are designed to make source code more readable.
Changing the Rules
At Google, the final decisions and approvals for each language's style guide are made by the owners of the style guide, our style arbitrators. The arbitrators make decisions within the context of the agreed goals for which the style guide optimizes.
Guidance
Software engineers come into a new project or codebase with knowledge of the programming language they'll be using, but they don't have it. To bridge this gap, we maintain a series of "
Applying the Rules
Code Review
Although this is a simple definition, implementations of the code review process vary widely across the software industry. Others delegate code review processes to smaller teams, allowing different teams to require different levels of code review.
Code Review Flow
The primary end goal of a code review is to get another engineer to agree to the change, which we indicate by tagging the change as "looks good." We use this. Reviewers open the change in the code review tool and comment on the diff.
Code Is a Liability
This is reflected in the "looks good to me" permissions "bit", which will be set after a peer reviewer agrees that the code "looks good". This allows the two roles to focus on different aspects of the code review and saves review time.
Ownership
Now, you just need to get an OWNER of the library (and owners often have the right readability) to approve the change. Each subdirectory may also contain a separate OWNERS file, and the relationship is hierarchical adder: a given file is generally owned by concatenating the members of all OWNERS files above it in the directory tree.
Code Review Benefits
