Software Engineering at Google

Mike's Notes

Discovered this gem via the DORA Community. You can buy the 602-page book from O'Reilly, and you can read an HTML copy for free online at Abseil.

The book is CC BY-NC-ND 4.0

"About Abseil

Abseil is an open source collection of C++ libraries drawn from the most fundamental pieces of Google’s internal codebase. These libraries are the nuts-and-bolts that underpin almost everything Google runs. Bits and pieces of these APIs are embedded in most of our open source projects, and Abseil aims to bring them together into one comprehensive project. Abseil encompasses the most basic building blocks of Google’s codebase: code that is production-tested and will be fully maintained for years to come.

Our primary purpose in releasing Abseil is to more easily support Google open source projects sharing their C++ code outside of Google. In some cases, Abseil provides pieces missing from the C++ standard; in others, Abseil provides alternatives to the standard for particular use cases we’ve needed in the Google codebase. We denote those cases clearly within the library code we provide you.

Abseil is not meant to be competitor to any standard library code; we’ve just found that many of these utilities serve a purpose within our codebase, and we now want to provide those resources to the C++ community as a whole."

Resources

• https://abseil.io/resources/swe-book
• https://abseil.io/resources/swe-book/html/toc.html
• https://www.oreilly.com/library/view/software-engineering-at/9781492082781/
• https://en.wikipedia.org/wiki/Camille_Fournier

References

• Software Engineering at Google curated by Titus Winters, Tom Manshreck, and Hyrum Wright, O'Reilly. 2020.

Repository

• Home > Ajabbi Research > Library > Subscriptions > DORA Community
• Home > Handbook > 

Last Updated

12/10/2026

Software Engineering at Google

By: Titus Winters, Tom Manshreck and Hyrum Wright

Abseil: 01/03/2020

Titus Winters: Senior Principal Scientist at Adobe. C++ Libraries Lead for Google. Founder of Abseil (http://abseil.io). C++ Standards Committee member, chair for Library Evolution Working Group (design for the C++ standard library). Google C++ Style Guide co-maintainer.  Teacher, author.

Tom Manshreck: Education engineer with deep programming experience. Experienced Principal Program Manager and Staff Technical Writer. Have worked on both internal and external projects at Google for 19 years, including as a manager of 12 individuals, a tech lead for a company-wide series of internal programming manuals, and external REST/gRPC-based APIs (Maps and Machine Learning APIs). Deep experience in educational efforts of complex internal programming systems, Cloud APIs, Machine Learning, GIS/Geographic information, and the C++ programming language.

Hyrum Wright: 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.

Camille Fournier: Author, The Manager's Path

...

Foreword

I have always been endlessly fascinated with the details of how Google does things. I have grilled my Googler friends for information about the way things really work inside of the company. How do they manage such a massive, monolithic code repository without falling over? How do tens of thousands of engineers successfully collaborate on thousands of projects? How do they maintain the quality of their systems?

Working with former Googlers has only increased my curiosity. If you’ve ever worked with a former Google engineer (or "Xoogler," as they’re sometimes called), you’ve no doubt heard the phrase "at Google we…" Coming out of Google into other companies seems to be a shocking experience, at least from the engineering side of things. As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises.

In Software Engineering at Google, a set of Googlers (and some Xooglers) gives us a lengthy blueprint for many of the practices, tools, and even cultural elements that underlie software engineering at Google. It’s easy to overfocus on the amazing tools that Google has built to support writing code, and this book provides a lot of details about those tools. But it also goes beyond simply describing the tooling to give us the philosophy and processes that the teams at Google follow. These can be adapted to fit a variety of circumstances, whether or not you have the scale and tooling. To my delight, there are several chapters that go deep on various aspects of automated testing, a topic that continues to meet with too much resistance in our industry.

The great thing about tech is that there is never only one way to do something. Instead, there is a series of trade-offs we all must make depending on the circumstances of our team and situation. What can we cheaply take from open source? What can our team build? What makes sense to support for our scale? When I was grilling my Googler friends, I wanted to hear about the world at the extreme end of scale: resource rich, in both talent and money, with high demands on the software being built. This anecdotal information gave me ideas on some options that I might not otherwise have considered.

With this book, we've written down those options for everyone to read. Of course, Google is a unique company, and it would be foolish to assume that the right way to run your software engineering organization is to precisely copy their formula. Applied practically, this book will give you ideas on how things could be done, and a lot of information that you can use to bolster your arguments for adopting best practices like testing, knowledge sharing, and building collaborative teams.

You may never need to build Google yourself, and you may not even want to reach for the same techniques they apply in your organization. But if you aren’t familiar with the practices Google has developed, you’re missing a perspective on software engineering that comes from tens of thousands of engineers working collaboratively on software over the course of more than two decades. That knowledge is far too valuable to ignore.

Camille Fournier

Author, The Manager's Path

CC BY-NC-ND 4.0