The Pragmatic Engineer
00:15:36 · Titus Winters, Gergely Orosz
[00:15:36] S1: Exactly. And like, it's one of the things that I believe very deeply is if you are held back from making changes to a thing out of fear, you have to go in and fix that. Like, fear is not an acceptable basis for engineering. And I think it's in the first two or three pages of the book, I've said now for ten years, you know, your code base is sustainable if, for any valuable change that comes along, you are capable of making that change safely. Right? You may choose not to make that change. Right? That could be technical debt or, you know, different product priorities or whatever. But if you're incapable of reacting to change, then you're placing a high bet or high risk bet that the change isn't critical or isn't important. And I hate to break it to people, but, like, security world has gotten real, real bad in the last few years. Like, there is nothing that is not going to change. Like, the strategic advantage of being able to change is incredible. [00:16:39] S0: Is it safe to say that if I join a company, a startup, a large company, whatever company, I joined a team and I look at the code base and, you know, my first weeks, my first months, I'm just being afraid of pushing code changes because I I worry this thing will break. I'll break production that I'm working on a system that is just, let's say, poorly engineered. It could [00:17:04] S1: be the system is poorly engineered or it could be you... There's some onboarding and mentoring that didn't happen there. Right? [00:17:10] S0: So one or the other problem.
00:17:10 · Gergely Orosz, Titus Winters
[00:17:10] S0: So one or the other problem. [00:17:11] S1: One or the other, for sure. And I think... And this goes to some of the educational stuff. Like, we... In undergrad education and the way that we kind of portray what the job is like, there is a correct answer. There is right and wrong. It is not just the trade offs. And you're graded anytime someone looks at what you have done. [00:17:33] S0: Mhmm. [00:17:34] S1: Right? And I think it's gonna be... Especially for new grads, it's really hard. It's really easy to get into a fear of, like, I don't know if I did this right. I don't know if this was the answer you were looking for because they've been falsely given this perspective that there's the right answer instead of, of course, it's just a trade off. Right? It's And then some point in the design space.
00:17:53 · Gergely Orosz
[00:17:53] S0: And I guess you're also saying that these new grads, they're also used to... You do something that is meaningful effort, typically a class or an exam, and you get feedback. You you get a scale, you get a grade, you get a thumbs up, a pass, or a fail at the very least. And I now actually remember when when I went to my first workplace, I actually remember this this really weird, like, I joined the company, I built this project and then nothing. And then I, you know, I do another thing and then nothing. And then I have a I have a one on one with the CEO of the company and I'm thinking they're gonna fire me because like clearly like I I I knew that, I don't know, like, middle of the day, like, I was sometimes slacking off because I finished my stuff. In hindsight, I was pretty efficient, but I just finished my stuff and then I was just browsing the Internet. I I I told them I'm ready. And I I was pretty sure, like, maybe I'll be re imprinted or something. And instead, they'll be like, oh, amazing job. Like, you've onboarded so quickly. We're so happy with you. And I was... But the the difference was that up until then, I've had years of getting direct feedback, and it didn't connect in my mind.
00:18:56 · Titus Winters, Gergely Orosz
[00:18:56] S1: Yeah. The other part of that is, like, the only time that a human is gonna look at your code if you're an undergrad is to grade you, is to judge you. Right? Whereas, when you, like, become a more experienced engineer, right, like, you're asking for feedback regularly, but it's just a check-in of, are we going in the right direction? Does this make sense to you? And the more of that feedback that you can get that isn't judgment, the more effective you will be. And like, oh, I hate that we've given all of the new grads and all the junior engineers exactly the wrong instinct. [00:19:32] S0: So going back to to Google, what is Abseil? How how do you pronounce it?
00:19:32 · Gergely Orosz, Titus Winters
[00:19:32] S0: So going back to to Google, what is Abseil? How how do you pronounce it? [00:19:39] S1: Abseil. Abseil. Yep. So Abseil was starting about ten years ago. Shortly after the initial pivot to cloud, there was a motion to, hey. We have all of these amazing developer tools in addition to all this amazing production stuff. Maybe we should try to externalize the developer tools as well. And at the same time, there was also a little bit of Google shifting into Alphabet. So for both the developer tooling aspects at one level of, like, how do we share developer tools amongst different companies within the Alphabet umbrella, and how do we share high value internal interfaces and APIs and tech components? How do we share those when it's not one single corporate... One single company? And also not one mono repo. Right? Increasingly. Yeah. Exactly. And so there was a bunch of work that was kind of the normal, like, okay, what does it take to make these developer tools, like, multi tenant and, like, you know, slightly less completely tied into that ecosystem? [00:20:43] S0: And and and just multi tenant for for those who are who are not as familiar with, what does multi tenant mean inside of Google? [00:20:51] S1: Well, so this would have been multitenant of other companies within the Alphabet umbrella, and then maybe extend that out to cloud customers. [00:20:58] S0: Oh oh, got it. Yeah. So like a like a way more and the Google could theoretically use it, something That like
00:20:58 · Gergely Orosz, Titus Winters
[00:20:58] S0: Oh oh, got it. Yeah. So like a like a way more and the Google could theoretically use it, something That like [00:21:03] S1: became not the hottest topic, and they they kinda dropped that idea after a year or two. But the low level components, like, if you wanted to share these things that were written internally in the mono repo, what would it take to do that effectively? And Abseil was basically, here is the layer of common c plus plus idiom. This is the vernacular that everything at Google is written out of. Let's open source that so that there's a common substrate for all Google tech. At the same time, the question was, some of this vernacular is gross and tech deady. Should we clean that up before we commit to it forever? And the answer was yes, to their great credit. So the Abseil open source project is the public projection of the stuff that got cleaned up. Most of the work was... That was... I I would defend pretty strongly. That was probably the largest refactoring task in human history. No way. Yeah. We had, like, ten ten or 12 people working full time with world class tools that no one else understands yet, just cleaning up and making sure that idiomatic code externally would be compatible with idiomatic code internally. [00:22:21] S0: And obviously, when you were talking about cleaning up, you're talking about cleaning up utilities and components that are in the middle of some of the highest used services in the world. Google Search Yep. Yep. Gmail, Maps, you name it. [00:22:34] S1: All of But