The Pragmatic Engineer
00:42:04 · Titus Winters
[00:42:04] S1: So for any change that's going in, someone that is involved, either the author or the reviewer or author or a reviewer, has to have two different permission bits. First is that ownership thing. So someone has to be in the list of people that is authorized to change these files. And the second is someone has to actually be certified in we believe you understand how to write idiomatic code in this code base in that language. And this is a step towards trying to make sure that everything is relatively consistent and that there's common patterns and that you're not reinventing the wheel because the strategic value of consistency is incredible. And so the readability process is someone has to be certified for that. How do you get certified for that? And initially, that came as employee number three sat down with every new employee and walked them through their first change. That stopped scaling, so they got a bunch of other people to try to proxy Bing Craig, and they walk you through your first big substantive change. And over time, it got to the point where most change was not like, I am writing a new component from scratch. It's an existing product. Like, you're making little edits here and there, you're adding a feature or whatever. So finding something that was meaty enough to demonstrate in one go that you knew everything was kind of hard, and the whole thing felt a little bit more like a hazing ritual. And so over the years, I think the... I think people in Java started it. It moved from that sort of one shot to being explicitly kind of a mentoring program of you do your normal work, and after your team has signed off on it, then we will round robin assign someone from the pool of Java mentors to go through and see, is there anything substantively interesting worth commenting on here to of up the quality of the code and make sure that it matches the rest of the the norms. And you might notice, that means if you're on a team that already has great standards, there's probably very little to comment on. Right? And you'll probably graduate pretty quick. Yeah. And if you're not, and you choose not to learn any of the lessons, you will probably graduate very slowly, if at all. And so the whole thing kind of grew into that.
00:44:23 · Titus Winters, Gergely Orosz
And we standard that sort of mentorship approach into all the other readability languages, and that's been the norm for a bunch of years. I haven't checked up on it since, you know, for at least a couple years. [00:44:36] S0: But but it's very interesting because it it feels to me like this turns code review into into just education in the depth of a programming language. Yep. Was this by design, or was it just a byproduct? [00:44:47] S1: I think it's absolutely by design. Certainly, at the parts of it where I was pulling any of the strings was definitely by design. But, yeah, when I left Google, you know, almost three years ago, readability was kind... Like, I was kind of the overarching owner for the readability program. I would argue that might be the largest educational program in tech or maybe in the world because there were tens of thousands of people participating in that, like, at any given moment. [00:45:14] S0: And and you just participated by by joining Google, and then you had no choice. It wasn't, like, voluntary. [00:45:20] S1: Right. And so, certainly, some people were super pissy about it.
00:45:20 · Titus Winters, Gergely Orosz
[00:45:20] S1: Right. And so, certainly, some people were super pissy about it. [00:45:23] S0: But I guess there was also a goal where it wasn't just about, like, okay. So step one is you need to address the comments that's a readability expert puts on your. Step two, you probably say like, I'd like to get fewer comments on them if you're... If you have any sense of pride because it's kind of embarrassing. And then step three is like, you know what? Okay. I now get zero comments. I actually wanna become a readability expert Mhmm. Myself, and then that's a different level. And then step four is now you are giving feedback. And and I guess through that feedback, maybe you meet people, maybe you start to form some, I don't know, mentorship, friendships. Who knows? [00:45:57] S1: Yeah. And you see other parts of the code base. You see stuff that other people are doing. You learn about other tech that might be happening. Like, it was a huge, like, subtle, below the waterline, like, information sharing program. [00:46:09] S0: In the book, you write about the importance of a team, and I I I'll quote you. In the realm of programming, lone craftspeople are extremely rare, and even when they do exist, they don't perform superhuman achievements vacuum. Their world changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort. A great team makes brilliant use of its superstars, but the whole is always greater than the sum of the parts. But creating a superstar team is fiendishly difficult.
00:46:09 · Gergely Orosz, Titus Winters
[00:46:09] S0: In the book, you write about the importance of a team, and I I I'll quote you. In the realm of programming, lone craftspeople are extremely rare, and even when they do exist, they don't perform superhuman achievements vacuum. Their world changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort. A great team makes brilliant use of its superstars, but the whole is always greater than the sum of the parts. But creating a superstar team is fiendishly difficult. [00:46:37] S1: Yeah. Don't think I wrote that chapter. [00:46:40] S0: It's in the book that you are a co author of. So I wanted to reflect on this especially with AI because now I'm starting to hear a lot more people say, yeah, in the past, we talked about a 10x engineer up to up to one... Up to 22, 23. [00:46:57] S1: We started on that. [00:46:58] S0: But I am now starting to hear people say like, oh, there's now the 100x engineer, which is this engineer who is a great engineer, uses AI amazingly well, and we are also hearing stories of individuals doing heroic efforts by themselves and with a bunch of AI agents. So I just wanted to ask you how the full... Concept of the team holds up as we have more AI tools and the concept of a standout team.
00:46:58 · Gergely Orosz, Titus Winters
[00:46:58] S0: But I am now starting to hear people say like, oh, there's now the 100x engineer, which is this engineer who is a great engineer, uses AI amazingly well, and we are also hearing stories of individuals doing heroic efforts by themselves and with a bunch of AI agents. So I just wanted to ask you how the full... Concept of the team holds up as we have more AI tools and the concept of a standout team. [00:47:23] S1: Yeah. So I think regardless of where you fit on the spectrum of AI believerism, I think the team is still critical. Like, if you believe that the agents are the only answer in another direction forward, we're still managing that team of agents. And I've heard an increasing number of voices talking about it as the problem right now is we need to make every engineer into an engineering manager for a team of agents. And we don't have the training or skill set or background to have done that. Like, we're asking them to do a thing with no no scaffolding or guidance. The alternative is you think of the AI and the agents as your tools, your IDE, but it is still you in conjunction with the team of humans around you. It's still team behavior. Right? I think there are certainly differences in the social dynamics and things like that between you and the agents, which I'm gonna go out on a limb and say the agents don't have feelings. [00:48:27] S0: They definitely do not. Right? Should not.
00:48:27 · Gergely Orosz, Titus Winters
[00:48:27] S0: They definitely do not. Right? Should not. [00:48:30] S1: Like, I'll just hold that line for a bit. But... Yeah. Like, I I think understanding clear communication and being able to write things down and get it out of your head is still, you know, a substantial important thing. Like, I... Yeah. I think it is still unquestionably still teams at the root of it. Software engineering is a team sport. [00:48:55] S0: Period. Also, guess just one, like, pretty, like, naive way to just prove that this is probably still true is if we just look at some of the leading AI companies, the leading AI labs, the Anthropic, the OpenAI's. When I talk to people there, I see standout individuals who are working as a team, you know, like Claude Code, for example. They're they're... They cleverly have a public face in front of both of them, Boris Cherny who created it, and I think they do amazing job. It makes it very relatable that this is a human. There's a team behind Boris. Yeah. And and that team, you can... When I met them, you can tell the the jail. They work together. They trust each other. You know? Like, at some point, Boris will be on holiday. Right.