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

Today, we are releasing the full interview of one of our favorite episodes: Dans 2021 conversation with engineers-turned-authors, Hyrum Wright & Titus Winters.

As two of the most senior staff engineers at Google, both guests brought a deep understanding of software engineering to the show: Hyrum is semi-famous as the "Hyrum" of Hyrum's Law; while Titus is responsible for managing 250 million lines of code.

In their brilliant book Software Engineering at Google: Lessons Learned from Programming Over Time, Hyrum & Titus explore the engineering practices that make one of the largest codebases in the world sustainable and healthy.

Episode Highlights Include:

• (1:37) Google's strategic goal with its codebase
• (5:09) How the 'Flamingo book' came to be
• (8:01) The role of time in relation to software
• (10:35) Hyrum's Law
• (15:23) What is the real goal of software engineering?
• (17:47) Problems of scale at Google
• (23:24) Consumption of sublinear resources
• (28:18) When shifting left is a bad thing
• (30:25) Science of trade-offs
• (37:00) Constraints are your friend, not your enemy
• (42:46) Hire good people first, good programmers second

Episode Excerpts:

Software engineering is not technical - it's a people problem:
Hyrum: The more I've learned as I've been doing software engineering for however many years, right? Is that this is actually not a technical problem. Software engineering is not a technical problem. And we all love the technology. We love to argue about everything from what's the latest web framework to how many cache misses am I going to have if I use those instructions of that instruction? We love to have those discussions. But the fundamental problems in software engineering is in almost every discipline known to mankind, personkind, is the people problem, right? The interactions between people, the communication. How do you help people? How do you encourage people? How do you get them to do the best thing they want to do? I want people to be great and do the best they can, not because they love Google or they love me or whatever, but because it makes them happy and they want to do their thing. And I can help them do that as a leader in my organization and whatever else. And that will produce better software in the long term. We take more effort in the short term, but it will produce much better results and solve better problems more efficiently in the longest time space that we're looking at. And that's why I think culture is such an important part of building a successful organization.

Software decision making: Can I undo this?
Dan: A lot of our listeners are having to make these decisions and trade offs, like, every single day. As a software engineer, you're making decisions. Do either of you have any tips of what questions you might want to ask yourself in determining should I do this thing around technical debt or not?

Titus: I think the most important piece, especially as we get more experience in our careers. A lot of people come around to the idea that it is much more important to make a decision that you can undo. I'm much less concerned with, is this necessarily the right decision? So as much as what are the stakes here? IF we make this decision and it's wrong, can we undo it? That's very important. I find most of the questions that I ask to the more junior people and my teams are mostly about, I'm just checking your work and looking at your reasoning, and I'm perfectly willing to trust you to make those decisions, so long as we have the ability to change our mind. If additional information comes up, that shows that oh, no, we're wrong. Okay, let's be honest about that. Let's move on. And I think that honesty ties a lot into the trade offs and decision making equation. It is far too easy for people to get caught up in, I'm going to argue that I'm right and I'm going to base my worth and my career stakes on, yes, I did this thing, and I was right. And that's really not engineering. It's really not rational. That's something else, and when we can build a culture around, yup, okay. Screwed that up, let's go fix it. Everyone learns, and that accelerates. It's the question of are you optimizing for yourself in the short term or for the team in the long term? And that turns out to be real important, too.

While youre here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!

Youre invited to Interact on October 25th!

Want to know how engineers at Slack and Stripe connect their dev teams work to the business bottom line? Or how team leads at Shopify and CircleCI keep elite cycle time while minimizing dev burnout and maximizing retention?

These are just two of the topics well tackle at Interact on October 25th.

A free, virtual, community-driven engineering leadership conference, Interact is a one-day event featuring over 25 of the most respected minds in development, all selected by the thousands of engineering leaders in the Dev Interrupted community.

Register now!