The Pragmatic Engineer
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.
00:49:35 · Titus Winters, Gergely Orosz
[00:49:35] S1: And you will not know because things just happen. Right. Like, you said the important keyword. Right? Trust. Right? Like, a substantial part of this is the psychological safety aspect of it. The other thing, which I think is natural for the AI labs but hasn't been nearly as dominant for the rest of the industry yet, is you're learning as you go. And if you look at all of the research, you know, like DORA research on stuff or any research on productivity or team efficacy or any of those things, like, at root, it always boils down to culture, psychological safety, and the the permission to learn. Right? It's the permission to admit that I don't know something. It is the incentive to learn from each other. It is the incentive to share your mistakes so that the team only has to do that once. Your lint rules or SRE postmortem culture. Every effective structure and organization in tech is actually about information flow and learning. And I think a really great perspective on that. I love Kat Hicks, the psychology researcher for tech. Like, her book, The Psychology of Software Teams, is beautiful. And, like, she talks about, you know, these these things a lot. Right? Similarly, there's a platform engineering at Google book that some of my friends are putting out. There's early release chapters on O'Reilly. I might have written the chapter on education for that. [00:51:03] S0: So so very surprisingly slash not surprisingly.
00:51:03 · Gergely Orosz, Titus Winters
[00:51:03] S0: So so very surprisingly slash not surprisingly. [00:51:06] S1: Right? But, yeah, like, education is the powerful route for, like, let's make this mistake a minimum number of times. Let's codify what we've done. Let's give people permission to admit they don't know and to grow because it's not a one off game. It's an iterated game, and you'll do better over time if your team is better next time. [00:51:30] S0: I want to go back to psychological safety because back about five, ten years ago, we kind of would talk so much about it in engineering leadership side side circles. This was pretty well understood that, you know, a good team feels a safe team. If you, for example, make a mistake, you cause an outage as an engineer, like literally, you push a code and that code causes outage. We should have a blameless postmortem where we don't say that, hey, Gergely pushed this code and he caused the outage because that's now, I mean, I feel terrible and... But let's talk about, like, for example, how could have we avoided this at a system Why did a test not fire? Why was it rolled out immediately when he was a new joiner on the team or she was a new joiner to him? Like, maybe some onboarding could have helped yada yada yada. What... How how do you define psychological safety and why is it important? Especially just playing devil's advocate, like, when we're talking about smart engineers who know stuff, like, is it all that important to us? Because we we should know our thing. Right? I'm just like, I'm kinda removing my emotional Yeah.