The Pragmatic Engineer
00:14:08 · Gergely Orosz, Titus Winters
[00:14:08] S0: Oh, so so so this is why is Google obsession with tests and quality and Uh-huh. So the the the core money making product was kind of handcuff not being able to push the [00:14:18] S1: rent from 2006. Wow. And circa 2006, almost anything that you did had some tendrils in, like, the front end or search or stuff like the the whole architecture and separation and, like, multi app, multiproduct Mhmm. Like, world, that was still not right. So if you were making changes to Gmail, there were still chances that you were, like, making changes to search. Oh, yeah. And so, like, everything was, you know, holed up. So the release engineers, like, they banded together, and they simply just said, like, you will not merge this change if there is not tests, period. We do not care what VP says anything. We do not care how important this feature is. You will not do that. Like, we will roll that back. Yep. And as soon as you put a line in the sand, even the people that are like, I'm very smart. How dare you ask me to write tests? This is beneath me. [00:15:10] S0: And then so basically taking over or taking on maintenance or even changing any library, C plus plus library, you had the test. So you could have high confidence if you refactor these things, all the tests passed. Yeah. Either it works or there was never enough test coverage. Right. Exactly. Right? [00:15:26] S1: And like... And and either way, it's a
00:15:26 · Titus Winters, Gergely Orosz
[00:15:26] S1: And like... And and either way, it's a [00:15:28] S0: win because if you... It's it's it's better if you expose the lack of test coverage and, okay, you have a crash today, but tomorrow or a year from now, you'll have twice as much traffic anyway. Right. [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: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?