The Pragmatic Engineer - Software engineering at Google & CS education with Titus Winters

0:00What if an engineer who helped define the contents of today's software engineer curriculum said that most of this should be burned down? An ex-Google software engineer says exactly this. In 2023, Titus Winters was the only active software engineer on the steering committee for the ACM and IEEE undergraduate CS curriculum. Before, he spent more than 10 years at Google, was the lead author of the book Software Engineering at Google, and ran the company's readability program.

0:23In today's conversation we discuss why Google made test manager around 2006 after the flagship search product could no longer be released on a regular cadence due to persistent regressions. Ways to measure developer productivity and why the value of AI does not show up in the metrics that we measure today. Ways that Titus would change computer science education, including why he'd want students to be created on their prompts and tests, not the code. And more.

0:48If you want to know what Google learned about Enduring at Scale, or how modern computer science education should look like in the age of AI, this episode is for you. This episode is presented by TurboPuffer, vector and fold texture should both on object storage. It's fast, cheap, and extremely scalable. Before we start, I'd like to talk about Linear, our season sponsor. Until recently, I was thinking of Linear as a tool that helps plan and organize the work, but it's much more than that.

1:14A lot of teams use linear to ship changes from IDEA to Merge and GitHub all without leaving the tool. I sat down with Dima and injured a linear team to see how devs inside of linear use linear to build all of linear. So here's a real issue. When you submit a review with unsent draft comments, linear warns you about these comments. But it doesn't tell you where those drafts are. A customer complained and Dima decided to fix it. But for the fix, Dima did not open his ID.

1:40Instead, he opened up Linear and described the issue to the agent. The agent built a fix, created a PR, and attached storybook screenshots for easy verification. You can see the fix with the draft comments linked on the screenshot. In the PR, there's a versatile preview. You can open the preview with one click from Linear to play around with the change, and we see that it worked. And here's my favorite part. Guided reviews, which is work in progress. Guided reviews is a new code review experience where the important stuff just pops out.

2:09The top of the review has a summary and diagram of the change. And the pull request is divided into chapters that walk you through what's changed. These blocks highlight the important changes in a way that's easier to understand and review. Oh, and when Dima is finished with all of this, he just self-approves the code and is merged into GitHub, all without leaving linear.

2:27If you take one thing away from this, Linear is no longer just a place for planning tickets and organizing the work. It's where all the work happened, creating the issue, kicking out the agent, checking out the preview, doing the review and merging to production. Linear is the product development system for teams and for AI agents, and I'm loving this evolution. Check it out and get a six month trial at linear.app slash pragmatic. Titus, welcome to the podcast. Thank you so much for having me. I'm so excited to have this one. It's awesome to do this in person again.

2:57Yeah, it's a joy. So how did you get into tech? Did growing up, did you know that you're going to do something with computers? I mean, my earliest memories, I thought I was going to be a scientist. But like, you know, as a three year old, that means like lab coats and test tubes and I don't know what else. My dad.

3:15very insightfully knew that computers would be important. That was not his field at all. He was kind of in carpentry and set design, things like that. So there was always a computer in the house. It was usually kind of a low-end thing of whatever we could scrape together and afford. And then I remember I really got my start. I think I was around 11 or 12. And instead of buying candy for everyone for Valentine's one year, he went to the bookstore. And I don't know what my brother got, but I got a book on Learn Q Basic.

3:45And it was all kind of downhill from there. Like I spent probably the next five, six years like programming, teaching myself to program was my hobby. Occasionally I would wind up like meeting, you know, other kids my age that were a little into it. We moved eventually to Las Vegas and I went to a magnet school that had a computer science program that is actually a really well regarded high school these days. I had no idea. And yeah, like just kind of self taught initially pre-internet.

4:14back when you had to really fight for it. But yeah, that set me on my path, that book. And then after high school, it was kind of obvious you went to college for it? Yeah. So I went to Harvey Mudd, which is a great school with a mix of tech and liberal arts education, kind of place that'll teach you to build weapons and teach you not to use them, that sort of thing. And then I met my wife there, and she was a...

4:43a little bit more junior than I was, so I didn't want to move away. She was still in school, so I did my master's at UC Riverside actually in computer science education. I did a kind of weird, I had a very strange graduate experience, but yeah, I spent four years at Riverside doing PhD in CS ed, kind of applied AI, educational data mining, computer science education.

5:10So some of the earliest conferences on CS Ed research I published there. And my advisor was the department chair. He never generally ran grad students. Like the research area was not his focus, but he was constantly the chair. He was this like charming, you know, social political sort of guy that knew all the stories. And so my graduate work was a lot of learn all of the stories of how we got here.

5:39and teach all of the classes whenever there was a hole in the... Yeah, and we'll keep coming back to probably this, like this education, computer science thing throughout this thing. So we've talked before, so I know. But let's jump next. You now graduated from college. You were looking for a job. What did you find?

6:01So first, I did a sort of consulting group. Again, two-body problem. My wife went to grad school in San Diego. I did not get a professorship after my PhD. So I did this consulting stuff. I was at a small startup consulting group, about 30, 50 people. Mostly I worked for indirectly for Direct TV, doing the embedded system stuff on set-top boxes.

6:25And then after four years of that, we were done with grad schools. We were done with all of that. I took the offer to do Google interview, got the offer, decided not to go to the Bay Area, and they moved us to New York. So we've been here ever since. This is when the Google was opening an office here. The office was already open and reasonably big. This was 2010. So I think there were a few thousand people there.

6:52And then in 2010, so Google was founded in 98. They went public in 2004. I remember that they start to really accumulate a global brand as like, wow, Google is the place to work at around like 2005 to 2010. So right around when you were applying, it was actually one of the hardest places to get into. A bit like today, Entropic or last year OpenAI or the, you know, like in the mid 2010s Uber. How did you find the interview?

7:20experience and getting an offer because it must have been pretty competitive at that point. It was competitive. I was a little surprised that they gave me the offer. I felt like I didn't do that great. I remember for some stupid reason, I really, really didn't want to spend a bunch of precious vacation days, so I flew up from San Diego the morning of.

7:40Instead of sensibly like, you know, they would have paid for the whole tone everything. Yeah. I just didn't want like I don't know I'm an anxious person I like my habits and routines and stuff getting up at five for a big interview is not a good plan folks the hot tip So there are a couple things like I remember one interview was like a relatively simple like Clock math sort of thing. It was technically camera angles on a Mars rover or something and there was a point and there was like I'm Tired and having interview brain and this is just basic math. So here's a function that has the right inputs and outputs and if I wasn't stupid this morning that would work and I just did it all in terms of that and I think my interviewer actually really liked that approach Yeah, this is not the important part like let's just talk and so yeah eventually there they gave me the offer and Yeah, moved to New York and started up when you joined you got you got the nuclear half, huh?

8:36Yep, absolutely. And so what did you work on at Google when you joined? So briefly I was on and like I don't think that Google had the best placement for new hires necessarily. On-boarding process, as we say. That was a little rough because like I said the things that I'm interested in are like developer efficiency, problem-solves, like I have a background in networks. I have a background in like API design, those sorts of things. They said, oh, you know, networks.

9:06So let's put you on this team that monitors the amount of traffic and where that is crossing the edge of the Google network, which is actually a databases problem with network says the topic of all of the data that you're doing. I'm like, I don't know anything about databases. That was never my thing. So it wasn't a great fit. And then almost immediately after that, like I want to push a little bit back here already.

9:35is like, come on, you're joining Google, you had college, you had four or five years of experience. When you joined a company, especially a hot company, they said, or I do X, then you're like, I'm not really there. Would you not want to say, let me just go deep into this to see what's important for the business? I am pushing back on you here. Yeah, no, please do always. I did what I could to learn from that team for sure.

10:03There was a little interpersonal tension in some of those things. Okay, so it already started a bit like that. You could have had this nagging feeling. Yeah, it was just like, this wasn't quite right. And then there was an email that went out to all the engineers in New York saying, hey, we're thinking about spinning up a new team that handles all of the old C++ nuts and bolts infrastructure code.

10:26that was written by people whose employee IDs are like two digits. They have more important things to do than to handle like patch requests for all of those components. So we would like people to maintain that. And me and I don't know, nine or 10 other people like raised our hands and I was the only person that showed up to like the second meeting. So I just kind of got onto that team.

10:49Again, I think the context is just important because I think folks here are going, oh, I'm joining this team. The first thing I think the difference, the context that I was missing is, first of all, Google was growing really quickly. New teams were starting up left and right. And also, moving teams was kind of fine. And you are more looking for, you knew that this team.

11:12Both for the what they were doing also sometimes there's not a great people fit. It would probably not be the one where you're going to be staying for many years. Yeah. 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 for you, C++ low level stuff. Yeah. I mean, back when I had been doing the consulting direct TV, there was stuff like build an API to do UPNP, like universal plug-in place. It was like local network, RPC sorts of stuff. Remote parts of your call.

11:41Yeah, right. And so it had been a lot of people, teams were manually assembling like the XML structure for every request to like implement at 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, it was a thing that I liked. This team, what was it more of?

12:08initiative of like, hey, Google has a bunch of C++ 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 type said like, I'm actually thinking of assembling a team, a full-time team on this. So this was I think like the last year before Google got actually pretty formal about your embedded two-way particular team and headcount is limited. It's a little chaotic. It's a little loosey-goosey about how those things work. Okay.

12:37could 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. All right. Did you tell me about it? 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 stuff that people wrote at Google, like that sounds like the version of health for me. Like, you know, like as an engineer, especially pre AI, right? Like.

13:06understanding what another engineer at some point wrote who might have left and a team is using and it's working for them. 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. If you do it and you do a great job, they'll probably not even think about it because it's always worked. It still works great. Luckily, the fear and the safety net for making changes had been pretty well established a couple years before this played out.

13:35Specifically 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 Right in 2010. This was not an obvious thing in the industry, 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... Oh, so this is why Google will obsession with tests and quality and... So the core money-making product was kind of handcuff not being able to push around to 2006. Wow. And circa 2006, almost anything that you did had some tendrils in like the front end or search or stuff, like the whole architecture and separation and like...

14:31Multi app multi products like world that was still not right? So if you're making changes to Gmail there were still chances that you were like making changes to search And so like everything was you know hold 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 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. And then so basically taking over or taking on maintenance or even changing any C++ library, you had the test so you could have high confidence if you refactor these things, all the tests pass. Either it works or there was never enough test coverage. Right, exactly.

15:26Right and like and any other way it's a wooden because if you it's better if you expose a 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 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 10 years, your code base is sustainable if for any valuable change that comes along, you are capable of making that change safely. You may choose not to make that change. That could be technical debt or different product priorities or whatever. But if you're incapable of reacting to change, then you're placing a high risk bet that the change isn't critical or isn't important.

16:25I hate to break it to people, but security world has gotten real, real bad in the last few years. There is nothing that is not going to change. The strategic advantage of being able to change is incredible. Is it safe to say that if I join a company, a startup, a large company, whatever company, I join the team and I look at the code base and my first weeks, my first months.

16:53I'm just being afraid of pushing code changes because 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 be the system is poorly engineered or it could be there's some onboarding and mentoring that didn't happen there. Right? So one or the other probably. One or the other for sure. And I think, and this goes to some of the educational stuff, like we in undergrad.

17:20you know, education and like 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, 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 a right answer instead of, of course, it's just a trade-off, right? It's at some point in the design space. And I guess you're also saying that these new guys are also used to you do something that is a meaningful effort, typically a class or an exam, and you get feedback. You get a scale, you get a grade, you get a thumbs up, a pass or a fail at the very least. And I know I should remember one when I went to my first workplace. I should remember this, this really weird, like join the company.

18:16build 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 going to fire me because like clearly, like I knew that I don't know, like middle of the day, like I was sometimes slacking off because I finished my stuff at hindsight. I was pretty efficient, but I just finished my stuff. And then I was just browsing the internet. I told them I'm ready. And I was pretty sure like, maybe I'll be re-imprided or something. And instead.

18:45They'll be like, oh, amazing job. You've onboarded so quickly. We're so happy with you. But the difference was that up until then, I've had years of getting direct feedback, and it didn't connect to my mind. Yeah. The other part of that is the only time that a human is going to look at your code if you're an undergrad is to grade you, is to judge you. Whereas when you become a more experienced engineer, you're asking for feedback regularly, but it's just a check-in of like, are we going in the right direction? Does this make sense to you? Right? 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 like given all of the new grads and all the junior engineers exactly the wrong instinct. So going back to Google, what is AppSale? How do you pronounce it? AppSale. Yeah. So AppSale was starting about...

19:4310 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?

20:12different companies within the alphabet umbrella? And how do we share high value, like internal interfaces and APIs and, you know, tech components? How do we share those when it's not one, you know, single corporate, right, one single company? And also not one Monoripo, right? Increasingly, yeah. Exactly.

20:32And 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. And just multi-tenant for those who are not as familiar with, what does multi-tenant mean inside of Google? Well, so this would have been multi-tenant of other companies within the alphabet umbrella and then maybe extend that out to cloud customers. Oh, got it. Yeah, so like a way more.

21:01And the Google could use it something like that. That became not the hottest topic. And they kind of 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 monorepo, what would it take to do that effectively? And abseil was basically here is the layer of common like C++ idiom. Like this is the vernacular that everything at Google is written out of.

21:30Let's open source that so that there's a common substrate for all like 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 like projection of the stuff that got cleaned up. Most of the work was that was I would defend pretty strongly. That was probably the largest refactoring task in human history. Don't we? Yeah, we had like 10 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. And obviously, when you were talking about cleaning up, you're talking about cleaning up utilities and components that are...

22:27in the middle of some of the highest used services in the world, Google search, Gmail, Maps, you name it. But like if you would break something, you would probably see at some point an outage in one of those services. It was at the time, I think it was 200 or 250 million lines of C++ code with 250 million lines of C++. First party, not counting external dependencies. And Google had that kind of.

22:55I think that was the public number at the time, 10,000 engineers probably at the time, making edits to that code base in a month. And so our job was, we joked about, that's a New York reference. We joked about it as our job is the logical equivalent of Google has a new technology for the skyscraper foundations. We're replacing the foundation under the Empire State Building. We're not allowed to close the building or block traffic. And we discovered nuclear waste in the basement. It's okay guys, we got this.

23:24It was, it was a magically, it was a great team. I just want to put the 250 million lines of code in perspective because today with AI, AI can generate like, you know, we have crazy numbers. It can generate tens of thousands of lines of code in an hour, et cetera. And you can get to millions if you want to. Honestly, just an agent can do it. However, pre AI, Uber's mobile application was about a million lines of code on iOS and on Android. And that was each written by 200 engineers for years.

23:54bun runtime at Entropic just rewrote something like, I think it was like 500 or 900,000 lines of code. And that was written by a small team. I find it rare to find examples of a project that has more than pre AI, more than let's say three million lines of code. And that will typically be hundreds of engineers writing it for, for several years. So in this, the reason I was like 250 million, that is about a hundred times more than I've heard for code base. And we're talking about like, Clearly, this is written for production. You're not like just goofing around and pushing some scaffolding here and there and right. And when you say first party, it's easy to have a lot of cool when you take on an open source component, but no. No, that was all Googler authored. So we have some insight into how things grow.

24:46Okay, so the largest refactoring history at that point in human history might have, you're not extricating. I don't think so. I mean, I can't prove it, but I would be surprised. So how, okay, when you have this, you are in the middle of this sense, 12 people, you have this massive, massive task that seems giant and almost, how do you go about it? How do you say like, how do you break it down? How do you plan for it? How do you speed it up? Because you clearly, if you just did it by hand, this would have not fully worked. Right.

25:16So one of the things that had enabled any of this and that came out of having been on that low level C++ infrastructure team to start with was, okay, if we own the interfaces that are kind of the nuts and bolts that everything at Google is written out of, like way below the database level, just like caches, containers, string manipulation routines, command line flags, like that sort of thing. If we own those things, maybe it's valuable to make them better.

25:43But how do you do that when there's 50,000 call sites or 100,000 edits that need to be made to change that API? And so luckily, I was friends and org chart cousins eventually with the compiler team, especially Clang LLVM people. And so they started doing stuff in the AST transformations or space. AST. Abstract syntax tree. So like you take a parse tree and, you know, it's Google, like MapReduce.

26:10So if you do a map reduce over the code base, where the mapper parses all of the translation units of your C++, like all of the build targets, and produces here is the parse tree, then you can match the parse tree for specific like, it's not text match, it's I guarantee you are calling this particular function in this particular context, and then you can apply some code to rewrite based on that.

26:39And so we had compiler assisted, you know, semi-automatic refactoring to generate all of the text edits. Turns out one of the things that was really hard at first was we could generate the edit, but we couldn't get the white space in the right places. No way. Yeah, seriously. So Clang format exists because I wished for it. This is like the auto formatter for many like C++ sorts of languages at this point, but it's like...

27:06I literally cannot accomplish this refactoring until someone figures out a way to like hack together a auto white space for C++. And so you do that, you generate one, you know, big edit. It is too large to fit in the codebase. Because for any given codebase, there's kind of a natural background level of how much change is happening. And if you're trying to edit 10,000 files, 20,000 files, it is likely the case that you will never be able to test and re-sync before something has gone out of sync. Someone else edited something. Yeah, exactly. Merge complex, parallel changes, that kind of stuff. Yeah, exactly. You do not want at a 10,000 plus person company to be like, everyone stop touching the repo for an hour, let me do this thing. That's not going to scale. And so the tech is you figure out how to do your refactoring so that the old API and the new one can coexist in spelling. And then you

28:04parallelize, like just cut by like directory structure. Like, all right, I'll send you this batch of updates, this batch of updates, and you wind up, you know, going like that. And then once everything is clean, then there's a race to make sure no one copy and pastes the old thing. And then you delete the old thing. The new thing is the default you move on with like, you just do that a few hundred times and your code base is in much better shape.

28:29Yeah, wow. And then you're doing this all the while, while other engineers, they're just doing their thing. They're using these things they don't even know about. They don't want to know about you. I mean, they might be aware of you, but they shouldn't have to change their, as you say, slow down. But we did get amazing feedback on some of this. At first, people are like, what are you doing? Why are you changing my code? I'm not OK with this. And very quickly, they're like, oh, this is great.

28:55I go away, my code just gets better. And I don't need to worry about looking up, is this the right way to do a thing? Because if it was the wrong way to do a thing, you would have gotten rid of it already. When you have someone that is going through and just janitoring the code base like that, copy and paste becomes the correct answer for how do I do this? Find someone else that did it once, you copy it, you move on with life, and you have evidence that it's probably a reasonable answer.

29:25Because if it was wrong, we would have fixed it already. It's very interesting because today, obviously, if you did a big refactoring, the obvious tool that you would reach for is AI, as we've seen with so many companies having lots of success with, well, in the sense that AI is capable of, the challenge that you had is you had this massive, massive code base, rewriting it by hand would have not been feasible, but at Google, you came up with a very clever semi-automated approach, which was based on pretty hardcore.

29:51language parsing and coming up with new ways where you could formally, maybe informally or at least prove that this thing will be correct, which is what most teams would not have the availability capacity, even expertise to do. What everyone has the capability to do right now is like, oh, AI, go and do this and do tests and all this. However, where I wanted to get to, like, rewriting with AI still feels so much more janky than what you did, which was so much more deterministic.

30:21And I wonder if this technique that you use that Google might at some point spread or people will just put up with like AI kind of, you know, like it might or might not work. I think if you're looking for it, it's already out there in the Java space in particular tools like open rewrite. Like you basically, there's a little configuration per run for it. And you say like, this is the pattern I'm looking for in the Java code. This is how the rewrite would look. And.

30:50it goes through and blasts through all your source files and does that update. Turns out AI tools are really, really good at generating open rewrite recipes, which is way cheaper on token consumption and way more accurate and much faster and auditable. It is a substantially better pattern. We've seen talks from, I want to say Netflix and Uber, I could be wrong, specifically on Like everyone seems to be coming to the same conclusion of what you need is a deterministic tool that declares the intent of the rewrite. You can have the AI like write a little skill to tell train the AI how to create the config for those tools. And then you move on with life and the C++ space. Actually, some good friends might have a startup right now. It's called Bronto source that is specifically just about that sort of declarative rewrite pattern.

31:46At a very high level of intent very powerful for C++. Yeah, I like the idea of using AI to help generate deterministic software tools transformations. Yeah Kelsey Hightower gave a great talk recently on like zero token architecture and Like his whole thesis and I think everyone is coming to the same conclusion. Don't use AI for constant inference use AI to generate the deterministic tool that will actually do the work and then have AI fill in the gaps on the parts of the problem that you can't solve or where to invoke the tool, things like that. Like if your whole architecture is token consumption for all time, it's probably a cheaper and more effective way to do it. Yeah, I just recently heard a head of engineering tell me that they're using these AI code review tools, which are pretty good.

32:44but very expensive and slow. And this person said like, hang on, like what if we told the AI, okay, like let's do a thorough code review every now and then, but when it finds something, let's have it generate a lint rule. Yes, please. Which is cheap and repeatable. And it will no longer take 30 minutes to cost. And also it's just non-deterministic. It might or might not find it next time. That was a frustrating, like this person was like, look, when we know we have certain things. So now what they're doing is every now and then they still run some of these reviews. And of course, but whenever they find any issues, then they fire up inference, AI, several agents and say, all right, can you come up with an improvement in our deterministic? Linting can help it. And the inspiration came actually from this person heard about how Uber, actually, I think it was, they've heard me talk about when I joined Uber, I could barely commit my code the first.

33:36The first week it was so painful because a linter just kept rejecting it because Uber had this, uh, Enduring culture that pre AI, whenever you saw something break, you just put a lint rule. Architectural rules were all in rent rules. You could not have something like, uh, we had an architecture and you could not inherit the wrong way. Cause a linter would say like, ah, you cannot, you cannot inherit from like a builder, cannot inherit from a, I don't know what, what a composer or whatever that was. Yeah. No, I think it makes.

34:05perfect sense. Let's try to learn our hard lessons only once, codify those rules somewhere to Germanistic, apply them equally and appropriately and fairly, and leave the interesting parts of code review. Make sure that the parts of code review that we're focusing on are only the things that humans need to be doing, which was true then.

34:29don't think everyone invested in linting and static analysis that quite to that extent they should have. And then it's equally true now, right? Like, we can't review everything, but like there are places that require like this human attention that is well spent. Titus just made the case for learning the hard lessons once, then writing the damas rules and saving the human attention for the things that really needs it. That is pretty much the same way you want permissions for AI agents to work, which brings us to our seasoned sponsor, WorkOS.

34:58Workwares provides the auth infrastructure that B2B and AI native companies need to sell to enterprise customers with SSO SCIM RBAC and now authorization for AI agents. Workwares' airlock is the intent-based access control. Most access control only asks who you are. Airlock also looks at what the agent is trying to do at the moment it tries to do it. Clearcut rules like no agent deletes cloud resources are run as plain code. For the fuzzier calls, an AI just evaluates the policy at runtime.

35:26You write those policies in plain English and Claude can pull the ones you already have out of Notion or Gyra and import them for you. Your agents, whether that's Claude or Devin, connect to a single access point and your MCP servers are behind this access point. Airlock is a new layer on top of your existing permissions, which means that an agent can never get more access than the person who invoked the agent. When something risky comes up, Airlock can escalate to Human for Approval, say over Slack. It's the same idea Titus described, write the rules once and spend human attention only on the calls that need it.

35:56you can request early access at workcross.com slash airlock. I also want to mention a representing sponsor, TurboPuffer, a ridiculously scalable, fast and cheap hybrid search engine built on top of object storage. How often do you get to see a rewrite playing out in real time? With the tip of team, we finally can. They are completely redesigning their storage architecture from first principles to make search faster, cheaper, and more reliable at scale. The new system called TurboPuffer v3 is not yet in prod, but it already passes CI.

36:23and when the rewrite started in September, it was not nearly as performant as the current production version V2. The team of team had been perfmaxing query plans until they are fast or faster than V2, doing all this in public all the way up to the V3 production launch. And it's so cool to see their progress. The new system went from being 10 to 100 times slower across most metrics to being several times faster on things like cold vector search, order by attitude, or hybrid search.

36:49The v3 system is still slower in areas like full text search, but only 1-2 times slower versus 100 times slower when this perf maxing started. And the team is sharing exactly how they optimize things in their development logs with things like group count aggregation, compressed column encodings, batch scoring, and many more. A lot of these wins are basic foundational work right now, but the team will be sharing some very cool systems work over the next few weeks. But hang on, why is the team doing a full rewrite?

37:18It's because search is changing, and so is TurboBuffer. T-Puff started as a vector database, but it is no longer a vector database. It has evolved into high-performance database for search. The V3Diskars is a vector primary index, and all indexes will share the same columnar storage system. Every query will run on vectorized query engines, which is something you don't usually see in search databases, but which will result in both very fast search and just generally a very fast database.

37:44The TurboPuffer team is keeping a work log of their journey, and you can follow along at www.turbopuffer.com. It's a blast to see how it's being built. Speaking of hard lessons and documenting them, can we talk about software engine and Google, the book that you're quite well known for? How did the idea come? How did it come together? What was your motivation to start with? So this was a little bit.

38:07The tail end of, hey, maybe we'll ship the developer tools. Maybe we'll need to explain why Google's developer tools are the way they are, because otherwise it'll be a little bit of like aliens came down and are trying to give you something that doesn't make any sense in your world. Part of the reason that we had the hubris to tackle that sort of task was because we had been doing this refactoring at scale everywhere. And when you run into everything that any engineer thought was a clever solution to their problem, it meant that my cadre of weirdos have run into so many. Oh, yeah, I can see how you thought that was a good idea. Don't do that. Like, more than anyone else out there. Well, you're talking some of the most kind of battle-scarred people in the industry, just because you're working on these large-scale systems for such a long...

39:02period of time. And it's not the production battle scars. It's the like testing and like local code design battle scars. Like everyone else in the industry has like all of this production experience. And like my job ends at merge. Like I know more about development and API design and test and keep the code base as an artifact working than most. But it doesn't mean.

39:29I'm kind of an outsider in that sense. Well, interesting enough, the, I mean, the book is very, very thorough on how it gets production, but it does not cover the operational part, which I guess is the SRE book. But there is an SRE book, which, well, then this book would be like twice as long. How did you pull the book together? Because you wrote some parts of it, other folks inside of Google wrote different chapters of it. So it's very much in the spirit of the SRE books.

39:57Like try to get the expert on or an expert on Kevin topics to contribute something useful And then the three names on the front of the book myself Hiram right and Tom Man Trek Hiram and I were kind of the technical leadership for that and Tom has is plenty technical but it has been our tech writer friend for many many years So he handled a lot of the like editorial structural organizational stuff, but Hiram and I had been the tag team of Hyrum generated millions of edits and sent them to me for review and I had the permissions to review almost everything in the codebase and so like everyone knew us as like the those two guys that clean everything up So we had those scars and so we led that and then the the trick was like finding the experts to to write something high quality some of those were Great from the start a lot of that took you know

40:54bit of ghost writing and stuff. The whole task was actually almost two years, certainly not full time. We were at most probably putting in a quarter to half time most of that time. But yeah, we wrangled together way too much text from way too many people. And I don't think I realized just how much we overshot until I saw a printed copy of that book. I was like, wow, that's huge. And even today, I do recommend the book because it gives a really good understanding of how the Google at the time worked. Obviously there's been evolving since, but how a company going from zero to building important production systems came over the bunch of stuff that might not make as much sense. And you talk about things like like Mono repo, like the stringent code review process, how there's a readability process at Google. And maybe we can talk about that as part of Google is the only company I know where

41:52for code review back in the day, they didn't just have code review like an engineer who owns this part of the system and understands reviews it and says it's okay, but Google had a readability review. What is readability review? 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 bids. 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 that you're not like reinventing the wheel because the strategic value of consistency is incredible. And so the readability process is

42:48someone 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 would 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. 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 people in Java started it, it moved from that sort of one shot to being explicitly kind of a mentoring program of

43:45You do your normal work and after your team has signed off on it, then we will round robin assign someone from the pool of like Java mentors to go through and see like, is there anything like substantively like interesting worth commenting on here to kind of up the quality of the code and make sure that it matches the rest of 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.

44:15And 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. And we extended 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 of years. But it was very interesting because it feels to me like this turns code review into just education in the depth.

44:44of a programming language. Was this by design or was it just a byproduct? 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 almost three years ago, readability 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.

45:13like at any given moment. And you just participated by joining Google and then you had no choice. It wasn't like voluntary. Right. And so certainly some people were super pissy about it. 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 readability expert puts on your step two. You probably say like, I'd like to get fewer comments on them if you have any sense of pride because it's kind of embarrassing. And then step three is like, you know what?

45:41Okay, I now get zero comments. I actually want to become a readability expert myself. And then that's different level. And then step four is now you are giving feedback. And I guess you have this feedback, maybe you meet people, maybe you start to form some, I don't know, mentorship friendships, who knows. 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.

46:10In the book, you write about the importance of a team, and 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 in a 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. Yeah.

46:38I don't think I wrote that chapter. It's in the book that you are a co-author of. 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 22, 23. Don't get me started on that. 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.

47:06And 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 concept of the team holds up as we have more AI tools and the concept of a standout team. Yeah. So I think regardless of where you fit on the spectrum of like 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 guidance. The alternative is you think of.

48:04the 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. I think there are certainly differences in the social dynamics and things like that between you and the agents, which I'm going to go out on a limb and say the agents don't have feelings. They definitely do not, right? Should not hold that line for a bit.

48:34But yeah, I think understanding clear communication and being able to write things down and get it out of your head is still a substantial important thing. I think it is still, unquestionably, is still teams at the root of it. Software engineering is a team sport, period. Also, I guess just one pretty naive way to...

49:00just prove that this is probably still true as if we just look at some of the leading AI companies, the leading AI labs, the entropics, the open AI's. When I talk to people there, I see standout individuals who are working as a team. You know, like Claude Cote, for example, they cleverly have a public face in front of both of them. Boris Cherni who created it. And I think they do an amazing job. It makes it very relatable that this is a human. There's a team behind Boris. Yeah.

49:27And that team, when I met them, you can tell the jail, they work together, they trust each other. At some point, Boris will be on holiday. And you will not know because things just happen. Right. Like you said the important keyword, trust. 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.

49:56And if you look at all of the research, like Dora research on stuff or any research on productivity or team efficacy or any of those things, at root, it always boils down to culture, psychological safety and the permission to learn. 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.

50:26your lint rules or SRE post-mortem culture, every effective structure and organization in tech is actually about information flow and learning. I think a really great perspective on that. I love Kat Hicks, the psychology researcher for tech. Her book, The Psychology of Software Teams, is beautiful. She talks about these things a lot.

50:54Similarly, there's a platform engineering at Google Book that some of my friends are putting out as early release chapters on O'Reilly. I might have written the chapter on education for that. Very surprisingly, slash not surprisingly. Right? But yeah, education is the powerful root 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.

51:21because 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. 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-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.

51:49we should have a blame is postmortem where we don't say that, hey, Kergay pushed this code and he caused the outage because that's now, I mean, I feel terrible. But let's talk about, for example, how could have we avoided this at a system level? Why did the test not fire? Why was it rolled out immediately when he was a new joiner on the team or she was a new joiner? Maybe some onboarding could have helped, yada, yada, yada. How do you define psychological safety and why is it important?

52:17Playing devil's advocate, like when we're talking about smart engineers who know stuff, like is it all that important to us? Because we should know our thing, right? I'm just like, I'm kind of removing my emotional hat here. Yeah, we should know our thing, sure. So I would say it's been a little hard to like root this stat, but from talking with people in Dora, the research, the one thing that I love was we can explain 30% of the variance.

52:46in whether or not your team will hit its goals based on how you score on psych-culture questions. We could give you a 15-question true, false, or maybe liquor-scale, but a 15-question assessment for the team and predict 30% of whether or not you will hit whatever your goals are. That's insanity. That is more powerful than any other signal. You think that we're all Engineers and this is all just computers and tech and emotions have nothing to do with it find me anything that's even remotely that powerful predictor of success It's a people problem like period right and Going back to right. It's it's not a single shot game. It's an iterated game I regularly cite Fred Brooks in the mythical man month essays right and in the surgical team like I the surgical team is my least favorite chapter in that book because it's structured as if

53:45We're only ever gonna do one project get the best person to do this get have everyone else build the tools and do the documentation under them. It's very high right and it's very like power dynamics mad Yeah, right, but it might make sense if you're only ever going to do one task Instead we're playing like in a game theory sense. It's not prisoners dilemma. It's iterated prisoners dilemma There's a different strategy and the strategy is find the most junior person that can do it with supervision so that they learn and grow and you still get a decent outcome. And that next, like the higher level people can solve something that they don't know how to do yet or that no one else can tackle. This is the only way to structure it so that growth happens. But in order for that growth to happen, people have to be willing to admit that they don't know a thing.

54:40brings you straight back to psychological safety and learning culture. If it is a culture that highlights information sharing, learning and growth, you will succeed. You mentioned that the AI labs probably take this for granted. Because they don't know what they're like. Well, I'm going to paraphrase it. With the AI labs, a few things going. First of all, business is booming. They're growing. Revenue goes up. Customers goes up. Funding goes up. Headcount goes up.

55:07Their teams are only ever expanding. They're on hyper growth like we've seen companies like Netflix and Uber and hyper growth. This is even faster. Your equity also goes up. So you don't need to worry about things like performance reviews because performance reviews are typically important where like how much bonus I'm going to get how much but when you're at a place that goes like this and your equity goes up, your financial part is taking care of just by focusing on helping the company succeed regardless of your titles. Second of all, Because they're building new technology and they know no one knows. So they just tell, okay, I don't know, I'm learning from you. Here's what I learned. So it's just all natural. Whereas compared to a company that might not grow like this, they might still be using, let's say AI, but now there's lots of incentive to say, I don't know, because there's a performance review coming up. You want to look like the smartest. You don't want people to say like, well, this person says, I don't know a lot. Your bonus will be lower. You might be put on a performance improvement plan because you're now at a company that every year.

56:02Let's go six percent of people. Right. And your goal is suddenly going from like, I just don't want to be there. I want to hang on to this job, but it's now hanging on. It's now, and you also, you're now very of maybe your teammates because now there's an internal competition. You want to hog that project. Yup. And so this is a huge difference. Yeah, it's huge. Like if you get into the mode of believing that the team outcomes are what matter for your own success, then it is much easier for you to realize like, okay, I don't have to have this one shiny task. Like the team will be successful by virtue of someone doing this and it might be my turn next. If when it breaks down into that like individualism and like, I don't trust the guy across the way from me or, you know, right shoulder to shoulder to me, like, even though we're on the same team work.

56:58scraping by and fighting for attention and success. And that's not a recipe for innovation and growth. That is a recipe for stagnation and just bad. One of the obvious things that I assume he does not do good for psychological growth or it's terrible for it is layoffs.

57:19Can you tell me based on your observation and we've seen right like we've all been part of it and in 2022 2023 there has been a series of layoffs. Right now companies are doing it again. Back then it was to do with on its interest rates and over hiring during zero interest rates and growth is kind of going down. Now some companies are actually openly saying that it's AI. Some are not as openly but we find out that Meta for example wanted to do scene ties is because they thought that I will be there.

57:49From your observations at a company where a layoff happens How does it change how software engineers show up work? Think speaking both about your experience the people you talk with I mean, it's stressful like I've had experiences of there being layoffs in the area and just it it'll be weeks or months of everyone on one starts with, so how are you doing? How are you coping? There's this huge amount of negative performance influence of, okay, we got to emotionally support each other first before we actually even get back to doing the work. And I'm very skeptical that the executive accounting on all of this that they're taking into consideration

58:43just the sheer amount of lost productivity and lost time from like, yeah, people are stressed. People are spending time brushing up their resume in case they're next on the chopping block. People are spending that one-on-one time in therapy instead of in planning. It is a huge hidden cost to all of that and it's really demotivating. It drives home like it is a reminder that Okay, this is just a business obligation. This is not a lifestyle choice and if me putting in extra doesn't give me extra safety on this Then what's the point? You know and like it There's a lot of cultural like baggage that happens for that and it's one of the things that I actually really liked about Adobe was Adobe's had the same CEO for a long time He just stepped down. He has a replacement now, but he was there for like the great recession crash

59:43and they did some layoffs at that era. And he saw how much it hurt morale and company productivity and all the rest of that. And he learned, like, we thought it made numeric sense at the time, but it was not good for the soul of the company. And that's not the company that we want to beat. And so Adobe didn't have the layoffs in the last few years. Like, there's group by group, like local things as things get reaped.

1:00:09prioritized, but it's not the sweeping. Yeah, we've seen that most of Big Tech has had it, especially in 2023. Speaking of Adobe, so you've moved to Adobe a few years ago. What are you focused on at Adobe? So there I'm very senior, I see focused on developer experience. I happen to say this is a polite fiction. Developer experience is the business of productivity.

1:00:33We just know enough not to say that we can measure productivity. It does not give everyone. Unlike McKinsey, who me and Ken have bonded over. That's horrible. But we'll link it in show notes below. Yeah. So what do we need for tools and culture and all of the things to improve the experience of being a developer and make you more productive and efficient?

1:01:00Most companies spend more on engineering comp than anything else. So today you've been focused on this thinking about it and working on it for both that it will be but also to some extent at Google. What do you know today about developer productivity? How does this relate to AI, coding tool, output, metrics, all of that things? What is it that we can measure? What is it worth measuring? And what are things that are hard to know? Yeah.

1:01:27I mean, we've taken it as axiomatic that it is hard if not impossible to measure productivity because what are the units even? I had a while back a sort of clever idea and I use that as a loaded term. I had an idea that if we don't know what the units are, like economics has prior art for this, you have an index metric where you measure all of the things that might influence this and you come up with a way to effectively basket those together. And then you have a unit list, but directionally useful and useful over time, number that you can pin to. And my theory had been, so measure all of the things that we think are positive or negative indicators of something is going well. Releases, test coverage, number of PRs, everything.

1:02:26just cast a wide net. My initial formulation on this was, you know, the wisdom of the crowd's idea, right? Like no individual can estimate how many jelly beans are in the jar, but you get 100 people and you'll get real close. So we do a like, am I hot or not? Of like, which would you prefer? Like one release per week, more or X tests, right? And you run a bunch of iterations of that game with your, you know, relatively experienced engineers to work out the linear trade-offs between all of those factors. To figure out what matters more, right? To figure out what the is. You probably want to de-dupe some things because they're just going to be the same stat in a different package, right? But find the ones that have some non-linearity and then mush that all together, right? Now you have something that sort of gives you an aggregate, like this is kind of our productivity number.

1:03:24and Adobe is doing something along these lines, slightly smarter than my initial formulation. But then you can watch that track up or down over time for a given population. What I've realized is that won't capture everything in this post AI boom. And the reason that I came to that was a paper that I put out, the develop deploy operate paper recently, where One of the points in there is there's four forms of impact in tech. There's product success The stuff everyone talks about and everyone else is better at than I am like that that's not what people buy a product or use a product Whatever net promoter score revenue like all of this stuff, right? There's Compute efficiency, right? Like how much you're blowing on AWS, right? Or if you're years old that's all too well, right, you know or like even Like the Android team has a trade-off for

1:04:25if you can reduce the size of an application download by a megabyte, it makes a difference for many metrics, yes. Right. And so all of those things, that is a form of impact. Then there's engineering productivity, or we phrased it as engineering capacity, because if we save you 5% productivity gains, capacity gains, you don't get to spend that somewhere else. You just have more capacity on doing more engineering.

1:04:53or having slack time for innovation or picking up when something happens, that kind of stuff. Right. But they're not like dollar fungible. You don't get money in a different account. And then the fourth form of impact, and this ties back to the AI thing, fourth form of impact is changing the game, right? Strategic innovation, like research makes impossible things possible. Security makes incredibly bad things impossible, right? But if you change the nature of What is what we are doing the cost structure? Etc then that's a different game and the problem that I think that we see with AI even with a clever Met you know index metric approach to trying to capture the gestalt of productivity if you're not looking for the value of a given change is Substantially different then there's no way you'll ever be able to capture that in the signal right and we don't have anything that says

1:05:51the value of a change of this size has changed. For instance, it is entirely possible at this point, and I hang out in security spaces and do a lot of low-level C++ library stuff, you can write a JPEG parser in a couple of weeks with whatever additional features you need. That would be insane to say that word that sentence out loud three years ago.

1:06:19Okay, so what you're saying is what none of the measurements really capture is the possibility, the impact, the effort it is to do a massive innovation, which right now with AI is happening. And I'll give you also one example and tell me if this is what you mean with it. There's a friend who works at a CTO at a Nigerian company about like a midsize engineering company, they're a niche industry. And you know, like the CTO, they have been looking at like release frequency of the usual metrics, talk with their engineering team. Are they happy? Are they not? And of course, now they're adopting AI as well. They're seeing that, well, people are more efficient and just privately, this person was telling me like, look, like I kind of know that for a fact that we could probably do the same amount of work with like half the amount of people and then we could be casual positive.

1:07:13But of course, there's a morale thing, so he likes the people. I'm not sure I want the emotional package on me, but we can see some people are picking it up faster and slower. We left it at that. A few weeks later, I'm talking with this person that says, you wouldn't believe, but we're probably going to be casual positive. I'm like, how? Did you go ahead with the cut? He's like, no. What happened is one of our engineers came to me and said, we license this component. Think of a library. It's a binary.

1:07:42But that was written by a vendor in the space that has a high performance thing that they use in their software. It's a core part of it. And they have a revenue share where they pay like, I don't know, like five, 10, 15% of their revenue for this component. It's so important. It's obviously licensed, closed source, but it's really important that it would take them years of a five person or 10% team to write it. And it might or might not work. So it's not worth it.

1:08:07Then Jerry came and said, like, what if, what if we just gave the specs? Because they have all massive amounts of tests around this thing, a test harness. They gave it to AI. AI wrote a component to them, which is faster and better what they have. No prior domain knowledge. And at first they thought, well, maybe we'll open source it, but then they told the supplier and the supplier said, like, it's a huge business for them. They're paying them to not open source it and to give them the implementation, which they can re-license. And suddenly.

1:08:36The game was completely changed. If this person would have gone ahead with, let's say, the layoffs, this engine might have just got it and no one might have known that the game could be changed because of this. AI makes things crazy, things sometimes possible. Right, exactly. And so I think that this is the insight that tries to bridge the gap between, I have not seen a research-based number that says productivity post AI is up more than like 20 or 30 percent.

1:09:04But then everyone talks about like these 10x sort of experiences. I super don't think it's actually 10x but Yeah, but like how do you bridge that gap? And I think it's exactly this thing of a lot of the value of AI is not in doing the same thing faster it's doing a harder more valuable thing you wouldn't have even thought about and if your productivity measures are the logical equivalent of counting how many widgets are coming out of the factory. And then you start producing super gold-plated deluxe widgets. There's no way to measure that or track that over time because we just don't have the tracking of what's the value of this component or feature. And that also matches with talking with senior engineers that are like, yes, we're up 70% on amount of code. We're up 30% on outages. Number of features is the same.

1:09:59The thing that we can't know for sure is are the value of those features up because how do you do that? One challenge that AI is giving is entering the market for new graduates. There seems to be expectation.

1:10:20very eager to hire senior engineers who know how to use AI and they have taste and judgment and we have these things thrown around. It's not deliberate, but whenever I talk to the AI labs, they always tell me increasingly that they look for taste, judgment, agency, these kind of things. Let's go back to education, to computer science education. What are your views of how today's computer science education works?

1:10:45especially for how we know the industry is changing. And what are some of your ideas of what could possibly be changed? I will riff a little on my Bonafide's there to add some weight to this. So after the book, I got recruited into the ACMI AAAI work on setting the curriculum requirements for an undergraduate CS degree. So this is like the...

1:11:12professional societies saying these are the things that we need to be doing. And for the steering committee, for that work, I was on the steering committee, I was the only currently working engineer. Everyone else is acting. Okay. In some sense, because you know, it's what can we teach? And I managed mostly the software engineering requirements. But it does mean that I like I see exactly what the requirements are and have been living in that space for for years. And bluntly, and I gave a talk on this in a pre AI keynote, bluntly, most of the CS curriculum hasn't substantially changed since like 2000, maybe earlier. The average thing in the curriculum is exactly what was needed to build a database or an operating system in the 90s. That does sound good, does it? Not for a field that prides itself on innovation. And there's all of these things where like,

1:12:09I have to genuinely ask, are we teaching this because it is relevant and important? Or are we teaching this because it is tradition? Or we know how to teach it. Right. Or we know how to teach it. Because the history of software engineering or CS departments, we're only at 50, 60, 70 years for the earliest CS departments. This is a field that is way, way too young to be doing stuff out of tradition.

1:12:39Even pre-AI, I think a lot of this needs to be burned down because all of the curriculum requirements, all of the teaching has mostly been through accretion. We just throw more stuff in there and cut the amount of depth on the existing stuff by epsilon. I don't think that works. Even pre-AI, I was saying, the thing that I really want is you spend more time Practice and drill and actually become like a fluent programmer algorithmic thinker not you have a trivia understanding of a million different topics and now AI right like We guarantee like you can do all of an undergraduate degree without ever thinking If you can just feed it into an AI because it will do just fine on all of those programs and assignments and so

1:13:35A lot of what I'm pushing for is we need to get out of the code. We need to up-level substantially. You need to be able to read code and think as a systems thinker and algorithmically understand the structure and execution. But no one needs to implement a linked list. And we probably shouldn't even teach linked lists. It's way too slow. Memory is a slow thing.

1:14:05the more that we can refocus on design specification precision in saying what you want to happen, and then testing validation verification, making sure that the AI actually did the stuff that you needed to happen. If we can teach those things, then it's suddenly perfectly relevant for professionals.

1:14:31And I think the big question is, will that be CS? Or are we looking at CS enrollment is going to plummet? But software engineering programs are going to kick up because let's be honest, the stuff that's going to matter like in a AI era and still get a job is teamwork, communication, design, specification, testing, validation, right? Oh, that's a bunch of software engineering.

1:14:58And also building production software, especially with AI. I was talking with Peter Mattis, co-founder of Cockroach DB, Cockroach Labs. And he was telling me that during his college on the side, he built the GIMP. And he got a lot of opportunities afterwards. And then he built GTK Plus. And I was thinking, hang on, he did that on the side next to a CS degree. Would you not want just...

1:15:26throw aside computer science. I did computer science as well. But for a software engineering degree, would you not want to start on day one, especially with AI? People come in here and you build on one class, you build one software and the other build, you build a software with the team. On the third one, you extend the software. On the fourth one, because my experience being in a computer science thing, we did a bunch of theory. My favorite class was the one team-based class where we actually built software in the four years. There was one, only one.

1:15:56And then I took an extra class for a textual learn.net. And then when I got into a real world, it felt I was starting to scratch. I was thinking of all of these things, which were not taught at the time these days are, but the practice was missing. I had the theory, but I definitely did not have the reps. Right. And I would argue that the lead code interview was because of this, because Okay, how do you find signal that someone has put in the reps? Right. It's the students that were playing in the programming contest, right? Those are the ones that had enough time. Because that was the only reps that were kind of a little bit common that were open to engineers who didn't have software engineering expertise. Sorry. Right. Yeah. People with affinity for programming who did not have software engineering expertise. Exactly. Right. And so like it made perfect sense from that perspective for us to

1:16:52like ask those sort of lead code questions in the programming contest styles, not because we needed solutions to yet another breadth for search problem or reversing a linked list or any of that nonsense, but specifically because it was a proxy for you've been in an environment where you put in reps, whereas the amount of actual like programming time on task for an average degree is pretty modest. And, you know, you go back to 10,000 hours to mastery and Malcolm Gladwell. I think that's a Gladwell.

1:17:22And like, yeah, like, where are you getting the time? And if I think back of the boot camps that spun up in the from like early 2010s, they started to get really strong 2014 to 2017. What they did is a three month, three to six months, sometimes 12 months, but usually three to six months, they took people who had no prior computer science or programming experience. They started day one. Let's build an application.

1:17:50which was typically a front and then the back and they gave them the basics. It wasn't all that much, but that was three intensive months or six intensive months, but building a working web application from the ground up. And there was such a huge demand for software engineers that they got hired as a junior engineer level or almost as an apprentice level. But what they knew compared to computer science grads, they knew version control, they knew Git, they knew pull requests, they knew a database.

1:18:19They knew a front-end, they knew new Chrome developer tools. So they actually had a bunch of valuable skills in only three months that the people coming out from program in four years might or might not have had. It was more of a coin toss. Yeah, exactly. I've done the math. The number of hours in a CS degree is roughly equivalent to like 15 months on average of full-time employment. And that includes all of the theory stuff, all of the things that are questionably relevant and is similarly trying to take you from no experience to employable in either an industry or academic direction. That is compared to a six-month bootcamp. That's not a huge gap, especially when one of those is laser focused on, these are all things that are just immediately relevant and one of them is, here's some stuff that'll hopefully

1:19:18teach you how to think about these problems maybe, or less charitably, this was useful when I was a student. Also, can we just mention some of the most successful schools who are actually outside of the US? One of them, well, a lot of the schools are of course, you know, the usual suspects are very highly regarded from the MITs, the Stamphords and so on. But Waterloo in Canada, I was very surprised to see that a bunch of Silicon Valley companies have a high number of Waterloo grads. And I asked this on social media, like, what's almost Waterloo? They're up in Canada. Why is everyone hiring from there? So it turns out that Waterloo has this program where, yeah, they teach you computer science or software engineering. I'm not sure which one. But the main part is that they have

1:20:04Dedicated placements by the time someone graduates they will have had four placements slash internships at different companies And because they have the relationship this will often be the Shopify the meta this so you will get an engineer who? You know three months times four that's like a year working inside of these companies and that is the value Yeah, like it's not you can probably throw away the the three not not throw away, but but that is more valuable itself if you ask me from a I don't want to downplay the importance of theory, by the way, but from a hiring manager point of view, like, oh, yeah, I'll take that because that person will be up to speed. Wow, they work in different environments. They might even bring some ideas from day one to us. Yeah, I'm incredibly jealous of... I don't think it's just Waterloo. Like a lot of the Canadian schools are... This was just one example, by the way. Yeah, but yeah, a lot of the Canadian schools for CS have substantially stronger programs on internships and co-ops in a way that a lot of those degrees run...

1:21:01five years now. But I think it is a much stronger educational experience because there are some of those lessons like I will fully admit like there's stuff we did not put into the software engineering requirements because there's just no way to do that in the academic setting. Right. There's some lessons you're going to have to learn the real way like in the field. Even the you gave the example of like doing a project. I want us to do more projects.

1:21:27But I'm really nervous about there being one project course in most degrees because you know what no team has ever looked like a bunch of people with exactly the same level of background, right? Like it also gives the wrong taste about this is what teamwork is Like I'll take it. It's better than not doing it. But yeah, well, we have what we have and this system will hopefully with people like yourself and others will hopefully start to also change or just adapt to the times. But AI is right now here. And one big question, more experienced engineers are thinking about that we, we've learned to build software pre AI. We have a bunch of we know the fundamentals of many of us went through computer science. So we actually have a very strong theoretical understanding which we might or might not use some parts of it, but.

1:22:22What about for new grads? Now that they'll enter a workforce of just today with just the capability that we have, what do you think the fundamentals are that they should focus on? And what are the things that they should just rely on AI? There's always the question of like, should you just ask AI for this or should you learn the basics, right? Yeah. So I mean, I think the learn the basics is an entirely loaded question because nobody agrees on what the basics are.

1:22:47And that's fair Kent Beck said a couple months ago when we were last together Something like everyone that's currently working Has grown up in an era where there was a playbook like we know at least in theory the right way to do this and There's no playbook right now, right? So we all have to get a little comfortable of not knowing the answer and we certainly don't know the answer on What is still the basics the things that I think that the the juniors should be focusing on One, the resilience to avoid just copying your ticket into AI prompt and then trying to check in that result. If that is all that you are doing, you can be replaced with a very shell script. That is not a defensible advantage for you being on staff. I think it's really important to use AI to better yourself and to widen your input.

1:23:47but not to immediately produce all of your outputs. There's a metaphor that I really liked from about a year ago at a think tank. We called it Andrew's axe. And it's, if I go chop down a tree with an axe, I do not say that it was the axe that chopped down the tree. It's me that chopped down the tree. The AI, as much as we occasionally anthropomorphize it, is still a tool.

1:24:17and 1979 IBM training manual. A computer will never be held accountable. Therefore, a computer should not be making management decisions. The AI is still not accountable. The AI labs are not going to indemnify us for the mistakes that these things produce. So you have to be able to stand up for whatever your name is on for those pull requests. And that requires a lot more rigor and not cutting those corners and like that attention to detail.

1:24:47I think is really hard to train. Going back to the sort of the undergraduate version of this, the story, the scary story that I've been hearing from a lot of profs is the best students, like the B, B plus and above students, they are better than they ever have been because they have, yeah, because instead of relying on a TA that is available a couple hours a week and is one or two grades above them, they have an infinitely patient always available.

1:25:15incredibly well read, sometimes hallucinatory, tutor at the drop of a hat. They can always learn and explain and figure out. And they actually have the autonomy and the drive to use this. And the metacognitive resources to avoid that, like, I'm just going to copy and paste. The very worst students are somewhat better.

1:25:38because they used to not be able to do anything, but now they can produce slop. Yeah, they're just going to slop, yeah. Which is a bit hard to detect, but I get you. But everyone in the middle has kind of collapsed. They don't have that resilience. They would rather go to the party or play video games than do the homework. And so they're like, well, just this one time, I'll just get in the habit of doing this thing. And that slippery slope just gets worse, right? And so like, there are a lot of profs from decent schools that are like, Yeah, I don't know man. Like I'm not sure that anyone like below like that the vast middle everyone below be Might not understand how code works at all like the system is just not set up to be tracking that Sort of thing or at least giving them feedback for example alerting right those kind of things right and so a lot of the discourse initially was how do we prevent students from using these AI tools and I think that that's nonsense because it's echoes of

1:26:36We got high-level languages and there's compilers. But now you're not going to learn how to program in assembly. The industry is using it anyway. Right. They're going to be forced the pressure to use it harder in some places when they get a job. Well, in fact, it might be, it will for sure be a red flag if a new grad says, like, I've not used these tools. Like, come on, have you not, do you not want to work in this industry? It's an open secret what we're doing. We're publishing it on blogs and everywhere.

1:27:06Exactly right and so the line of well, we're gonna never let you use these tools cannot possibly hold I co-published a piece in communications of ACM with a bunch of academics this month That I think the opening line there is imagine forward to 2040 And we hold the line treating all use of AI as cheating but a generation of students AI you know, they've grown up with AI in the same way that the internet natives have grown up with the network, right? If we keep continue asking them these traditional questions about like, find a palindrome in this string or measure the volume of rainfall in this graph, right? Like, are they going to learn anything from a traditional CS degree? I think the answer is obviously no. So like, if we know that we cannot stay here and there's plenty of things that need fixing,

1:28:06Like let's burn it down and do something that matters and figure out how to use this appropriately and I think finding ways to assume that they're using AI and What are the new learning objectives and how do you make that still? Frictionful in the ways that cause them to think and learn about different things like almost certainly at a higher level right, but like that's actually the key to undergraduate education and curriculum design and assessment. Well, it sounds like whoever's so the the professors, the, the, the TAs of people who are designing these course, they also need to put a bunch of work because no one has this figure it out. You need to experiment. You need to first use the schools yourself. You need to come up with novel ways of creating an assignment, which you need to use AI to solve, but AI itself is not enough. How do you

1:29:04get the feedback you might need to put in more time let's say like sit down with someone afterwards and have them explain to you because again like interviews are also changing and one of the interviews that seem to be working well is when you're pairing with someone you're like video or in person you're using AI but you're explaining what you're doing and how right because now you cannot just fully fake it and go away give it to a friend or just have Claude do it you're now showing.

1:29:31your cognitive ability, the interviewer can push you into uncomfortable, you know, they'll get a gauge of like how expert you are and push you further and further and so on. Yeah, exactly. And at the undergraduate level, like there is some move towards more oral exams and those sort of things. But also I think a really simple solution is stop grading just the outcome, focus on the process, right? Like even if you don't come up with wildly harder Assess assignments for assessment stop grading just the code that they turned in grade instead What are the prompts that you used to get here? Also, what are the tests that you provided? Like how did you make sure that this thing is actually doing what you needed to do and like when you start focusing on like the Process that got you there instead of just the outcome like I think not only CS but most disciplines

1:30:30We've been using, go write a new essay on catcher and the rye. We don't need another essay on catcher. Go write a new link list. We don't need another link list. We've been using the artifact that's produced from that as a proxy for you put in the time and the struggle and faced the friction that we assume that you now have learned something. It might be more appropriate to just focus on, do we have evidence that you've struggled and learned?

1:31:00Turn in the whole package, right? Curriculums are designed by committees, which is for a good reason But if if you had Titus's software engineering school where you could yourself put together the curriculum and study course for an undergrad course of let's say three to four years How would it look like right now and and we're talking about getting engineers Ideally having engineers who can hit the ground running at software and engineering companies obviously using AI tools building software that kind of stuff Yeah, so I think the first course, like the first semester starts un-aided by AI. Like, we need to get you through at least the level that you can read code and have a vague idea of what's going on. Like, you can understand control flow and those sorts of things. I think there's some really interesting things on well-scaffolded and harnessed AI for educational purposes of we're intentionally not just going to give you the answer and

1:31:58in conjunction with if you're assessing the whole package and process of creation, then you don't need to worry about them going to chat GPT and just getting the whole answer. Some of that's covered. I mean, I'll be honest, I don't know. Nobody knows. There is no playbook, but one of the ideas that I've had is let's make CS0 like non-majors and majors alike intro to programs.

1:32:26like specifically how do you describe the inputs and outputs and structure and design of the interfaces, right? So we could talk about what's the difference between a checkbox and a radio button. When do you use a button versus some other UI widget for non UI things like what command line flags, positional parameters, how do you like interface these components specifically so that if that's the only class that you ever took, at least the AI vibe-coded slop that you produce for your own use cases is going to have a slightly more coherent, sensible design language and be more fit for purpose. I live in New York. The condo building I'm in has an app for the laundry broom and drives me insane because they use menu UI for button. The design language is completely wrong. Start with that.

1:33:25and then graduate kind of along the lines of what you're saying. If we want to move up into projects and teamwork and things like that, try to motivate them into themselves wanting to solve a bigger problem and then needing some background on, oh, this is how the web works. This is how a remote API or PC call works. You can't give people a solution to a problem they don't realize they have, right? And until they are trying to solve these problems, Those solutions that we present in theory are all just trivia. They're just isolated academic, not connected to anything. Like motivate that by like getting them into a situation where they need that as the answer first. And then you can provide that back. I also desperately want more projects for two reasons. I don't want the assignments to be there is a correct answer because that's not how the industry works.

1:34:25Mostly not how it research works and I want them to grade part of your grade is Critique of others like look at their outcomes or their code or both Right and be able to say like that was great Did you think about doing a different thing here and then also grade them on? Can you give feedback without being a jerk? Because psychological safety and teamwork right?

1:34:54All of this sounds like a lot of work except you can use AI to like do some of that analysis like Let's do the sentiment analysis Was that rude? Right things like that and like I think we could have a much more practical hands-on like and much more effective educational structure and I worry that that's going to be software engineering departments and not CS department and as closing for For grads right now college students sitting inside of CS program software engineering programs who are seeing okay It's it's more competitive to get into the industry tools are changing. What advice would you get in terms of tactics strategies to? Activities to do to maximize your chances of getting into the industry and then doing well there this might be risky, but Most of my success in life has come from not doing the thing that everyone else is doing

1:35:54Like it is really incredibly hard to stand out if you are just listening to what is a hot topic and chasing the same shiny thing that literally everyone else is doing right and So I think it is to thine own self be true right like find something that you are actually interested in and put in the time doing something that you care about Especially if it's weirder than what everyone else around you is doing because then you will have a novel story to tell your interviewer, you will be worth talking to at a cocktail party so that the startup founder is like, yeah, I want to take a risk on this kid. And the more time that you put into these things, the more expertise that you can bring to it, the better off you're going to be. I have a worry that with AI-assisted engineering, our emphasis on raw engineering skill is

1:36:51Dropping like you can get by with a lot less of that depth But the only way to replace that is you need to understand the problem domain that you're operating into a much deeper level And I think that that might actually lead to less Mobility in the industry like it's not I'm a C++ engineer or I'm a back-end engineer It's a I'm an engineer in embedded audio. Mm-hmm, right like you had understand those problem domains to a much deeper level, and that's your actual advantage. As closing, what's a book that you would recommend and why outside of your excellent book, of course? I mentioned it earlier, but I'll stick with it. Psychology of Software Teams by Cat Hicks, especially. There are a couple chapters in that that if I could have that downloaded into the brains of every leader around, I would be so happy. The brains in jars analogy is haunting.

1:37:49That one's a really good one. Well, Titus, thank you so much for this conversation. Thank you so much for having me. This has been a lot of fun. I'm glad I got to finally sit down with Titus, and this conversation did not disappoint.

1:37:58To start with, I knew that Google's codebase was large, but I had no idea we were talking about 250 million lines of just C++ code. And this was all pre-AI, so we're not talking about overly verbose codebases generated by AI. As comparison, Uber's mobile apps had codebases of about 1-2 million lines of iOS and Android code back in 2016, and Uber crowned a lot of business logic into those apps. How tight is it that the team cleaned up these foundations without using AI was also pretty educational.

1:38:26They build deterministic code generation tools to parse the code, match pattern, then generate edits. This is an approach that still could work more reliably even today than just asking non-deterministic AI to refactor a codebase, even though it is arguably more difficult to write advanced parsing logic on a codebase like Titus and Team did. I also appreciated Titus's view on where AI is helpful today.

1:38:48He mentioned this quote he heard from a senior engineer that said, We are up 70% on the amount of code, but we're also up 30% on outages. The number of features is the same. Well, that doesn't sound all that good. Where's the value from AI then?

1:39:02Titus says that we won't get all that much value from doing the same stuff we did before AI, but faster. The value is to be more ambitious and do harder things that we would never have attempted before AI. Finally, I hear a lot of worried for new grads in tech about how they'll get a job or not, especially when AI agents are so commonly used, but CS programs have not incorporated them into their program.

1:39:25Titus is one of the few engineers who has been part of a steering committee for the CS curriculum and says that this program needs to either change substantially and be more practice oriented or CS enrollment will plummet. Titus also says that it might make sense to finally have a software engineering curriculum that is focused on students getting far more experience building software with these modern tools. I don't think any of us has an answer to what will work.

1:39:49But having more people from the industry get more involved in refreshing the CS software engineer curriculum sounds like a step in the right direction to me. Check out the show notes for related to pragmatic engineer deep dives on Google's engineer culture, measuring developer productivity, and the impact of AI and software engineering. If you enjoyed this podcast, I greatly appreciate it if you left a rating on it and perhaps a review. Thanks a lot and see you in the next one.