The Pragmatic Engineer
00:11:19 · Titus Winters, Gergely Orosz
[00:11:19] S1: Yeah. [00:11:19] S0: You did the best you can. And then when you saw an opportunity, you knew it was better for your strengths. You're like, let's go for it. So so for you, c plus plus low level stuff? [00:11:27] S1: Yeah. I mean, back when I had been doing the consulting at DIRECTV, there was stuff like build an API to do UPnP, like universal plug and plays. Was like local network RPC sorts of stuff. Remote processor you call? Yeah. Right. And so it had been a lot of people... Teams were manually assembling, like, the XML structure for every request to, like, implement a single client call or something like that. It was like, we could do better, folks. And, like, I was probably a little too clever in the way that I assembled all of that API, but it was like, yeah. Like, that was a thing that I liked. [00:12:05] S0: This team, what what was it more of of initiative of like, hey, Google has a bunch of C plus plus here and there, kind of like roots up, like, you know, let's get together and initially in our free time, let's see if we can do something, or was it more some manager typeset, like, I'm actually thinking of assembling a team, a full time team on this? So this was, I
00:12:05 · Gergely Orosz, Titus Winters
[00:12:05] S0: This team, what what was it more of of initiative of like, hey, Google has a bunch of C plus plus here and there, kind of like roots up, like, you know, let's get together and initially in our free time, let's see if we can do something, or was it more some manager typeset, like, I'm actually thinking of assembling a team, a full time team on this? So this was, I [00:12:23] S1: think, like, the last year before Google got actually pretty formal about your embedded to a particular team and headcount is limited, it was a little chaotic. It's a little loosey goosey about how those things work. Oh, okay. I could actually be wrong about that because I was still, you know, new enough that the internals of how headcount works might have been just not clear. But, yeah, like, moved over pretty quick and boy, that that was exactly the place for me.
00:12:23 · Titus Winters, Gergely Orosz
[00:12:23] S1: think, like, the last year before Google got actually pretty formal about your embedded to a particular team and headcount is limited, it was a little chaotic. It's a little loosey goosey about how those things work. Oh, okay. I could actually be wrong about that because I was still, you know, new enough that the internals of how headcount works might have been just not clear. But, yeah, like, moved over pretty quick and boy, that that was exactly the place for me. [00:12:49] S0: Alright. Then so tell me about it. Why why was it the place? What what kind of work can we imagine of like... I mean, because it sounds like when you describe to me, like, taking random c plus plus stuff that people wrote at Google, that sounds like the version of hell for me. Like, you know, like as an engineer, especially pre AI. Right? Like understanding what another engineer at some point wrote who might have left and a team is using and it's working for them like the... It sounds like it's a lose lose because if you take it over and you make a change and you break someone, they'll be mad at you. And if you do it and you do a great job, they'll probably not even think about it because it just it's always worked. [00:13:24] S1: It still works great. Luckily, the fear and the the safety net for making changes had been pretty well established a couple years before this played out. Specifically, and, like, this goes to topics that we'll get to in a second, I'm sure. Specifically, like, Google already went through the phase of, yes, you have to write tests.
00:13:24 · Titus Winters, Gergely Orosz
[00:13:24] S1: It still works great. Luckily, the fear and the the safety net for making changes had been pretty well established a couple years before this played out. Specifically, and, like, this goes to topics that we'll get to in a second, I'm sure. Specifically, like, Google already went through the phase of, yes, you have to write tests. [00:13:45] S0: Right? In 2010, this was not an obvious thing in the industry. [00:13:49] S1: Right. But, like, I think the story is 2006, 2007, search lost the ability to push a release on a regular cadence. Like, it was down to... Like, we were trying for monthly, and they were maybe only get once a quarter because [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: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.