与 Titus Winters 谈 Google 软件工程经验与 CS 教育改革

Brief Description

Titus Winters discusses engineering at Google, large-scale C++ refactoring, the readability mentoring program, team learning, developer productivity, and how AI should change software engineering education.

Table of Contents

• Opening highlights, sponsors, and early career
• Testing, sustainable change, and engineering feedback
• Abseil and refactoring millions of lines safely
• Sponsors and codifying engineering lessons
• Writing Software Engineering at Google and readability mentoring
• Teams, psychological safety, and learning
• Layoffs and the hidden cost to engineering culture
• Developer experience, productivity, and the value of AI
• Rethinking computer science and software engineering education
• Learning with AI, assessment, and practical curriculum design
• Career advice, domain expertise, and closing reflections

Opening highlights, sponsors, and early career

That was probably the largest refactoring task in human history. It was 200 or 250 million lines of C++ code with 250 million lines of first-party, not counting external dependencies, and 10,000 engineers probably at the time making edits to that code base in a month. What is readability review? When I left Google, I was kind of the overarching owner for the readability program. That might be the largest educational program in tech cuz there were tens of thousands of people participating in that at any given moment. Most of the CS curriculum hasn't substantially changed since 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 doesn't sound good, does it? Not for a field that prides itself on innovation. A lot of what I'm pushing for is we need to get out of the code. We need to up-level substantially. 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 in a AI era and still get a job is

What if an engineer who helped define the contents of today's software engineering curriculum said that most of this should be burnt down? An actual 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. In 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 graded on their prompts and tests, not the code.

And more. If you want to know what Google learned about engineering 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 Turbo Buffer, vector and full text search built 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. A lot of teams use Linear to ship changes from idea to merge in GitHub, all without leaving the tool. I sat down with Dima, an engineer on 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. Before the fix, Dima did not open his IDE. Instead, 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 Vercel 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. The 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's finished with all of this, he just self-approved the code and it's merged into GitHub, all without leaving Linear. If 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 happens, creating the issue, kicking off 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 6-month trial at linear.app/pragmatic. Titus, welcome to the podcast.

Thank you so much for having me. I'm so excited to have this one. It's It's awesome to do this in person again. Yes. Yeah, 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, right? My dad uh very insightfully knew that computers would be important. Like 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 you know whatever we could scrape together and afford. Uh 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 QBasic. And 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. Um that is actually a really well-regarded high school these days. I had no idea. And yeah, like just kind of self-taught initially uh pre-internet back when you had to really fight for it. Um but yeah, that set me on my path, that book. And then you after high school it was kind of obvious you went to college for it.

Yeah. Uh so I went to Harvey Mudd uh which is a great school with a mix of, you know, tech and liberal arts education. Um the kind of place that'll teach you to build weapons and teach you to not to use them, that sort of thing. And then I met my wife uh there and she was a 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.

Mhm. Um All righty. I did a kind of weird I had a very strange graduate experience, yeah, I spent four years at Riverside doing a PhD in CS Ed, kind of applied AI, educational data mining, computer science education. Um So, some of the earliest conferences on CS Ed research, I published there. And my uh 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 and teach all of the classes uh whenever there was a hole in the

Yeah, and we'll we'll we'll keep coming back to probably this like this education computer science thing throughout this thing. So, it's a we've talked before, so I know. But, let's let's jump next like you now graduated from college. You were looking for a job.

Yep. What did you find? Uh so, 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 DirecTV during the embedded system stuff on the set-top boxes.

Mhm. And then, after four years of that, uh we were done with grad schools, we were done with all of that. I took the offer to do Google interview. Uh got the offer. Uh decided not to go to the Bay Area. And they moved us to New York. So, we've been here ever since.

So, this is when the Google was opening an office here in New York. And that office was already open and reasonably big. This was 2010. So, I think there were a few thousand people there.

And then and in 2010, so Google was founded in '98. They went public in 2004. I remember that they started 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, Anthropic or last year OpenAI or the you know, like in the mid mid 2010s, Uber.

Yeah. How did you find the interview experience and getting an offer? Cuz it must have been pretty competitive at that point. It was competitive. I was a little surprised that they gave me the offer. I didn't 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 like precious vacation days. So, I flew up from San Diego the morning of instead of sensibly like

And then they would have paid for the hotel and everything. Yeah. I just didn't want to like I don't know. I'm an anxious person. I like my habits and routines and stuff. Getting up at 5:00 for a big interview is not a good plan, folks. Uh hot tip. Uh so, there were 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 in 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 of like, "Yeah, this is not the important part. Like, let's just talk." And so, yeah.

Eventually, they gave me the offer and yeah, moved to New York. you started up. And then you joined you got you got the nuclear hat. Uh-huh. Yep. Absolutely. It was

And so, what did you work on at Google when when you joined? Uh so, briefly, I was on and like I don't think that Google had the best placement for new hires necessarily.

Onboarding process as we say. That was a little rough cuz 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, uh so let's put you on this team that monitors the amount of traffic and where that is crossing the edge of the Google network." Uh which is actually a databases problem with networks as 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. Um and then almost immediately after that, like 2 months in,

I want to push a little bit back here already is like, "Come on." Like you're you're joining Google. You had like what? Like you had college. You had Yeah. 4 or 5 years of experience. When like you join a company, especially like a hot company, they said like, "All right, do X." And you're like, "Ah, I'm not really." They're like, "Would you not want to say like let let me just go deep into this to see why the why it's important for the business?" I am I am pushing back on you here.

No, yeah. No, please do. Always. I did what I could to learn, you know, from that team, for sure. Uh there was a little like interpersonal tension in some of those things.

Okay, so it already started a bit like that. You kind of had this nagging feeling. Yeah, like it was just like, "Yeah, this wasn't quite right." And then there was a like email that went out to all the engineers in New York saying like, "Hey, we're thinking about spinning up a new team that handles all of the old like C++ nuts and bolts infrastructure code that 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, you know, components. So, we would like people to maintain that." Uh and me and I don't know, nine or 10 other people like raised their hands, and I was the only person that showed up to like the second meeting. Uh so, I just kind of got onto that team.

Oh I get it. So basically I think the context is just important cuz I think, you know, folks hearing, "Oh, I'm joining this team." Like I didn't really like the first thing I think the difference the context that was missing is like first of all, Google was growing really quickly. New teams were starting up left and right. And also like moving teams was kind of fine, right? And you were more looking for like, all right, like you knew that this team, both for the what they were doing and 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 at DirecTV, there was stuff like build an API to do UPnP, like universal plug and play stuff, like local network RPC sorts of stuff.

Um remote procedure call? Yeah, right. And so it had been a lot of people teams were manually assembling like the XML structure for every request to like implement a single client call or something like that. It was like, we could do better, folks. And like I was probably a little too clever in the way that I assembled all of that API, but it was like it Yeah, like that was the thing that I liked.

This team, what was it more of initiative 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 would got actually pretty formal about your embedded to a particular team and head count is limited. It's a little chaotic, it's a little loosey-goosey about how those things work. I could actually be wrong about that cuz I was still, you know, new enough that the internals of how head count works might have been just not clear. But yeah, like moved over pretty quick, and boy, that was exactly the place for me.

All right, then tell me about it. Why Why was it the place? What kind of work can we imagine of like I mean, cuz it sounds like when you describe to me like taking random C++ stuff that people wrote at Google, like that sounds like the version of hell for me, like, you know, like as an engineer, especially to pre-add, right? Like understanding what another engineer at some point wrote who might have left and a team is using it and it's working for them like that it sounds like it's a lose-lose because if you take it over and you make a change and you break someone they'll be mad at you and uh if you do it and you do a great job they'll probably not even think about it cuz it just it's always worked it still works great.

Testing, sustainable change, and engineering feedback

Uh luckily the fear and the safety net for making changes had been pretty well established a couple years before this played out. Specifically and like this goes to topics that we'll get to in a second I'm sure. Specifically like Google already went through the phase of yes you have to write tests. Right?

In 2010 this was not an obvious thing in the industry. Right. But like I think the story is 2006 2007 uh 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 is Google obsession with tests and quality and all that. Uh-huh. So the core money making product was kind of handcuffed not being able to push around through 2006. Wow.

And circa 2006 almost anything that you did had some tendrils in like the front end or search or stuff like that the whole architecture and separation and like multi-app multi-product 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.

Wow. And so like everything was you know held up. So the release engineers like they banded together and they simply just said like you will not merge this change if there is not tests. Period. We do not care what VP says anything. We do not care how important this feature is. You will not do that. Like we will roll that back.

Yep. And like 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. Like this is beneath me.

And then so basically taking over or taking on maintenance or or even changing any a library C++ library, you had the test so you could have high confidence if you refactor these things all the test pass. Yeah, either it works or there was never enough test coverage.

Right, exactly. Right? And like And any day where it's a win because if you it's it's better if you expose the lack of test coverage and okay, you have a crash today, but tomorrow or a year from now you'll have twice as much traffic anyway.

Right, exactly. And like uh 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 uh I've said now for 10 years you know, your code base is sustainable if for any valuable change that comes along, you are capable of making that change safely, right? You may choose not to make that change, right? That could be technical debt or, you know, different product priorities or whatever. But if you're incapable of reacting to change, then you're placing a high bet or high risk bet that the change isn't critical or isn't important. And I hate to break it to people, but like security world has gotten real real bad in the last few years.

Like there is nothing that is not going to change. Like the strategic advantage of being able to change is incredible. 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 you know, my first weeks, my first months I'm just being afraid of pushing code changes cuz I worry this thing will break. I'll break production. That I'm working on a system that is just, let's say it's poorly engineered.

It could be the system is poorly engineered or it could be you there's some onboarding and mentoring that didn't happen there. Right? So one or the other problem.

One or the other for sure. And I think and this goes to some of the educational stuff, like we in undergrad, you 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.

Mhm. Right? And I think it's going to be for 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 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 grads they're 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 when when I went to my first workplace, I should remember this. This is really weird. Like, join the company, I did I built this project, and then nothing. And then I, you know, I do another thing and then nothing. And then I have a I have a one-on-one with the CEO of the company, and I'm thinking they're going to fire me cuz like clearly like I knew that I don't know like middle of the day like I was sometimes slacking off cuz I finished my stuff. In hindsight, I was pretty efficient, but I just finished my stuff and then I was just browsing the internet.

I told them, "I'm ready." And I was pretty sure like maybe I'll be reprimanded or something. And instead, told me like, "Oh, amazing job. Like, you've onboarded so quickly. We're so happy with you." And I was But the difference was that up until then I had years of getting direct feedback, and it didn't connect in my mind.

Yeah. The other part of that is like 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. Right? Whereas when you like become a more experienced engineer, right? Like, you're asking for feedback regularly, but it's just like a check-in 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. Like, "Oh, I hate that we've like given all of the new grads and all the junior engineers exactly the wrong instinct." So, go going back to Google, what is abseil? How do you pronounce it correctly?

Abseil. Abseil. Yeah.

Abseil and refactoring millions of lines safely

So, abseil was starting about 10 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 the 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 different 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 one single company?

And also not one mono repo, right? Increasingly, yeah. Exactly. Um and so, there's a bunch of work that's 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 who are not that familiar with What does multi-tenant mean inside of Google? Uh 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 oh, got it. Yeah, so like a like a way more and the Google could theoretically use it, something like that. That became not the hottest topic and they kind of dropped that idea after a year or two. Um but, the low-level components, like, if you wanted to share these things that were written internally in the mono repo, 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. Let'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 teddy 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 that would defend pretty strongly.

That was probably the largest refactoring task in human history. No way. Yeah, we had like 10 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're talking about cleaning up you're talking about cleaning up utilities and components that are in the middle of some of the highest use services in the world, Google search

Yep. Gmail Yep. Maps, you name it. All of it. Like if if 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. Uh and Google had that kind of I think that was the public number at the time. 10,000 engineers probably at the time uh 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. Like, it was It was a magically It was a great team.

I just want to put the 250 million lines of code in perspective cuz today with AI AI can generate like, you know, like we have crazy numbers. It can generate tens of thousands of lines of code in an hour, etc. And you can get to millions if if you want to. Honestly, just an agent can do it. However, pre-AI uh Uber's uh mobile application was about a million lines of code on iOS and on Android, and that was each written by 200 engineers for years. Bun uh runtime at Anthropic 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 3 million lines of code, and that will typically be hundreds of engineers writing it for several years.

So, in this in this The reason I was like 250 million, that is about 100 times more than I've heard for codebase. 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 lot of code when you take on an open-source component, but no.

No. No, that was all Googler authored. And uh so, we have some insight into uh how things go. Okay, so the largest refactoring history at that point in uh human history might have uh you're not expurgating likely.

I mean, I can't prove it, but I would be surprised. So, how Okay, when you have this You're in the middle of this 10 to 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. So, uh one of the things that had enabled any of this and that came out of having been on that the 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. But 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 transformation sort of thing.

AST? Uh abstract syntax tree. So like you take the parse tree. And you know, it's Google like map reduce. So if you do a map reduce over the code base uh 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. And so we had compiler assisted, you know, semi-automated 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. Uh this is like the auto formatter for many like C++ sorts of languages at this point. But it's like I 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 code base um because for any given code base 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 resync before something has gone out of sync.

Yeah. Right? Someone else edited something. Yeah, exactly. Merge conflicts, like parallel changes, that kind of stuff. Yeah, exactly. You know, you do not want at a, you know, 10,000-plus person company to be like, "Everyone stop touching the repo for an hour. Let me do this thing." Like that's not going to scale, right? And so the tech is you break all of like you figure out how to do your refactoring so that the old API and the new one can coexist in spelling.

Yeah. And then you parallelize, like just cut by like directory structure. Like, "All right, I'll send you this batch of updates, this batch of updates." So 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. Uh and then you delete the old thing, the new thing is the default, you move on with life. You just do that a few hundred times and your code base is in much better shape.

Yeah, wow. And then you're you're doing this all all 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

Exactly. They might be aware of you, but they shouldn't have to change their just as you said, slow down or Yep. But then we did get amazing feedback on some of this. Like

at first people are like, "What are you doing? How Why are you changing my code? This like I'm not okay with this." And very quickly they're like, "Oh, this is great." Like I go away, my code just gets better. Like and I don't need to worry about looking up like, "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. Like 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? Like 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. Cuz 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 uh language parsing and coming up with new ways where you could formally, maybe even formally or or at least prove that this thing will be correct, which is what most teams would not have the available capacity, even expertise to do. What everyone has the expert the capability to do right now is like, "Oh, AI, go and do this and do test and all this."

However, where I wanted to get to like rewriting with AI feels still feels so much more janky than what you did, which was so much more deterministic.

Yes. And I wonder if this technique that you used at Google might at some point spread or 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's already out there. Um in the Java space in particular, uh tools like OpenRewrite, like you basically uh it'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 uh it goes through and, you know, blasts through all your Java source files and does that update. Turns out AI tools are really, really good at generating OpenRewrite recipes, which is way cheaper on token consumption, and way more accurate, and much faster, and like auditable. Right? It is a substantially better pattern and I we've seen uh talks from I want to say Netflix and Uber, I could be wrong, um 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. In the C++ space actually, some good friends of mine have a startup right now. Uh it's called Brontosaurus uh that is specifically just about that sort of declarative rewrite pattern uh at 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. Uh 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 pro- parts of the problem that you can't solve or where to invoke the tool, things like that. But like if your whole architecture is token consumption for all time, it's probably a cheaper and more effective way to do

Yeah, I just recently heard a head of engineering tell me that they're using these AI code review tools which which are pretty good but very expensive and slow.

Right. 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. That which is cheap and repeatable and it will no longer take 30 minutes that the cost and also it's 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 uh inference AI several agents and say all right, can you come up with an improvement in our deterministic linting and help it. And the inspiration came actually from this person heard about how Uber actually I think it was uh heard heard me talk about when I joined Uber, I could barely commit my code the first the first week. It was so painful cuz the linter just kept rejecting it because Uber had this uh engineering culture that

Yep. pre-AI, whenever you saw something break, you just put a lint rule. Architectural rules were all in lint rules. You could not have something like we had our architecture and you could not inherit the wrong way cuz the linter would say like uh-uh, you cannot you cannot inherit from like a builder cannot inherit from a I don't know what a composer or whatever that was.

Yeah. No, I think it makes perfect sense. Like let's try to learn our hard lessons only once, codify those rules somewhere deterministic, apply them equally and appropriately and fairly like and leave the interesting parts of code review like make sure that the parts of code review that we're focusing on are only the things that humans need to be doing. Right? Which was true then. I don'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 is well spent.

Sponsors and codifying engineering lessons

Titus just made the case for learning the hard lessons once, then writing them as rules, and saving the human attention for the things that really need such. That is pretty much the same way you want permissions for AI agents to work, which brings us to our season sponsor, WorkOS. WorkOS provides the auth infrastructure that B2B and AI native companies need to sell to enterprise customers with SSO, SCIM, RBA, and now authorization for AI agents. WorkOS Airlock is 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. Clear-cut rules like no agent deletes cloud resources are run as plain code. For the fuzzier calls, an AI just evaluates the policy at runtime. You write those policies in plain English and Cloth can pull the ones you already have out of Notion or Jira and import them for you.

Your agents, whether that's Cloth or Devin, connect through 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. You can request early access at workos.com/airlock. I also want to mention our presenting sponsor, Turbo Buffer, a ridiculously scalable, fast, and cheap hyper search engine built on top of object storage. How often do you get to see a rewrite playing out in real time? With the TiKV 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 Turbo Buffer V3, is not yet in prod, but it already passes CI. And when the rewrite started in September, it was not nearly as performant as the current production version, V2. The TiKV team had been perf maxing 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. The V3 system is still slower in areas like full-text search, but only one to two times slower versus 100 times slower when this perf maxing started. And the TiKV 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 showing some very cool systems work over the next few weeks. But hang on, why is the team doing a full rewrite? It's because search is changing, and so is Turbo Buffer. TiKV started as a vector database, but it is no longer a vector database. It has evolved into a high-performance database for search. The V3 discards the 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 and just generally a very fast database. The Turbo Buffer team is keeping a work log of their journey and you can follow along at turbobuffer.com/v3. It's a blast to see how it's being built.

Writing Software Engineering at Google and readability mentoring

Speaking of hard hard lessons and documenting them, can we talk about software engineering 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 uh a little bit at the 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 cuz otherwise it'll be a little bit of like aliens came down and they're trying to give you something that doesn't make any sense in your world. Part of the reason that we had the hubris to like tackle that sort of task was because we had been doing this refactoring at scale, you know, everywhere. And when you run into everything that any engineer thought was a clever solution to their problem, it meant that the my cadre of weirdos has run into so many Oh, yep, I can see how you thought that was a good idea. Don't do that. Like more than more than anyone else out there.

Well, you're talking some of the most kind of battle-scarred people in the industry just just because you're working on these large-scale systems for such a long period 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 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. Um but it does mean I don't know. I'm kind of an outsider in that sense.

Well, interestingly enough, the I mean, the book is very very thorough on how it gets to production, but it does not cover the operational part, which I guess it's it's the history of the book.

There isn't a history book, which Well, then the this book would be like twice as long. How did you pull that 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. Um like try to get the expert on or an expert on given topics to contribute something useful. Uh and then the three names on the front of the book, myself, Hiram Wright, and Tom Limoncelli, Hiram and I were kind of the technical leadership for that. And Tom has is plenty technical, but is has been our tech writer friend for many many years.

Mhm. Uh so, he handled a lot of the like editorial, structural, organizational stuff. But Hiram and I had been the tag team of uh Hiram generated millions of edits uh and sent them to me for review, and I had the permissions to review almost everything in the code base. 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 trick was like finding the experts to write something high quality. Some of those were great from the start. A lot of that took a, you know, bit of goes right and stuff.

Iteration, yeah. Um the whole task was actually almost 2 years. Uh certainly not full-time. Like we were at most probably putting in quarter to half-time in most of that time. Um but yeah, like 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."

Yeah, and even today, uh 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 with a bunch of stuff that might not make as much sense. And you talk about things like monorepo, like the stringent code review process, how there's a readability process at Google, and maybe we can talk about that as as part of Google is the only company I know where for 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 that you had a Google had a readability review. What is readability review?

So, for any change that's going in, uh someone that is involved, either the author or the reviewer or author or a reviewer, has to have two different permission bits. First is that ownership thing. So, someone has to be in the list of people that is authorized to change these files. And the second is someone has to actually be certified in we believe you understand how to write idiomatic code in this code base in that language. And this is a step towards trying to make sure that everything is relatively consistent and that there's common patterns and you're not like reinventing the wheel uh because the strategic value of consistency and so the readability process is someone has to be certified for that. How do you get certified for that? And initially that came as employee number three sat down with every new employee and walked them through their first change.

That stopped scaling, so they got a bunch of other people to try to proxy being 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, like you're making little edits here and there, you're adding a feature or whatever. So, finding something that was meaty enough to like demonstrate in one go that you knew everything it was kind of hard and the whole thing felt a little bit more like a hazing ritual. And so, over the years uh I think the I think people in Java started it moved from that sort of one shot to being explicitly kind of a mentoring program. Uh you do your normal work and after your team has signed off on it, then we will round robin assign someone from the pool of 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.

Yeah. And if you're not and you choose not to learn any of the lessons, you will probably graduate very slowly, if at all. Uh and so that the whole thing kind of grew into that. And we expanded that sort of mentorship approach into all of the other readability languages and that's been the norm for a bunch of years. I haven't checked up on it since, you know, for at least a couple years, but

But it's very interesting because it feels to me like this turns code review into into just education in the depth of 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. Um but yeah, when I left Google, uh you know, almost 3 years ago, readability was kind like I was kind of the overarching owner for the readability uh program. I would argue that might be the largest educational program in tech or maybe in the world cuz there were tens of thousands of people participating in that like at any given moment.

And then you just participated by by joining Google then you had no choice. It wasn't like a 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 readability expert puts on you. Step two, you probably say like I'd like to get fewer comments on them if you're if you have any sense of pride cuz it's kind of embarrassing. And then step three is like, you know what? Okay, 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 through that 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 codebase, 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.

Teams, psychological safety, and learning

In the book, you write about the importance of a team, and I'll quote you. Uh 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 always the result of a spark of inspiration, followed by a heroic team effort. A great team makes brilliant use of a superstars, but the whole is always greater than the sum of the parts. But creating superstar team is fiendishly difficult.

Yeah. I don't think I wrote that chapter. It's in the book that you are a co-author of. So, uh 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 the 10x engineer, up to up to one up to 22 20 23.

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, and we are also hearing stories of individuals doing heroic efforts by themselves and with a bunch of AI agents. So, I just wanted to ask you how the concept of a 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 and the other direction forward, we're still managing that team of agents. And I've heard 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 be have done that. Like, we're asking them to do a thing with no no scaffolding or guidance. The alternative is you think of the AI and the agents as your tools, your IDE, but it is still you in conjunction with the team of humans around you. It's still team behavior. 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. Let us hold that line for a bit. Um, but uh yeah, like I think understanding, clear communication, and like being able to write things down and get it out of your head is still, you know, a substantial important thing. Like I Yeah, I think it is still unquestionably is still teams at the root of it. Software engineering is a team sport, period.

Also, I guess just one like pretty like naive way to just prove that this is probably still true is if we just look at some of the leading AI companies, the leading AI labs, the Anthropic's, the OpenAI's. When I talk to people there, I see standout individuals who are working as a team. You know, like Claude code, for example, they're they cleverly have a public face in front of both of them, Boris Cherney, who created it, and I think he did an amazing job. It makes it very relatable. This is a human, but there's a team behind Boris.

Yeah. And that team, you can when I met them, you can tell that they gel. They work together. They trust each other. You know, like at some point Boris will be on holiday.

Right. You will not know because things just happen. Right. Like you said the important keyword, right? Trust. Right. Like a substantial part of this is the psychological safety aspect of it. The other thing, which I think is natural for the AI labs, but hasn't been nearly as dominant for the rest of the industry yet, is you're learning as you go. And if you look at all of the research, you know, like Dora research on stuff or any research on productivity or team efficacy or any of those things, like at root it always boils down to culture, psychological safety, and the permission to learn. All right, it's the permission to admit that I don't know something. It is the incentive to learn from each other. It is the incentive to share your mistakes so that the team only has to do that once. Your lint rules or SRE postmortem culture, every effective structure and organization in tech is actually about information flow and learning.

And I think a really great perspective on that. Um I love Cat Hicks, uh the psychology researcher for tech. Like her book, The Psychology of Software Teams, is beautiful. And like she talks about, you know, these these things a lot, right? Um similarly, there's a platform engineering at Google book that some of my friends are putting out. This early release chapters on O'Reilly. I might have written the chapter on education for that.

Uh and So very surprisingly {slash} not surprisingly. Right. But yeah, like 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 because it's not a one-off game. It's a 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 5-10 years ago, we kind of would talk so much about it in engineering leadership circles. This was pretty well understood that you know, a good team feels a safe team. If you, for example, make a mistake, you cause an outage as an engineer, like literally, you push a code and that code causes outage. We should have a blameless postmortem where we don't say that, hey, Gergely pushed this code and he caused the outage cuz that's now, I mean, I feel terrible and but let's talk about, like for example, how could have we avoided this at a system level? Why did a test not fire? Why was it rolled out immediately when he was a new joiner on the team or she was a new joiner team like maybe some onboarding could have helped yada yada yada.

What how do you define psychological safety and why is it important? Especially just playing devil's advocate like when we're talking about smart engineers who know stuff like is it all that important to us cuz we should know our thing, right? I'm just like go I'm kind of removing my emotional

Yeah. Yeah. But here. Yeah. Uh we should know our thing. Sure. So I would say and it's been a little hard to like root this uh stat, but from talking with people in Dora, the research the one thing that I love was we can explain 30% of the variance in whether or not you your team will hit its goals based on how you score on psych culture questions, right? Like we could give you a 15 question true false or maybe Likert scale like but like a 15 question assessment for the team and predict 30% of whether or not you will hit whatever your goals are. That's insanity. All right? That is more powerful than any other signal. Like, okay. So 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 at the surgical team is my least favorite chapter in that book because it's structured as if we're only ever going to 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 hierarchical. 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 prisoner's dilemma, it's iterated prisoner's 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 like no one else can tackle. Right? This is the only way to like 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. And like that brings you straight back to psychological safety and learning culture, right? Like if it is a culture that highlights information sharing, learning, and growth you will succeed.

And you mentioned that the AI labs already take this for granted and I'm going to Because they don't know what they're like Well, I'm going to paraphrase it like with the AI labs have a few things going. First of all, business is booming. They are growing. Revenue goes up. Customers goes up. Funding goes up. Headcount goes up. Their teams are only ever expanding. They're in hypergrowth. Like we've seen companies like Netflix and Uber in hypergrowth, 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 am I 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 taken 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 company that might not grow like this, they might still be using let's say AI, but now there's less of an 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 let's go a 6% 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 not hanging on. It's now

Uh-huh. And you also you're now wary of maybe your teammates because now there's internal competition. You want to hog that project. Yep. And so this is a huge difference then.

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, we're scraping by and like you know, fighting for attention and success. And that's not a recipe for innovation and growth. Like that is a recipe for stagnation and just bad.

Layoffs and the hidden cost to engineering culture

One of the obvious things that I assume you know, is does not do good for psychological growth or is terrible for it is layoffs. Mhm. Can you tell me based on your observation and then we've seen right? Like you 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 all all this interest rates and over hiring during zero interest rates and growth kind of going down. Now some companies are are actually openly saying that it's AI. Some are not as openly, but we find out that meta for example wanted to reduce team sizes because they thought that I will be there. From 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 and people you talk with.

I mean, it's stressful. Like uh it I've had experiences of there being layoffs in the area and just it'll be weeks or months of every one-on-one starts with, "So, how are you doing?" Like, "How are you coping?" Like, there's this huge amount of yeah, negative performance influence of like, "Okay, we got to like emotionally support each other first before we actually even get back to doing like the work." And I am very skeptical that in the executive accounting on all of this that they're taking into consideration just the sheer amount of, you know, 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 like in therapy instead of in planning."

Uh it's 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. And they did some layoffs at that era. And he saw how much it hurt morale and company productivity and all of the rest of that and he learned like it 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 be. 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 re-prioritized, but it's not the sweeping all that

but we've seen that at most of big tech has had it especially in 2023. Yeah.

Developer experience, productivity, and the value of AI

And 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 IC focused on developer experience. I happen to say this is a polite fiction. Developer experience is the business of productivity. We just know enough not to say that we can measure productivity. It is not given

Unlike McKinsey who me and Ken have bonded over. Yeah. That was that's horrible. We'll put a link in the show notes below. Yeah. So, it's it's what do we need for, you know, tools and culture and, you know, all of the things to improve the experience of being a developer and make you more productive and efficient because most companies spend more on engineering comp than anything else.

So, today you've been focused on this thing about it and working on it for both at Adobe, but also to some extent at 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. I 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 sort of clever idea. Um and I use that as a loaded term. I had this idea that if we don't know what the units are, like economics has prior art for this, right? 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 like basket those together. And then you have a unitless but like directionally useful and useful over time like number that you can sort of like pin to. And my theory had been to measure all of the things that we think are positive or negative indicators of something is going well. Right? Releases, uh test coverage, number of PRs, right? Like everything, right?

Just cast a wide net. My initial formulation on this was uh you know, the wisdom of the crowds 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

Yeah. to work out the linear trade-offs between all of those To figure factors. out what matters more. Right? To figure out like what that is. You probably want to dedupe some things cuz they're just going to be the same stat in a different package. Right? But find the ones that have some non-linearity. Uh 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. And Adobe is doing something along these lines. Slightly smarter than my initial formulation. But like then you can watch that track up or down and, you know, 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, uh 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's that's not my job. Whether or not people buy a product or or use a product, whatever.

And net promoter score, revenue, like all of the stuff, right? There's compute efficiency, right? Like how much are blowing on AWS? Right? Or if you're shipping sensors and all that, so I know that all too well. Right. You know, or like even like the Android team has a trade-off for if you can reduce the size of a application download by a megabyte,

it makes a difference for many metrics, yes. Right. You know, and so like all of those things, like that is a form of impact. Then there's engineering productivity or we phrased it as engineering capacity because if we save you know, 5% productivity gains, capacity gains, you don't get to spend that somewhere else. You just have more capacity on doing more engineering.

Or having slack time for innovation or picking up when something happens, that kind of stuff. 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.

Oh, yeah. 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? We don't have anything that says the value of a change of this size has changed. So for instance, like it is entirely possible at this point, and I hang out in security spaces and do a lot of low-level, you know, C++ library stuff. You can write a JPEG parser in a couple weeks.

Yep. Right? With whatever additional features you need. That would be insane to say that word that sentence out loud 3 years ago. Okay, 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 right and I'll I'll I'll give you also one example that I and tell me if if this is what you mean with it is there's a friend who works at a CTO at an engineering company about uh like a mid-size engineering company. They're they're a niche industry. And you know, like this the CTO they have been looking at like release frequency, all 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 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 cash flow positive.

But of course there's a there's a morale thing." So he's like also like he likes the people. So he's like, "I don't I'm not sure I want the emotional baggage on on me. But we can see some people are picking it up faster and some slower. And we kind of left it at that." A few weeks later I'm talking with this person and says like, "You wouldn't believe, but we're probably going to be cash flow positive." I'm like, "How? Like did you go ahead with the cut?" He's like, "No. What happened is one of our engineers came to me and said like, "We license this component. Think of a library. Like it's a binary. But that was written by a vendor in the space that has a high performance thing that they use in their in their software. It's it's a core part of it. And they have a revenue share where they pay like I don't know like 5, 10, 15% of their revenue for this component.

It's so important. It's obviously licensed, closed source, but it's it's really important and it would take them years of a five-person or 10-person team to write it and it might or might not work. So it's not worth it." The engineer came and said like, "What if what if we just gave the specs? Cuz they have all massive amounts of test 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, the game was completely changed. Like if if this person would have gone ahead with, let's say, the layoffs, this engineer might have just got a and no one would 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%. But then everyone talks about like these 10x sort of experiences. I super don't think it's actually 10x, but

Um 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 that 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, you know, 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. The thing that we can't know for sure is are the value of those features up?

Because what's how do you how do you do that?

Rethinking computer science and software engineering education

One challenge that AI is giving uh is entering the market uh for new graduates. Uh there's now there seems to be this ex- expectation. Companies are very eager to hire senior engineers who know how to use AI and they have taste and judgement, 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, judgement, uh agency, these kind of things. Let's go back to education. Uh to computer science education. W- What are your views of how today's computer science education works, especially for how we know the industry is changing? And what are some of your ideas of what could what's uh possibly be changed?

I will riff a little on my bona fides there to like to add some weight to this. Uh So, after the book, I got recruited into the ACM IEEE AAAI work on setting the curriculum requirements for an undergraduate CS degree. So, this is like the professional 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 academic.

Okay. Yeah, in some sense, cuz, you know, it's what can we teach? Uh 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 years. And bluntly, uh and I gave a talk on this in a pre-AI keynote, uh bluntly, most of the CS curriculum hasn't substantially changed since like 2000, maybe earlier. Right? The average thing in the curriculum is exactly what was needed to build a database or an operating system in the '90s.

That doesn't sound good, does it? Not for a field that prides itself on innovation, right? And like there's all of these things where like I have to genuinely ask, like, are we teaching this because it is relevant and important, or are we teaching this because it is tradition? And the history of or we know how to teach it. Right. Or we know how to teach it. But cuz like the history of, you know, software engineering or CS departments, like we're only at 50, 60, 70 years for the earliest CS departments. Right? Like this is a field that is way, way too young to be doing stuff out of tradition. Even pre-AI, I was like, 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 uh accretion. You know, like we just throw more stuff in there and cut the amount of depth on the existing stuff by epsilon.

Yeah. Right? And like that I don't think that works. Even pre-AI, I was saying like the thing that I really want is like 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 Yeah. We guarantee like you can do all of an undergraduate degree without ever thinking uh if you can just feed it into an AI cuz it will do just fine on all of those programs and assignments. And so a lot of what I'm pushing for is we need to get out of the code. We need to up-level substantially. Like you need to be able to read code and think as a systems thinker and under- like algorithmically like 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 the way too slow. Right? Memory is a slow thing. The more that we can refocus on uh design specification, like precision in saying what you want to happen, and then testing, validation, verification, like making sure that the AI actually did the stuff that you needed to happen. Right? If we can teach those things, then it's suddenly perfectly relevant you know for professionals. And 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 And also building production software especially with AI there's no like I was talking with Peter Mattis co-founder Cockroach DB Cockroach Labs and he was telling me that during his college on the side he built the

Mhm. Yeah. And he got a lot of opportunities afterwards and then he built GTK plus and I was thinking hang on like he did that on the side next to a CS degree. Would you not want just throw 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 a 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.

Normal. And then I took an extra class for to actually learn dot net and then when I got into real world it felt I was starting from 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 contests, right? Those are the ones that had enough time on task.

that was that was the only reps that were kind of a little bit get common that were open to engineers who didn't have software engineering expertise. Sorry. Uh 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 like ask the sort of leak code questions in the programming contest styles, not because we needed solutions to get another breadth-first 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 the 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 in Malcolm Gladwell. I think that's in Gladwell. Uh and like yeah, like where are you getting the time?

And if if if I think back of the boot camps that have spun up in the from like early 2010s, they started to get really strong 2014 to 2017. What they did is that a 3-month 3 to 6 months sometimes 12 month, but usually 3 to 6 months, they took people who had no prior computer science or programming experience. They started day one, let's build an application which was typically a front end and a back end. They gave them the basics. It wasn't all that much, but that was a three intensive months or six intensive months of building a working web application from the ground up.

Yeah. And there was such a huge demand for software engineers that they got hired as a junior engineer level or almost at an apprentice level, but what they knew uh compared to computer science uh science grads, they knew version control, they knew Git, they knew pull requests, they knew they knew a database, they knew a front end, they knew new Chrome developer tools. So, they actually had a bunch of valuable skills in only 3 months that the people coming out from programming in 4 years might or might not have had. It was more of a toss.

Yeah, exactly. Like 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. Uh and that includes all of the theory stuff, all of the things that are you know like questionably relevant. Uh and is similarly trying to take you from no experience to employable in either an industry or academic direction. And like that is compared to a 6-month boot camp, right? Like that's 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 teach 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 were actually outside of the US? One of them well, a lot of the schools are of course you know the usual suspects are are very highly regarded from the MITs, the Stanfords and so on. But Waterloo in Canada, I was very surprised to see that all a bunch of Silicon Valley companies have a high number of Waterloo grads. And I asked this on social media, like what's what's up with 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 every they have dedicated placements. By the time someone graduates, they will have had four placements/internships at different companies.

And because they have the relationships, this will often be the Shopifys, the Metas, this. So you will get an engineer who you know 3 months times four, that's like a year working inside of these companies.

Yeah. And that is the value. Yeah, exactly. Like it's it's not you can probably throw away the three not not throw away, 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 I'll take that cuz 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 just one of example, by the way. Yeah, but uh yeah, a lot of the Canadian uh schools for CS have substantially stronger programs on internships and co-ops in a way that a lot of those degrees run 5 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 cuz 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 though you gave the example of like doing a project. I want us to do more projects, but 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, uh like I'll take it's better than not doing it, but there yeah.

Learning with AI, assessment, and practical curriculum design

Well, we have what we have, and this system will hopefully with people like yourself and others will hopefully start to also change or or just adapt to the times. But, AI is right now here, and one big question more experienced engineers are thinking about, like 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, what about for new grads? Now that they'll enter 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 were 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. And that's fair. Kent Beck said a couple months ago when we were last together, uh something like everyone that's currently working uh 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 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 juniors should be focusing on, one, uh the resilience to avoid just copying your ticket into AI prompts and then trying to check in that result. Right? Like if you're if that is all that you are doing, you can be replaced with a very short off-the-shelf script. Like 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 inputs, but 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. Uh we called it Andrew's Axe. And it's if 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, right, is still a tool. And 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 you know 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 I think is really hard to train.

Um 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+ and above students, they are better than they ever have been.

Mhm. Because they have Yeah, because instead of relying on a TA that is available, you know, a couple hours a week and is one or two grades above them, they have an infinitely patient, always available, incredibly well-read, sometimes hallucinatory tutor right at the drop of a hat, right? They can always learn and explain and figure out

And they actually have the autonomy and the drive to use this. Right. And the and the metacognitive resources to avoid that like I'm just going to copy and paste, right? The very worst students are somewhat better because they used to not be able to do anything, but now they can produce slop.

Yeah, they're just throwing slop, yeah. Right. Which is a bit hard to detect, but I get what Right. Uh 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 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 the vast middle, everyone below a B, 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, those kind of things, yeah. Right. And so a lot of the discourse initially was how do we prevent students from using these AI tools? And I think that's nonsense because it's echoes of like we got high-level languages and there's compilers. Like But now you're not going to learn how to program in assembly, right? Like the industry is using it anyway.

Right. They're going to be asked to use They're going to be forced to pressure to use it harder in some places when they get a job. Well, if that 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

Yeah. 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. Yeah, exactly, right? And so the line of well, we're going to never let you use these tools cannot possibly hold. Um I co-published a piece in Communications of ACM with a bunch of academics this month. Um the I think the opening line there is imagine forward to 2040. Uh 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 continuing 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? And 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.

Like 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.

Uh it sounds like whoever's uh so the professors, the TAs, the people who are designing these course, they also need to put a bunch of work because no one has this figured out. You need to experiment. You need to first use these tools yourself.

Yep. 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 get 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 cuz, you know, 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? Cuz now you cannot just fully fake it and go away. You give it to a friend or or just have Claude do it. You're you're now showing your cognitive ability. The interviewer can push you into uncomfortable, you know, they'll they'll they'll 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 sorts 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 need it 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, right? Like, we've been using go write a new essay on Catcher in the Rye. Like, we don't need another essay on Catcher in the Rye.

Go write a new linked list. We don't need another linked 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 like, 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 struggled and learned? Turn 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 3 to 4 years, how would it look like? Right now. 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 unaided 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 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 in 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, right? So, like some of that's covered. I mean, I'll be honest, I don't know. Nobody knows. There is no playbook, but

I want to get opinionated. I want to get opinionated. I So, one of the ideas that I've had is let's make CS zero, like non-majors and majors alike, uh intro to programs. Like 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, you know, 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 like slightly more coherent, sensible design language and like be more fit for purpose. Like, I live in New York. Uh the condo building I'm in has a, you know, there's an app for the laundry room.

And drives me insane because like they use like menu UI instead of a button, right? And like the just the design language is completely wrong. Start with that. And then graduate kind of along the lines of what you were saying of like we want to move up into like projects and teamwork and things like that. Try to motivate them into in themselves wanting to solve a bigger problem. And then needing some background on, "Oh, this is how the web works. This is how a web remote API RPC call works." You can't give people a solution to a problem they don't realize they have, right? And until they're 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 background. 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. Mostly 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 in teamwork, right? And all 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's going to be software engineering departments and not CS departments.

Career advice, domain expertise, and closing reflections

And as closing for grads right now, college students sitting inside of CS programs, 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 give 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. Like 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, you know, startup founder is like, yeah, I want to take a risk on this kid, right? Like and the more time that you put into these things, the more expertise that you can bring to it, like the better off you're going to be.

I have a worry that with AI-assisted engineering, our emphasis on raw engineering skill is dropping. 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 might actually lead to less mobility in 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. Right? Like, you have to understand those problem domains to a much deeper level, and that's your actual advantage.

As a closing, what's a book that you would recommend then why outside of your excellent book, of course? I mentioned it earlier, but I'll stick with it. Uh Psychology of Software Teams by Cat Hicks. Especially, like, there are a couple chapters in that if I could have that downloaded into the brains of every leader around, I would be so happy. Like, the brains in jars analogy is um haunting. So, that 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. To start with, I knew that Google's code base was large, but I had no idea we're talking about 250 million lines of just C++ code. And this was all pre-AI, so we're not talking about over the verbose code bases generated by AI. As comparison, Uber's mobile apps had code bases of about 1 to 2 million lines of iOS and Android code back in 2016, and Uber crammed a lot of business logic into those apps. How Titus and the team cleaned up these foundations without using AI was also pretty educational. They built deterministic code generation tools to parse the code, match patterns, then generate edits. This is an approach that still could work more reliably even today than just asking a non-deterministic AI to refactor a code base, even though it is arguably more difficult to write advanced parsing logic on a code base like Titus and team did.

I also appreciated Titus's view on where AI is helpful today. He 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? Titus 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 attempted before AI. Finally, I hear a lot of worry 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. Titus is one of the few engineers who has been part of the 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, but having more people from the industry get more involved in refreshing the CS software engineering curriculum sounds like a step in the right direction to me. Check out the show notes for related to the pragmatic engineer deep dives on Google's engineer culture, measuring developer productivity, and the impact of AI in software engineering. If you enjoyed this podcast, I'd greatly appreciate it if you left a rating on it and perhaps a review. Thanks a lot and see you in the next one.