Lessons Learned from Programming at Google w/ Hyrum Wright & Titus Winters

**Hyrum Wright** (0:00)
Lots of Google's problems aren't actually problems of kind, they're problems of scale, right?
Email existed before Gmail did, web search existed before Google search did. You can pick a number of different technologies that existed before the Google thing came along, right?
But no one had a gigabyte of email storage before Gmail came along, right? Or whatever the obscene number was at the time, right? And really, these are problems of scale. And so when I think about things like migrating software, anyone can change a line of code and change 10 lines of code, but how about changing 10,000 lines of code or 100,000 lines of code in a reasonable time? Those are kinds of the problems that we start thinking about working on systems of this size.

**SPEAKER_2** (0:39)
Want to know how the world's smartest engineers are proving their dev team's connection to the business bottom line? Or how they keep a lead cycle time while minimizing dev burnout and maximizing retention? These are just two of the topics leaders from Slack, Shopify and Stripe will tackle at Interact on October 25th. A free, virtual, community-driven engineering leadership conference, Interact is a one-day event with more than 25 of the most respected minds in software engineering, all selected by the thousands of engineering leaders in the Dev Interrupted community. If you are a developer, team lead, VP or CTO looking to improve your team, this is the conference for you.
Go to devinterrupted.com/interact to register free today.

**Dan Lines** (1:21)
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** (1:33)
Thanks for having us. Great to be here.

**Dan Lines** (1:36)
Yeah, yeah, awesome to have you both. So I wanna 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** (2:04)
Sure, so Google has hundreds of millions of lines of software source code.
And as a strategic goal, we wanna 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 a 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 that the business is gonna 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 wanna make sure that we can always evolve our source code to account for changes in the needs of the business.

**Dan Lines** (2:55)
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** (3:15)
I don't know. Someone was gonna tell me that someday, but largely I have my fingers in most things that pertain to how people write C++ code at Google. So like the teams that I directly manage maintain Abseil and our internal common libraries, Google tests, things like that. So 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 nuts and bolts. 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.
So 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 just this is probably what you wanna do unless you have a really good reason otherwise.