Lessons Learned from Programming at Google - Part I

**Dan Lines** (0:01)
Everyone listening knows who Google is.
Maybe you found this podcast through them. They're one of the most innovative and era-defining companies in the world. And today, we have two of their top engineering leaders, Hyrum Wright and Titus Winters, sharing their lessons learned from programming at Google. Let's dive in.

**SPEAKER_2** (0:28)
This episode is sponsored by Linear B. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**Dan Lines** (0:42)
Hey, everyone. Welcome to Dev Interrupted. I'm your host, Dan Lines, and today we are talking to Hyrum Wright and Titus Winters. Hey, guys, thanks for joining the pod today.

**Titus Winters** (0:56)
Thanks for having us. Great to be here.

**Dan Lines** (0:58)
Yeah, yeah. Awesome to have you both. So I want to give our audience some context before we dive into your book, which is a great book, and let's start out with Hyrum. So Hyrum, you're semi-famous for being Hyrum of Hyrum's Law, which we'll get into a bit later. And your focus at Google is on large-scale code change tools and infrastructure.
Can you give us a quick kind of high level of what that actually means?

**Hyrum Wright** (1:27)
Sure.
So Google has hundreds of millions of lines of software, source code, and as the strategic goal, we want to make sure that is maintainable, that it's fresh, that we can sustain changes that we need to make to that code base, whether it's a business reason or a technical reason, new library standard, new library, or new language standard, new libraries, whatever it may be. We want to be able to evolve our software to meet those needs. And so to do so, we've developed a number of tools to make that happen at scale. And that's a lot of what I do is help the people that are developing those tools do so to understand what are the needs of the business is going to have in terms of being able to evolve software longer term, try to think about new strategies for doing that, and just make it so that we don't have any hidden corners of our code base that people are afraid to touch. We want to make sure that we can always evolve our source code to make, to account for changes in the needs of the business.

**Dan Lines** (2:16)
Okay, awesome. That sounds like a really great job. And Titus, I read somewhere that you're in charge of something like 250 million lines of code. Over 12,000 developers work on this code.
What does your role as a senior staff engineer look like at a high level?

**Titus Winters** (2:36)
I don't know. Someone was going to tell me that someday. No, but largely I have my fingers in most things that are, that pertain to how people write C plus code at Google.
The teams that I directly manage maintain Abseil and our internal common libraries, like Google test, things like that. A lot of the nuts and bolts, I describe it as if all of Google's code base was a book. My teams are the ones that provide nouns and verbs. We are the nut, but I also work as one of the C++ style arbiters, so I produce the C++ style guide that Google uses and that we provide an external drop of. I control the way that you format that, the way that you, what features are allowed, what features are encouraged. I have my fingers in a lot of the best practices, the tips of the week, things that aren't law like the style guide, but this is probably what you want to do unless you have a really good reason otherwise. A lot of education, training, so it really runs the gamut from the very, very low level of maintaining the mutexes and the data structures all the way up to the very people-centric.
We need to answer several questions a day on, hey, why is this crashing? Hey, can you help me debug this? Hey, I need to understand this better. We're the care and feeding for a quarter of a billion lines of C plus code and all of the engineers that go into that.

**Dan Lines** (3:59)
Wow, that's awesome. Yeah. Being responsible for a quarter of a billion anythings is a really cool job as well. The book we're talking about today is commonly referred to as the Flamingo Book, but actually titled Software Engineering at Google, Lessons Learned from Programming Over Time. Hyrum, would you mind giving us a quick intro to the book and how it came to be?