- File Size: 8613 KB
- Print Length: 881 pages
- Simultaneous Device Usage: Unlimited
- Publisher: O'Reilly Media; 1 edition (February 28, 2020)
- Publication Date: February 28, 2020
- Sold by: Amazon.com Services LLC
- Language: English
- ASIN: B0859PF5HB
- Text-to-Speech: Enabled
- Word Wise: Not Enabled
- Lending: Not Enabled
- Amazon Best Sellers Rank: #73,252 Paid in Kindle Store (See Top 100 Paid in Kindle Store)
Software Engineering at Google: Lessons Learned from Programming Over Time 1st Edition, Kindle Edition
Use the Amazon App to scan ISBNs and compare prices.
The Amazon Book Review
Book recommendations, author interviews, editors' picks, and more. Read it now
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Customers who bought this item also bought
From the Publisher
From the Preface
This book is titled Software Engineering at Google. What precisely do we mean by software engineering? What distinguishes “software engineering” from “programming” or “computer science”? And why would Google have a unique perspective to add to the corpus of previous software engineering literature written over the past 50 years?
The terms “programming” and “software engineering” have been used interchangeably for quite some time in our industry, although each term has a different emphasis and different implications. University students tend to study computer science and get jobs writing code as “programmers.”
“Software engineering,” however, sounds more serious, as if it implies the application of some theoretical knowledge to build something real and precise. Mechanical engineers, civil engineers, aeronautical engineers, and those in other engineering disciplines all practice engineering. They all work in the real world and use the application of their theoretical knowledge to create something real. Software engineers also create “something real,” though it is less tangible than the things other engineers create.
Unlike those more established engineering professions, current software engineering theory or practice is not nearly as rigorous. Aeronautical engineers must follow rigid guidelines and practices, because errors in their calculations can cause real damage; programming, on the whole, has traditionally not followed such rigorous practices. But, as software becomes more integrated into our lives, we must adopt and rely on more rigorous engineering methods. We hope this book helps others see a path toward more reliable software practices.
What This Book Isn’t
This book is not meant to cover software design, a discipline that requires its own book (and for which much content already exists). Although there is some code in this book for illustrative purposes, the principles are language neutral, and there is little actual “programming” advice within these chapters. As a result, this text doesn’t cover many important issues in software development: project management, API design, security hardening, internationalization, user interface frameworks, or other language-specific concerns. Their omission in this book does not imply their lack of importance. Instead, we choose not to cover them here knowing that we could not provide the treatment they deserve. We have tried to make the discussions in this book more about engineering and less about programming.
About the Author
Titus Winters is a Senior Staff Software Engineer at Google, where he has worked since 2010. Today, he is the chair of the global subcommittee for the design of the C++ standard library. At Google, he is the library lead for Google’s C++ codebase: 250 million lines of code that will be edited by 12K distinct engineers in a month. For the last 7 years, Titus and his teams have been organizing, maintaining, and evolving the foundational components of Google’s C++ codebase using modern automation and tooling. Along the way he has started several Google projects that believed to be in the top 10 largest refactorings in human history. As a direct result of helping to build out refactoring tooling and automation, Titus has encountered first-hand a huge swath of the shortcuts that engineers and programmers may take to “just get something working”. That unique scale and perspective has informed all of his thinking on the care and feeding of software systems.
Tom Manshreck is a Staff Technical Writer within Software Engineering at Google since 2005, responsible for developing and maintaining many of Google's core programming guides in infrastructure and language. Since 2011, he has been a member of Google's C++ Library Team, developing Google's C++ documentation set, launching (with Titus Winters) Google's C++ training classes, and documenting Abseil, Google's open source C++ code. Tom holds a BS in Political Science and a BS in History from the Massachusetts Institute of Technology. Before Google, Tom worked as a Managing Editor at Pearson/Prentice Hall and various startups.
Hyrum K. Wright is a Staff Software Engineer at Google, where he has worked since 2012, mainly in the areas of large-scale maintenance of Google's C++ codebase. Hyrum has made more individual edits to Google's codebase than any other engineer in the history of the company. He is a member of the Apache Software and an occasional visiting faculty member at Carnegie Mellon University. Hyrum received a PhD in Software Engineering from the University of Texas at Austin, and also holds an MS from the University of Texas and a BS from Brigham Young University. He is an active speaker at conferences and contributor to the academic literature on software maintenance and evolution.
Would you like to tell us about a lower price?
There was a problem filtering reviews right now. Please try again later.
I was initially excited to read this book to learn more about software engineering to apply to my work, but I didn't get too many useful takeaways that I didn't already know (or that isn't already widely known for software engineers already). The authors are quite accomplished, making this book appealing to buy at first, but that appeal wore off quickly.
First, It is admirable how the company wants to spread its hard-earned wisdom. Thank you! Many places do many things exceptionally well - but the earnestness to coach and educate others is an extreme rarity - a version of Survivorship Bias - among the “Big Techs”. Collectively, these five books, “Top N” Google Tech Talks (check YouTube) and - depending on your role - coding best practices (check their site) are collectively a combination of top notch combined technical and business education in itself.
Very rarely I give a 5-star rating to a technical book, but SEaG is completely worth the two weeks I immersed myself into learning Culture, Processes and Tools of Google Software Teams. The writers are deeply knowledgable, passionate about their crafts and offer insight after insight into topics ranging from human psychology to the flaws of over-embracing mock testing.
Not targeting on algorithm, language, tools or libraries, it focuses on “Software Engineering” as a system, i.e., stuff that is not taught at any school. The book disambiguates “programming” from “engineering”, and walks through the hardest engineering challenge - how to scale.
It also offers a treasure of insights and ideas from how Google made a billion lines of code change at one time, or how its automated tests could successfully process 50,000 change requests a day, or how Google Production System is perhaps one of the best machines humans ever engineered. Even if you are working nowhere near Google scale, the book covers a lot of fundamentals, especially on how to sustainably develop software and make objective trade-offs while doing so. I would very highly recommend SEaG to any engineering leader trying to improve her team's game. For developers, the four extensive chapters on testing should alone be worth the entry price.
Notes from the "Culture" - first of three - part of the book (most of these should be organization agnostic) -
Software Engineering is “Programming integrated over time”. From a reverse lens, code thus becomes a derivative of Software Engineering.
A project is sustainable if for the expected life span of the software, you are capable of reactive to valuable changes for either business or technical reasons.
The higher the stakes, the more imperfect the trade-off value metrics.
Your job as a leader is to aim for sustainability and managing scaling costs for the org, the product and the development workflow.
Hyperbolic Discounting - when we start coding, our implicit life-span assignment to the code is often in hours or days. As the late 90s joke went - WORA - Write Once, Run Away!
Hyrum’s Law: With a sufficient number of users of an API, all observable behavior of your system will depend on a random person doing a random thing. Conceptually similar to entropy - your system will inevitably progress to a high degree of disorder, chaos and instability. I.e., all abstractions are leaky.
Two spectrums of code - one way is hacky and clever, another is clean and maintainable. The most important decision is to ensure which way the codebase leans. It is programming if ‘clever’ is a complement, and software engineering if ‘clever’ is an accusation!
Google's SRE book talks about the complexity of managing one of the most complex machines created by humankind - Google Production system. This book focuses on the organization scale and processes to keep that machine running over time.
Scaling an org means sublinear scaling with regard to human interactions.
The Beyoncé rule: “If you liked it, you should have put a CI test on it”. i.e., if an untested change caused an incident, it is not the change’s fault.
An average Software Engineer produces a constant number of lines of code per unit time.
Treat whiteboard markers as precious goods. Well functioning teams use them a lot!
60-70% developers build locally. But Google built its own distributed build system. Ultimately, even the distributed build gets bloated - Jevon’s Paradox -- consumption of a resource increase as a response to greater efficiency in its use.
Humans are mostly a collection of intermittent bugs.
Nobody likes to be criticized, especially for things that aren’t finished.
DevOps in one sentence: Get feedback as early as possible, run tests as early as possible, think about security & production environments as early as possible - also known as “left shifting”.
Many eyes make all bugs shallow. Make reviews mandatory.
Three Pillars of Social Interaction - Humility, Respect, Trust.
Relationships always outlast projects.
You have two paths to choose from - one, learn, adapt and use the system; two, fight it steadily, as a small undeclared war, for the whole of your life.
Good Postmortem output - Summary, Timeline, Proximate Cause, Impact, Containment (Y/N), Resolved (Y/N) and Lessons Learned.
Psychological safety is the biggest thing in leading teams - take risks and learn to fail occasionally.
Software engineering is multi person development of multi-version programs,
Understand Context before Changing things - Chesterton’s Fence is a good mental model.
Google tends toward email-based workflows by default.
Being an expert and being kind are not mutually exclusive. No brilliant jerks!
Testing on the toilet (tips) and Learning on the Loo (productivity) are single-page newsletters inside toilet stalls.
1-2% of Google engineers are readability (Code Review tool) reviewers. They have demonstrated capability to consistently write clear, idiomatic and maintainable code for a given language. Code is read far more than it is written. Readability (review tool at Google) is high cost - trade-off of increased short-term review latency and upfront costs for long-term payoffs of higher-quality code.
Knowledge is the most important, though intangible, capital for software engineering org.
At a systemic level, encourage and reward those who take time to teach and broaden their expertise beyond (a) themselves, (b) team, and (c) organizations.
On diversity - Bias is the default; Don’t build for everyone. Build with everyone; Don’t assume equity; measure equity throughout your systems.
A good reason to become tech lead or manager is to scale yourself.
First rule of management? “Above all, resist the urge to manage.” Cure for “management disease” is a liberal application of “servant leadership”, assume you’re the butler.
Traditional managers worry about how to get things done, whereas great managers worry about what things get done (and trust their team to figure out how to do it).
Being manager - “sometimes you get to be the tooth fairy, other times you have to be the dentist”.
Managers, don’t try to be everyone’s friend.
Hiring: A hires A, while B hires C players.
Engineers develop an excellent sense of skepticism and cynicism but this is often a liability when leading a team. You would do well to be less vocally skeptical while “still letting your team know you’re aware of the intricacies and obstacles involved in your work”.
As a leader - Track Happiness - best leaders are amateur psychologists; Let your team know when they’re doing well; It’s easy to say “yes” to something that’s easy to undo; Focus on intrinsic motivation through autonomy, mastery and purpose; Delegation is really difficult to learn as it goes against all our instincts for efficiency and improvement.
Three “always” of leadership - Always be Deciding, Always be Leaving, Always be Scaling.
“Code Yellow” is Google’s term for “emergency hackathon to fix a critical problem”.
Good Management = 95% observation and listening + 5% making critical adjustments in just the right place.
To scale, aim to be in “uncomfortably exciting” space.
All your means of communication - email, chat, meetings - could be a Denial-of-Service attack against your time and attention. You are the “finally” clause in a long list of code blocks!
In pure reactive mode, you spend every moment of your life on urgent things, but almost none of it is important. Mapping a path through the forest is incredibly important but rarely ever urgent.
Your brain operates in natural 90-minute cycles. Take breaks!
Give yourself permission to take a mental health day.
Everyone has a goal to be “data driven”, but we often fall to the trap of “anecdata”.
Google uses GSM (Goals/Signals/Metrics) framework to select metrics to measure engineering productivity.
QUANTS - 5 components of productivity
Quality of code; Attention from engineers; Intellectual Complexity; Tempo (how quickly can engineers accomplish something) and velocity (how fast they can push their release out); Satisfaction
Quantitative metrics are useful because they give you power and scale. However, they don’t provide any context or narrative. When quantitative and qualitative metrics disagree, it is because the former do not capture the expected result!
Let go of the idea of measuring individuals and embrace measuring the aggregate. Before measuring productivity, ask whether the result is actionable. If not, it is not worth measuring.
Despite being written by over a dozen different contributors, who work at Google, the book itself is carefully edited to share a consistent message. Perhaps this is a reflection of the software engineering processes used at Google to enforce consistency within Google's codebase.
The first section on culture covers topics ranging from how to work on teams, share information, lead teams, and measure productivity. It provides a useful perspective on how Google's culture has adapted over the past two decades as the company grew from being a startup with a handful of people to having over a hundred thousand employees. These topics don't typically show up in a software engineering curriculum, but they are very valuable to understand, particularly for engineers and managers at large companies.
The second section covers processes that Google has developed over time to improve productivity of a large number of people working together on a large and long-lived codebase. The topics include style guides, code review, documentation, testing, and deprecation. Two of the main lessons are the value that Google gets from consistency in its code (recognizing that code is typically read more than times than it is written), and the importance of effective automated testing that allows engineers to modify code that they did not write while remaining confident that the code still works correctly. Google has been at the forefront of promoting developer written tests (rather than relying on separate QA or validation teams), and many of the tips and techniques described for writing and maintaining effective tests are quite insightful.
The final section describes the tools that Google uses to support its software engineering activities. The categories of tools are ones that are useful for any software engineering organization, but the specific details in this chapter are harder to generalize than other topics in the book. Google maintains a single source repository (the monorepo) where all its code is stored and it has built custom tools for version control, code search, build processes, code review, static analysis, dependency management, continuous integration, and compute as a service. Reading the specific details of how and why Google developed these tools is insightful, but many of the tools are tightly integrated in Google's environment and the techniques described in the chapter may not be generally applicable to other organizations.
One thing I felt was missing from the book was a discussion of how Google manages its processes to work with open sources projects and share code with people outside of Google. The book focused on code that is developed internally at Google rather than projects that are developed in collaboration with an open source community (i.e Linux, LLVM). But open source is becoming an increasingly important part of software engineering and Google engineers use and contribute to many open source projects. It would be interesting to know how they collaborate with outsiders who lack access to Google's monorepo and associated development tools.
Despite being over 500 pages long, Software Engineering at Google is relatively quick reading and most of the chapters are self-contained and could be read in any order. The authors presented information about software engineering that is not typically covered in university courses, and the book is recommended reading for any software engineer.
It's a good collection of essays though.
Top international reviews
The first half is rather weak, not for lack of appreciation for the managerial skill that building good software takes, but because the book provides the same old cliches that most in software would have come across without providing substantially more motivation. Most of the takeaways are a few bullet-points at most.
My other problem with the book is its (self-announced) myopia to Google. To most novice engineers who haven't themselves run into some of the problems described in the book, the motivations will continue to remain unclear and solutions further obfuscated within the Google-context/parlance. It is entirely possible I was reading it too lazily, but I personally find a barrage of case-studies of unrelated products rather tiring, especially when the content isn't organized in a way where the takeaways are clear.
The second half picks up pace well as it is technical, and clearly closer to the author's day at Google than the former. I found some of the paradigms employed at Google very interesting as to stumble upon them online in one singular place is unlikely, so this book is your best bet.
> If in your journey as a software engineer, you are yet to acknowledge software as a living, breathing thing, you will find little to no value for yourself in this book.
> If you are at a point where you are seeing some scaling issues with your team or engineering process, this book is a must-read because it can provide for a few new paradigms.
> If you are in a large traditional business, you will continue to remain in awe of Google and leave this book without too many actionables.
> If you are in a large tech business, you likely don't need this book because your bootcamp covers it; however, it'll be a very fun read!
Think of it like a very interesting conversation for hours with a Google engineer. He's smart and really experienced, but also incapable of any imagination outside of the Google box.
Strongly recommend as an overview of software engineering based on concrete experiences more than theorical concepts.
Should be a must read for many executive doing software project management.