# Rebuilding CS Education and Engineering for the AI Era

**Podcast:** The Pragmatic Engineer Podcast
**Published:** 2026-10-29

## Transcript

What if an engineer who helped define the contents of today's software engineering curriculum said that most of this should be burned down?
An ex-Google software engineer says exactly this.
In 2023, Titus Winters was the only active software engineer on the steering committee for the ACM and IEEE undergraduate CS curriculum.
Before, he spent more than 10 years at Google, was the lead author of the book Software Engineering at Google, and ran the company's readability program.
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 tightest would change computer science education, including why they'd want students to be created 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 TurboBuffer, vector and full textures 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 the Linear team to see how devs inside of Linear use Linear to build all of Linear.
So here's a real issue.
When you submit a review with unsent draft comments, Linear warns you about these comments.
But it doesn't tell you where those drafts are.
A customer complained and Dima decided to fix it.
But for the fix, Dima did not open his ID.
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 this screenshot.
In the PR, there's a versatile preview.
You can open the preview with one click from Linear to play around with the change, and we see that it worked.
And here's my favorite part, Guided Reviews, which is work in progress.
Guided Reviews is a new code review experience where the important stuff just pops out.
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 is finished with all of this, he just self-approves the code and is 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 out the agent, checking out the preview, doing the review, and merging to production.
Linear is the product development system for teams and for AI agents, and I'm loving this evolution.
Check it out and get a six-month trial at linear.app.
Titus, welcome to the podcast.
Thank you so much for having me.
I'm so excited to have this one.
It's awesome to do this in person again.
Yeah, it's a joy.
So how did you get into tech?
Growing up, did you know that you're going to do something with computers?
I mean, my earliest memories, I thought I was going to be a scientist.
But like, you know, as a three year old, that means like lab coats and test tubes and I don't know what else.
My dad.
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.
And then I remember I really got my start.
I think I was around 11 or 12.
And instead of buying candy for everyone for Valentine's one year, he went to the bookstore.
And I don't know what my brother got, but I got a book on Learn Q Basic.
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 that is actually a really well regarded high school these days.
I had no idea.
And yeah, like just kind of self-taught initially pre-internet.
back when you had to really fight for it.
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.
So I went to Harvey Mudd, which is a great school with a mix of, you know, tech and liberal arts education.
The kind of place that'll teach you to build weapons and teach you not to use them, that sort of thing.
And then I met my wife there and she was a...
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.
I did a kind of weird, I had a very strange graduate experience, but yeah, I spent four years at Riverside doing a PhD in CS ed, kind of applied AI, educational data mining, computer science education.
So some of the earliest conferences on CS ed research I published there.
And my 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 the classes whenever there was a hole in the yeah and and we'll we'll keep coming back to probably this like this education computer science thing throughout this thing so i guess we we've talked this first so i know but let's let's jump back so like you you you now graduated from college you were looking for a job yep what what did you find 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 doing embedded system stuff on set-top boxes.
And then after four years of that, we were done with grad schools.
We were done with all of that.
I took the offer to do a Google interview, got the offer, decided not to go to the Bay Area, and they moved us to New York.
So we've been here ever since.
This is when Google was opening an office here.
The office was already open and reasonably big.
This was 2010.
So I think there were a few thousand people there.
And then 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, Entropic, or last year, OpenAI, or the, you know, like in the mid-2010s Uber.
How did you find the interview?
experience and getting an offer?
Because it must have been pretty competitive at that point.
It was competitive.
I was a little surprised that they gave me the offer.
I felt like I didn't do that great.
I remember for some stupid reason, I really, really didn't want to spend a bunch of precious vacation days.
So I flew up from San Diego the morning of.
Instead of sensibly like, you know, they would have paid for the hotel and everything.
Yeah, I just didn't want like, I don't know.
I'm an anxious person.
I like my habits and routines and stuff.
Getting up at five for a big interview is not a good plan, folks.
Hot tip.
So there are a couple of 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 and started up.
And when you joined you got the nuclear hat.
Yep, absolutely.
And so what did you work on at Google when you joined?
So briefly, I was on and like, I don't think that Google had the best placement for new hires necessarily.
Onboarding process, as we say.
That was a little rough because like I said, the things that I'm interested in are like developer efficiency, problem solve.
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.
And 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, which is actually a databases problem with networks as the topic of all of the data that you're doing.
Like, I don't know anything about databases.
That was never my thing.
So it wasn't a great fit.
And then almost immediately after that, like two months in.
I want to push a little bit back here already.
It's like, come on, like you're you're joining Google.
You had like what?
Like you had college, you had four or five years of experience when like you joined a company, especially like a hot company.
They said like, I do X and you're like, I'm not really there.
Like, would you not want to say like, let me just go deep into this to see why the what's important for the business?
I am pushing back on you here.
Yeah, no, please do.
Always.
I did what I could to learn, you know, from that team for sure.
There was a little like interpersonal tension in some of those things.
Okay, so it already started a bit like that.
You could have 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 components.
So we would like people to maintain that.
And me and I don't know, nine or 10 other people like raised our hands and I was the only person that showed up to like the second meeting.
So I just kind of got onto that team.
oh i get it so so basically i think the context is just important because 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 and you were more looking for like all right like you knew that this team both for 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.
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-in Plays.
It was like local network RPC sorts of stuff.
Remote positive call.
Yeah.
Right.
And so it had been a lot of people.
Teams were manually assembling like the XML structure for every request to like implement a single client call or something like that.
It was like we could do better folks.
And like I was probably a little too clever in the way that I assembled all of that API.
But it was like, yeah, it was a 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 got actually pretty formal about you're embedded to a particular team and headcount is limited.
It's a little chaotic.
It's a little loosey-goosey about how those things work.
Okay.
could actually be wrong about that because I was still, you know, new enough that the internals of how headcount works might have been just not clear.
But yeah, like moved over pretty quick and boy, that that was exactly the place for me.
All right.
So tell me about it.
Why was it the place?
What what kind of work can we imagine of like I mean, because it sounds like when you describe to me like taking random C++ stuff that people wrote at Google, like that sounds like the version of hell for me, like, you know, like as an engineer, especially pre-AI, right?
Like.
understanding what another engineer at some point wrote who might have left and a team is using and it's working for them.
It sounds like it's a lose-lose because if you take it over and you make a change and you break someone, they'll be mad at you.
And if you do it and you do a great job, they'll probably not even think about it because it's always worked.
It still works.
Great.
Luckily, the fear and the safety net for making changes had been pretty well established a couple of years before this played out.
Specifically, and this goes to topics that we'll get to in a second, I'm sure.
Specifically, like Google already went through the phase of, yes, you have to write tests.
Right.
In 2010, this was not an obvious thing in the industry.
Right.
But like, I think the story is 2006, 2007.
Search lost the ability to push a release on a regular cadence.
Like it was down to.
Like we were trying for monthly and they were maybe only get once a quarter because.
Oh, so this is why it's Google obsession with tests and quality and.
So the core money making product was kind of handcuffed, not being able to push around to 2006.
Wow.
And circa 2006, almost anything that you did had some tendrils in like the front end or search or stuff like that, the whole architecture and separation and like.
multi-app, multi-products, like, world, that was still not, right?
So if you were making changes to Gmail, there were still chances that you were, like, making changes to search.
And so, like, everything was, you know, holed up.
So the release engineers, like, they banded together and they simply just said, like, you will not merge this change if there is not tests, period.
We do not care what VP says anything.
We do not care how important this feature is.
You will not do that.
Like, we will roll that back.
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 even changing any library, C++ library, you had the test.
So you could have high confidence if you refactor these things, all the tests pass.
Yeah.
Either it works or there was never enough test coverage.
Right.
Exactly.
Right.
And like in any other way, it's a win, because if you it's better if you expose the lack of test coverage and OK, you have a crash today, but tomorrow or a year from now, you'll have twice as much traffic anyway.
Right.
Exactly.
And like it's one of the things that I believe very deeply is if you are held back from making changes to a thing out of fear, you have to go in and fix that.
Like fear is not an acceptable basis for engineering.
And I think it's in the first two or three pages of the book.
I've said now for 10 years, 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 joined a 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 because I worry this thing will break.
I'll break production that I'm working on a system that is just, let's say, poorly engineered.
It could be the system is poorly engineered or it could be there's some onboarding and mentoring that didn't happen there.
So one or the other problem.
One or the other for sure.
And I think 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.
Right.
And I think it's going to be, especially for new grads, it's really hard.
It's really easy to get into a fear of like, I don't know if I did this right.
I don't know if this was the answer you were looking for because they've been falsely given this.
perspective that there's a right answer instead of, of course, it's just a trade-off, right?
It's at some point in the design space.
And I guess you're also saying that these new grads are also used to you do something that's 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 I went to my first workplace, I should remember this really weird, like, join the company.
build this project and then nothing.
And then I, you know, I do another thing and then nothing.
And then I have a, I have a one-on-one with the CEO of the company and I'm thinking they're going to fire me because like clearly, like I, I knew that I don't know, like middle of the day, like I was sometimes slacking off because 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 re-imprated or something.
And instead, They'll be like, oh, amazing job.
Like you've onboarded so quickly.
We're so happy with you.
But the difference was that up until then, I've had years of getting direct feedback and it didn't connect to my mind.
Yeah.
The other part of that is 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 of like, are we going in the right direction?
Does this make sense to you?
Right.
And the more of that feedback that you can get that isn't judgment, the more effective you will be.
I'm like, oh, I hate that we've like given all of the new grads and all the junior engineers exactly the wrong instinct.
So going back to Google, what is Abseil?
How do you pronounce it?
Abseil.
Yeah.
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 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 or one single company?
And also not one on a repo, right?
Increasingly.
Yeah, exactly.
And so there was a bunch of work that was kind of the normal, like, okay, what does it take to make these developer tools like multi-tenant and like, you know, slightly less completely tied into that ecosystem.
And just multi-tenant for those who are not as familiar.
What does multi-tenant mean inside of Google?
Well, so this would have been multi-tenant of other companies within the Alphabet umbrella and then maybe extend that out to cloud customers.
Oh, got it.
Yeah, so like a way more.
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.
But the low level components, like if you wanted to share these things that were written internally in the monorepo, what would it take to do that effectively?
And Abseil was basically here is the layer of common like C++ idiom.
Like this is the vernacular that everything at Google is written out of.
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 daddy.
Should we clean that up before we commit to it forever?
And the answer was yes to their great credit.
So the Abseil open source project is the public like projection of the stuff that got cleaned up.
Most of the work was that was I would.
defend pretty strongly.
That was probably the largest refactoring task in human history.
No way.
Yeah, we had like 10 or 12 people working full time with world class tools that no one else understands yet, just cleaning up and making sure that idiomatic code externally would be compatible with idiomatic code internally.
And obviously when you were talking about cleaning up, you're talking about cleaning up utilities and components that are in the middle of some of the highest used services in the world.
Google search, Gmail, Maps, you name it.
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.
Google had that kind of...
I think that was the public number at the time, 10,000 engineers probably at the time, making edits to that code base in a month.
And so our job was, we joked about, that's a New York reference.
We joked about it as our job is the logical equivalent of Google has a new technology for the skyscraper foundations.
We're replacing the foundation under the Empire State Building.
We're not allowed to close the building or block traffic.
And we discovered nuclear waste in the basement.
It's okay, guys, we got this.
It was magically, it was a great team.
I just want to put the 250 million lines of code in perspective because today with AI, AI can generate, like, you know, we have crazy numbers.
It can generate tens of thousands of lines of code in an hour, et cetera.
And you can get to millions if you want to, honestly, just an agent can do it.
However, pre-AI, Uber's mobile application was about a million lines of code on iOS and on Android.
And that was each written by 200 engineers for years.
Bunn runtime at Antropic 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 the reason I was like 250 million, that is about 100 times more than I've heard for code base.
And we're talking about like, Clearly, this is written for production.
You're not just goofing around and pushing some scaffolding here and there and right.
And when you said first party, it's easy to have a lot of code when you take on an open source component, but no.
No, no.
That was all Googler authored.
Yep.
And so we have some insight into how things grow.
Okay, so the largest refactoring history at that point in human history might have, you're not extricating.
I don't think so.
I mean, I can't prove it, but I would be surprised.
So how, okay, when you have this type, you were in the middle of 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 one of the things that had enabled any of this and that came out of having been on 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 space.
AST.
Abstract syntax tree.
So like you take a parse tree and, you know, it's Google, like MapReduce.
So if you do a map reduce over the code base where the mapper parses all of the translation units of your C++, like all of the build targets, and produces here is the parse tree, then you can match the parse tree for specific, like, it's not text match.
It's I guarantee you are calling this particular function in this particular context.
And then you can apply some code to rewrite based on that.
And so we had compiler assisted, you know, semi-automatic refactoring to generate all of the text edits.
Turns out one of the things that was really hard at first was we could generate the edit, but we couldn't get the white space in the right places.
No way.
Yeah, seriously.
So Clang format exists because I wished for it.
This is like the auto formatter for many like C++ sorts of languages at this point.
But it's like.
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 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 re-sync before something has gone out of sync.
Someone else edited something.
Yeah, exactly.
Merge conflicts, parallel changes, that kind of stuff.
Yeah, exactly.
You do not want at a 10,000 plus person company to be like, everyone stop touching the repo for an hour.
Let me do this thing.
That's not going to scale.
And so the tech is you break all of, you figure out how to do your refactoring so that the old API and the new one can coexist in spelling.
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, and you wind up, you know, going like that.
And then once everything is clean, then there's a race to make sure no one copy and pastes the old thing.
And then you delete the old thing.
The new thing is the default.
You move on with life.
You just do that a few hundred times and your code base is in much better shape.
Yeah, wow.
And then you're doing this all the while other engineers, they're just doing their thing.
They're using these things they don't even know about.
They don't want to know about you.
I mean, they might be aware of you, but they shouldn't have to change their, as you say, slow down or.
Yep.
But we did get amazing feedback on some of this.
Like, at first, people are like, what are you doing?
Why are you changing my code?
It's like, I'm not okay with this.
And very quickly, they're like, oh, this is great.
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.
Because 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 asset 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.
language parsing and coming up with new ways where you could formally, maybe informally, or at least prove that this thing will be correct, which is what most teams would not have the availability capacity, even expertise to do.
What everyone has the capability to do right now is like, oh, AI, go and do this and do tests and all this.
However, where I wanted to get to, rewriting with AI still feels so much more janky than what you did, which was so much more deterministic.
And I wonder if this technique that you used at Google might at some point spread or people will just put up with like AI kind of, you know, like it might or might not work.
I think if you're looking for it, it's already out there in the Java space in particular, tools like Open Rewrite.
Like you basically, there's a little configuration per run for it.
And you say like, this is the pattern I'm looking for in the Java code.
This is how the rewrite would look.
It goes through and blasts through all your Java source files and does that update.
Turns out AI tools are really, really good at generating open rewrite recipes, which is way cheaper on token consumption and way more accurate and much faster and like auditable.
It is a substantially better pattern.
And we've seen talks from, I want to say, Netflix and Uber.
I could be wrong.
Specifically on.
Like everyone seems to be coming to the same conclusion of what you need is a deterministic tool that declares the intent of the rewrite.
You can have the AI like write a little skill to 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 might have a startup right now.
It's called BrontoSource that is specifically just about that sort of declarative rewrite pattern.
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.
Kelsey Hightower gave a great talk recently on like zero token architecture and like his whole thesis.
And I think everyone is coming to the same conclusion.
Don't use AI for constant inference.
Use AI to generate the deterministic tool that will actually do the work and then have AI fill in the gaps on the parts of the problem that you can't solve or where to invoke the tool, things like that.
Like if your whole architecture is token consumption for all time, it's probably a cheaper and more effective way to do it.
Yeah, I just recently heard a head of engineering tell me that they're using these AI code review tools, which are pretty good.
but very expensive and slow.
And this person said, like, hang on, like, what if we told the AI, okay, like, let's do a thorough code review every now and then, but when it finds something, let's have it generate a lint rule.
Yes, please.
Which is cheap and repeatable, and it will no longer take 30 minutes, the cost.
And also, it's just non-deterministic.
It might or might not find it next time.
That was frustrating.
Like, this person was like, look.
when we know we have certain things.
So now what they're doing is every now and then they still run some of these reviews and of course, but whenever they find any issues, then they fire up inference AI, several agents and say, all right, can you come up with an improvement in our deterministic linting?
Can help it.
And the inspiration came actually from this person heard about how Uber, actually, I think it was, heard me talk about when I joined Uber, I could barely commit my code to first.
The first week, it was so painful because a linter just kept rejecting it because Uber had this engineering culture that 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 an architecture and you could not inherit the wrong way because a linter would say like, you cannot inherit from like a builder, cannot inherit from, 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 to Germanistic, 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.
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.
Titus just made the case for learning the hard lessons once, then writing the damals rules and saving the human attention for the things that really need it.
That is pretty much the same way you want permissions for AI agents to work, which brings us to our season sponsor, WorkOS.
WorkRest provides the auth infrastructure that B2B and AI-native companies need to sell to enterprise customers with SSO's Kim Arbak and now Authorization for AI Agents.
WorkRest AirLog is intent-based access control.
Most access control only asks who you are.
AirLog 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 Cloud can pull the ones you already have out of Notion or Gyra and import them for you.
Your agents, whether that's Cloud or Devin, connect to a single access point and your MCP servers are behind this access point.
Airlock is a new layer on top of your existing permissions, which means that an agent can never get more access than the person who invoked the agent.
When something risky comes up, Airlock can escalate to a 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 workerwas.com.
I also want to mention our presenting sponsor, TurboPuffer, a ridiculously scalable, fast and cheap hybrid search engine built on top of object storage.
How often do you get to see a rewrite playing out in real time?
With the Teepuff team, we finally can.
They are completely redesigning their storage architecture from first principles to make search faster, cheaper, and more reliable at scale.
The new system called TurboPuffer v3 is not yet in prod, but it already passes CI.
And when the rewrite started in September, it was not nearly as performant as the current production version, v2.
The TPUF team had been perf-mapsing 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 Teeph team is sharing exactly how they optimize things in their development logs with things like group count aggregation, compressed column encodings, batch scoring, and many more.
A lot of these wins are basic foundational work right now, but the team will be sharing some very cool systems work over the next few weeks.
But hang on, why is the team doing a full rewrite?
It's because search is changing and so is TurboBuffer.
TPUF 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 search and just generally a very fast database.
The TurboPuffer team is keeping a work log of their journey, and you can follow along at turbopuffer.com slash v3.
It's a blast to see how it's being built.
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 a little bit...
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.
Because otherwise it'll be a little bit of like aliens came down and you'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 my cadre of weirdos have run into so many, oh, yep, I can see how you thought that was a good idea.
Don't do that.
Like more than anyone else out there.
Well, you're talking some of the most kind of battle-scarred people in the industry, just because you're working on these large-scale systems for such a long...
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.
But it does mean, I don't know.
I'm kind of an outsider in that sense.
Well, interesting 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 is the SRE book.
But there is an SRE book, which well, then this book would be like twice as long.
How did you pull the book together?
Because you wrote some parts of it.
Other folks inside of Google wrote different chapters of it.
So it's very much in the spirit of the SRE books.
Like try to get the expert on or an expert on Gavin topics to contribute something useful.
And then the three names on the front of the book, myself, Hiram Wright and Tom Manchereck.
Hiram and I were kind of the technical leadership for that.
And Tom is plenty technical, but has been our tech writer friend for many, many years.
So he handled a lot of the like editorial, structural, organizational stuff.
But Hiram and I had been the tag team of.
Hiram generated millions of edits and sent them to me for review.
And I had the permissions to review almost everything in the code base.
And so everyone knew us as those two guys that clean everything up.
So we had those scars.
And so we led that.
And then the trick was finding the experts to write something high quality.
Some of those were great from the start.
A lot of that took, you know.
bit of ghostwriting stuff.
The whole task was actually almost two years.
Certainly not full time.
Like we were at most probably putting in quarter to half time most of that time.
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.
And I was like, wow, that's huge.
Yeah.
And even today.
I do recommend the book because it gives a really good understanding of how the Google at the time worked.
Obviously, there's been evolving since, but how a company going from zero to building important production systems came up 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.
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 Google had a readability review.
What is readability review?
So for any change that's going in, someone that is involved, either the author or the reviewer, or author or a reviewer, has to have two different permission bits.
First is that ownership thing.
So someone has to be in the list of...
people that is authorized to change these files.
And the second is someone has to actually be certified in, we believe you understand how to write idiomatic code in this code base in that language.
And this is a step towards trying to make sure that everything is relatively consistent and that there's common patterns and that you're not like reinventing the wheel because the strategic value of consistency is incredible.
And so the readability process is Someone has to be certified for that.
How do you get certified for that?
And initially that came as employee number three sat down with every new employee and walked them through their first change.
That stopped scaling.
So they got a bunch of other people to try to proxy Bing Craig and they walk you through your first big substantive change.
And over time, it got to the point where most change was not like.
I am writing a new component from scratch.
It's an existing product.
Like you're making little edits here and there.
You're adding a feature or whatever.
So finding something that was meaty enough to like demonstrate in one go that you knew everything was kind of hard.
And the whole thing felt a little bit more like a hazing ritual.
And so over the years, I think the people in Java started it.
It moved from that sort of one shot to being explicitly kind of a mentoring program of.
You do your normal work and after your team has signed off on it, then we will round robin assign someone from the pool of 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.
And so the whole thing kind of grew into that.
And we extended that sort of mentorship approach into all the other readability languages.
And that's been the norm for a bunch of years.
I haven't checked up on it since, you know, for at least a couple of years.
But it's very interesting because it feels to me like this turns code review into just education in the depth.
of a programming language.
Yep.
Was this by design or was it just a byproduct?
I think it's absolutely by design.
Certainly at the parts of it where I was pulling any of the strings was definitely by design.
But yeah, when I left Google, you know, almost three years ago, readability was kind of like I was kind of the overarching owner for the readability program.
I would argue that might be the largest educational program in tech or maybe in the world because there were tens of thousands of people participating in that.
like at any given moment.
And then you just participated by joining Google and you had no choice.
It wasn't like voluntary.
Right.
And so certainly some people were super pissy about it.
But I guess there was also a goal where it wasn't just about like, OK, so step one is you need to address the comments that a Reasibility Expert puts on your.
Step two, you probably say like, I'd like to get fewer comments on them if you have any sense of pride because it's kind of embarrassing.
And then step three is like, you know what?
okay, I now get zero comments.
I actually want to become a readability expert myself.
And then that's a 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 code base, you see stuff that other people are doing, you learn about other tech that might be happening.
Like it was a huge, like subtle, below the waterline, like information sharing program.
In the book, you write about the importance of a team, and I'll quote you.
In the realm of programming, lone craftspeople are extremely rare, and even when they do exist, they don't perform superhuman achievements in a vacuum.
Their world-changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort.
A great team makes brilliant use of its superstars, but the whole is always greater than the sum of the parts.
But creating a superstar team is fiendishly difficult.
Yeah.
I don't think I wrote that chapter.
It's in the book that you are a co-author of.
So I wanted to reflect on this, especially with AI, because now I'm starting to hear a lot more people say, yeah, in the past, we talked about a 10X engineer up to up to one up to 22, 23.
Don't get me started on that.
But I am now starting to hear people say like, oh, there's now the 100X engineer, which is this engineer who is a great engineer, uses AI amazingly well.
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 the team holds up as we have more AI tools and the concept of a standout team.
Yeah.
So I think regardless of where you fit on the spectrum of like AI believerism, I think the team is still critical.
Like if you believe that the agents are the only.
answer in other direction forward, we're still managing that team of agents.
And I've heard an increasing number of voices talking about it as the problem right now is we need to make every engineer into an engineering manager for a team of agents.
And we don't have the training or skill set or background to have done that.
Like we're asking them to do a thing with no scaffolding and 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's hold that line for a bit.
But 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 Entropics, the Open AIs.
When I talk to people there, I see standout individuals who are working as a team, you know, like Claude Code, for example.
They cleverly have a public face in front of both of them, Boris Cherny, who created it.
And I think they do an amazing job.
It makes it very relatable that this is a human.
There's a team behind Boris.
Yeah.
And that team, you can, when I met them, you can tell the jail, they work together, they trust each other.
You know, like at some point, Boris will be on holiday and you will not know because things just happen.
Right.
Like you said the important keyword, right?
Trust, right?
Like a substantial part of this is the psychological safety aspect of it.
The other thing, which I think is natural for the AI labs, but hasn't been nearly as dominant for the rest of the industry yet, is you're learning as you go.
And if you look at all of the research, you know, like Dora research on stuff or any research on productivity or team efficacy or any of those things, like at root, it always boils down to culture, psychological safety and the the permission to learn.
It's the permission to admit that I don't know something.
It is the incentive to learn from each other is the incentive to share your mistakes so that the team only has to do that once.
your lint rules or SRE postmortem culture.
Every effective structure and organization in tech is actually about information flow and learning.
And I think a really great perspective on that.
I love Kat Hicks, the psychology researcher for tech.
Like her book, The Psychology of Software Teams is beautiful.
And like she talks about, you know, these things a lot, right?
Similarly, there's a platform engineering at Google book that some of my friends are putting out.
There's early release chapters on O'Reilly.
I might have written the chapter on education for that.
Very surprisingly slash not surprisingly.
Right.
But yeah, like education is the powerful route for like, let's make this mistake a minimum number of times.
Let's codify what we've done.
Let's give people permission to admit they don't know and to grow.
Because it's not a one-off game.
It's an iterated game.
And you'll do better over time if your team is better next time.
I want to go back to psychological safety because back about five, 10 years ago, we kind of talked so much about it in engineering leadership side circles.
This was pretty well understood that, you know, a good team feels a safe team.
If you, for example, make a mistake, you cause an outage as an engineer, like literally you push a code and that code causes outage.
we should have a blameless postmortem where we don't say that, hey, Gergay pushed this code and he caused the outage because that's now, I mean, I feel terrible.
But let's talk about, for example, how could have we avoided this at a system level?
Why did a test not fire?
Why was it roll out immediately when he was a new joiner on the team or she was a new joiner on the team?
Maybe some onboarding could have helped, yada, yada, yada.
How do you define psychological safety and why is it important?
Especially just...
Playing devil's advocate, like when we're talking about smart engineers who know stuff, like, is it all that important to us?
Because we should know our thing, right?
I'm just like, I'm kind of removing my emotional hat here.
Yeah, we should know our thing, sure.
So I would say, and it's been a little hard to like root this stat, but from talking with people in DORA, the research, the one thing that I love was we can explain 30% of the variants.
in whether or not your team will hit its goals based on how you score on culture questions.
We could give you a 15-question true-false or maybe Likert scale, but a 15-question assessment for the team and predict 30% of whether or not you will hit whatever your goals are.
That's insanity.
That is more powerful than any other signal.
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 not a single shot game, it's an iterated game.
I regularly cite Fred Brooks and the Mythical Man month essays, right?
And in the surgical team, like 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.
Have everyone else build the tools and do the documentation.
Be 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 no one else can tackle.
This is the only way to structure it so that growth happens.
But in order for that growth to happen, people have to be willing to admit that they don't know a thing.
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 probably 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, 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 on hyper growth.
We've seen companies like Netflix and Uber and hyper growth.
This is even faster.
Your equity also goes up.
So you don't need to worry about things like performance reviews because performance reviews are typically important where like how much bonus I'm going to get, how much.
But when you're at a place that goes like this and your equity goes up, your financial part is 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, OK, I don't know.
I'm learning from you.
Here's what I learned.
So it's just all natural.
Whereas compared to a company that might not grow like this, they might still be using, let's say, AI.
But now there's 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 6% of people.
And your goal is suddenly going from like, I just don't want to be there.
I want to hang on to this job, but it's now hanging on.
It's now, and you also, you're now very of maybe your teammates because now there's internal competition.
You want to hog that project.
And so this is a huge difference.
Yeah, it's huge.
Like if you get into the mode of believing that the team outcomes are what matter for your own success, then it is much easier for you to realize like, okay, I don't have to have this one shiny task.
Like the team will be successful by virtue of someone doing this.
And it might be my turn next.
If when it breaks down into that, like individualism and like, I don't trust the guy across the way from me or, you know, right shoulder to shoulder to me, like, even though we're on the same teamwork.
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.
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.
Can you tell me, based on your observation, and we've seen, right, like we've all been part of it, and in 2022, 2023, there has been a series of layoffs.
Right now, companies are doing it again.
Back then, it was to do with honest interest rates and overhiring during zero interest rates and growth kind of going down.
Now, some companies are actually openly saying that it's AI.
Some are not as openly, but we find out that Meta, for example, wanted to reduce scene ties because they thought that AI would 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, the people you talk with.
I mean, it's stressful.
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, you know, 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'm very skeptical that in the executive accounting on all of this, that they're taking into consideration.
Just the sheer amount of lost productivity and lost time from like, yeah, people are stressed.
People are spending time brushing up their resume in case they're next on the chopping block.
People are spending that one-on-one time like in therapy instead of in planning.
It is a huge hidden cost to all of that.
And it's really demotivating.
It drives home like it is a reminder that.
OK, 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, I 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 reaped.
prioritized, but it's not the sweeping.
Yeah, we've seen that most of big tech has had it, especially in 2023.
Yeah.
Speaking of Adobe, so you've moved to Adobe a few years ago.
What are you focused on at Adobe?
So there I'm very senior, I see focused on developer experience.
I happen to say this is a polite fiction.
Developer experience is the business of productivity.
We just know enough not to say that we can measure productivity.
It does not give everyone.
Unlike McKinsey, who me and Ken have bonded over.
Yeah, that's horrible.
We will link it in the show notes below.
Yeah.
So it's what do we need for tools and culture and all of the things to improve the experience of being a developer and make you more productive and efficient.
most companies spend more on engineering comp than anything else.
So today you've been focused on this, thinking about it and working on it for both at Adobe, but also to some extent at Google.
What do you know today about developer productivity?
How does this relate to AI, coding tool, output, metrics, all of that things?
What is it that we can measure?
What is it worth measuring?
And what are things that are hard to know?
Yeah.
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 a sort of clever idea, 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 unit list, but like directionally useful and useful over time, like number that you can sort of like pin to.
And my theory had been, so measure all of the things that we think are positive or negative indicators of something is going well, right?
Releases, test coverage, number of PRs, right?
Like everything, right?
just cast a wide net.
My initial formulation on this was, 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 to work out the linear trade-offs between all of those factors.
To figure out what matters more.
Right, to figure out like what that is.
You probably want to de-dupe some things because they're just going to be the same stat in a different package.
Right, but find the ones that have some non-linearity and then mush that all together.
Right, now you have something that sort of gives you an aggregate like this is kind of our productivity number.
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, 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 not my job.
We'll buy a product or use a product, whatever.
Net promoter score revenue, like all of this stuff, right?
There's compute efficiency, right?
Like how much are you blowing on AWS?
Oh, yeah.
Right.
Or if you're shipping.
That's all too well.
Right.
If you can reduce the size of an application download by a megabyte.
It makes a difference for many metrics, yes.
Right.
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, 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.
Right.
But they're not like dollar fungible.
Exactly.
You don't get money in a different account.
And then the fourth form of impact, and this ties back to the AI thing.
Fourth form of impact is changing the game, right?
Strategic innovation.
Like research makes impossible things possible.
Security makes incredibly bad things impossible, right?
But if you change the nature of...
what we are doing, the cost structure, et cetera, then that's a different game.
And the problem that I think that we see with AI, even with a clever 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.
And 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 C++ library stuff, you can write a JPEG parser in a couple weeks with whatever additional features you need.
That would be insane to say that sentence out loud three 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 I'll give you also one example that I, and tell me if this is what you mean with it.
There's a friend who works at a CTO at an engineering company about like a mid-sized engineering company, they're a niche industry.
And, you know, like the CTO, they have been looking at like release frequency, the usual metrics, talk with their engineering team, are they happy, are they not?
And of course, now they're adopting AI as well.
They're seeing that, well, people are more efficient and just privately, this person was telling me like, look, like I kind of know that for a fact that we could probably do the same amount of work with like half the amount of people and then we could be cashflow positive.
But of course, there's a morale thing.
So he's like, also like, he likes the people.
So it's like, I don't, I'm not sure I want the emotional package 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 that says like, you wouldn't believe, but we're probably going to be cashflow 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 software.
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 really important.
And it would take them years of a 5-person or 10-person team to write it.
And it might or might not work.
So it's not worth it.
Then you came and said, like, what if what if we just gave the specs?
Because they have a massive ounce of tests around this thing, a test harness.
They gave it to AI.
AI wrote a component to them, which is faster and better what they have.
No prior domain knowledge.
And at first they thought, well, maybe we'll open source it.
But then they told the supplier and the supplier said, like, it's a huge business for them.
They're paying them to not to not open source it and to give them the implementation, which they can relicense.
And suddenly.
Yeah, 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 it.
And no one might have known that the game could be changed because of this.
AI makes things crazy things sometimes possible.
Right, exactly.
And so I think that this is the insight that tries to bridge the gap between.
I have not seen a research based number that says productivity post AI is up more than like 20 or 30 percent.
But then everyone talks about like these 10x sort of experiences.
I super don't think it's actually 10x, but yeah.
But like, how do you bridge that gap?
And I think it's exactly this thing of a lot of the value of AI is not in doing the same thing faster.
It's doing a harder, more valuable thing 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 how do you do that?
One challenge that AI is giving is entering the market for new graduates.
There seems to be expectation.
Companies are...
very eager to hire senior engineers who know how to use AI and they have taste and judgment and we have these things thrown around.
It's not deliberate, but whenever I talk to the AI labs, they always tell me increasingly that they look for taste, judgment, agency, these kind of things.
Let's go back to education, to computer science education.
What are your views of how today's computer science education works?
especially for how we know the industry is changing?
And what are some of your ideas of what could possibly be changed?
I will riff a little on my bona fides there to add some weight to this.
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 acting.
Okay.
Some sense because, you know, it's what can we teach?
And I managed mostly the software engineering requirements.
But it does mean that I see exactly what the requirements are and have been living in that space for years.
And bluntly, and I gave a talk on this in a pre-AI, keynote, bluntly, most of the CS curriculum hasn't substantially changed since like 2000, maybe earlier.
The average thing in the curriculum is exactly what was needed to build a database or an operating system in the 90s.
That 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 because, 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 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 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 we guarantee like you can do all of an undergraduate degree without ever thinking if you can just feed it into an AI because it will do just fine on all of those programs and assignments.
And so.
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 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 way too slow.
Memory is a slow thing.
The more that we can refocus on 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 an AI era and still get a job is teamwork, communication, design, specification, testing, validation, right?
Oh, that's a bunch of software engineering.
topic and also building production software especially with ai there's no like i was talking with peter mattis co-founder uh cockroach db cockroach labs and he was telling me that during his college on the side he built the gimp 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 the team.
On the third one, you extend the software.
On the fourth one, because my experience being in a computer science thing, we did a budget 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.
Yep.
And then I took an extra class to actually learn .NET.
And then when I got into a 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 LeetCode 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 tasks.
That was the only reps that were kind of a little bit common that were open to engineers who didn't have software engineering expertise.
Sorry.
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 those sort of lead code questions in the programming contest styles, not because we needed solutions to yet 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 reps, whereas the amount of actual like programming time on task for an average degree is pretty modest.
And, you know, you go back to 10,000 hours to mastery and Malcolm Gladwell.
I think that's a Gladwell.
And like, yeah, like, where are you getting the time?
And if I think back of the boot camps that spun up in the, from like early 2010s, they started to get really strong 2014 to 2017.
What they did is a three month, three to six months, sometimes 12 months, but usually three to six months.
They took people who had no prior computer science or programming experience.
They started day one.
Let's build an application.
which was typically a front and then the back and they gave them the basics it wasn't all that much but that was a three intensive months or six intensive months but building a working web application from the ground up and there was such a huge demand for software engineers that they got hired as a junior engineer level or almost at an apprentice level but what they knew uh compared to computer science science grads the new version control then you get they knew pull requests they knew they knew a database They knew a front end.
They knew Chrome developer tools.
So they actually had a bunch of valuable skills in only three months that the people coming out from program in four years might or might not have had.
It was more of a coin toss.
Yeah, exactly.
I've done the math.
The number of hours in a CS degree is roughly equivalent to like 15 months on average of full time employment.
And that includes all of the theory stuff, all of the.
things that are questionably relevant and is similarly trying to take you from no experience to employable in either an industry or academic direction.
And like that is compared to a six 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 will 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 u.s one of them well a lot of the schools are of course uh you know the the usual suspects are are very highly regarded from the mit's the the stampers and so on but waterloo in canada I was very surprised to see that a bunch of Silicon Valley companies have a high number of Waterloo grads.
And I asked this on social media, like, what's on 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 they have...
dedicated placements by the time someone graduates they will have had four placements slash internships at different companies and because they have the relationship this will often be the shopify the meta this so you will get an engineer who you know three months times four that's like a year working inside of these companies and that is the value yeah exactly like it's not you can probably throw away the the three not not throw away but but that is more valuable itself if you ask me from a I don't want to downplay the importance of the theory, by the way.
But from a hiring manager point of view, like, oh, yeah, I'll take that because that person will be up to speed while 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 example, by the way.
Yeah.
But yeah, a lot of the Canadian schools for CS have substantially stronger programs on internships and co-ops in a way that a lot of those degrees run.
five years now, but I think it is a much stronger educational experience because there are some of those lessons, like I will fully admit, like there's stuff we did not put into the software engineering requirements because there's just no way to do that in the academic setting, right?
There's some lessons you're going to have to learn the real way, like in the field, even 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.
I'll take it.
It's better than not doing it.
But.
Well, we have what we have.
And this system will hopefully.
with people like yourself and others will hopefully start to also change or just adapt to the times.
But AI is right now here.
And one big question more experienced engineers are thinking about, like we've learned to build software pre-AI.
We have a bunch of, we know the fundamentals.
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.
What about for new grads?
Now that they'll enter a workforce of just today with just the capability that we have, what do you think the fundamentals are that they should focus on and what are the things that they should just rely on AI?
There's always a question of like, should you just ask AI for this or should you learn the basics, right?
Yeah.
So, I mean, I think learn the basics is an entirely loaded question because nobody agrees on what the basics are.
And that's where Kent Beck said a couple months ago when we were last together, something like everyone that's currently working has grown up in an era where there was a playbook.
Like we know, at least in theory, the right way to do this.
And there's no playbook right now.
Right.
So we all have to get a little comfortable of not knowing the answer.
And we certainly don't know the answer on what is still the basics.
The things that I think that the juniors should be focusing on.
One, the resilience to avoid just copying your ticket into an AI prompt 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 small shell 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 input.
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.
We called it Andrew's Axe.
And it's if I go chop down a tree with an axe, I do not say that it was the axe that chopped down the tree.
It's me that chopped down the tree.
The AI, as much as we occasionally anthropomorphize it, is still a tool.
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 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.
Going back to sort of the undergraduate version of this, the story, the scary story that I've been hearing from a lot of profs is the best students, like the B, B plus and above students, they are better than they ever have been.
Because they have, yeah, because instead of relying on a TA that is available, 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 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 just throw in slop, yeah.
Which is a bit hard to detect, but I get what you're going.
But everyone in the middle has kind of collapsed.
They don't have that resilience.
They would rather go to the party or play video games than do the homework.
And so they're like, well, just this one time, I'll just get in the habit of doing this thing.
And that slippery slope just gets worse.
Right?
And so, like, there are a lot of profs from decent schools that are like...
Yeah, I don't know, man.
Like, I'm not sure that anyone like below, like 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.
Right.
And so a lot of the discourse initially was how do we prevent students from using these AI tools?
And I think that that's nonsense because it's echoes of.
We got high level languages and there's compilers.
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, in fact, it might be it will for sure be a red flag if a new grad says, like, I've not used these tools.
Like, come on.
Right.
Have you not?
Yeah.
Do you not want to work in this industry?
It's an open secret.
We're doing it.
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.
I co-published a piece in Communications of ACM with a bunch of academics this month that I think the opening line there is imagine forward to 2040 and we hold the line treating all use of AI as cheating, but a generation of students, AI.
You know, they've grown up with AI in the same way that the Internet natives have grown up with the network.
Right.
If we continue asking them these traditional questions about, like, find a palindrome in this string or measure the volume of rainfall in this graph.
Right.
Like, are they going to learn anything from a traditional CS degree?
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.
Well, it sounds like whoever's, so the professors, the TAs, the people who are designing these course, they also need to put in a bunch of work because no one has this figured out.
You need to experiment.
You need to first use the tools yourself.
You need to come up with novel ways of creating an assignment, which you need to use AI to solve, but AI itself is not enough.
How do you?
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 because 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 know like video or in person you're using ai but you're explaining what you're doing and how right because now you you cannot just fully fake it and go away give it to a friend or or just have a lot do it you're you're now showing your cognitive ability, the interviewer can push you into uncomfortable, you know, they'll get a gauge of like how expert you are and push you further and further and so on.
Yeah, exactly.
And at the undergraduate level, like there is some move towards more oral exams and those sort of things.
But also, I think a really simple solution is stop grading just the outcome.
Focus on the process, right?
Like even if you don't come up with wildly harder.
Assess assignments for assessment.
Stop grading just the code that they turned in.
Grade instead, what are the prompts that you used to get here?
Also, what are the tests that you provided?
Like, how did you make sure that this thing is actually doing what you 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've struggled and learned?
Turn in the whole package, right?
Curriculums are designed by committees, which is for a good reason.
But if you had Titus's software engineering school, where you could yourself put together the curriculum and study course for an undergrad course of, let's say, three to four years, how would it look like right now?
And we're talking about getting engineers, ideally having engineers who can hit the ground running at software and engineering companies, obviously using AI tools, building software, that kind of stuff.
Yeah.
So I think the first course, like the first semester starts un-faded by AI.
Like we need to get you through at least the level that you can read code and have a vague idea of what's going on.
Like you can understand control flow and those sorts of things.
I think there's some really interesting things on well-scaffolded and harnessed AI for educational purposes of we're intentionally not just going to give you the answer.
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.
Some of that's covered.
I mean, I'll be honest.
I don't know.
Nobody knows.
There is no playbook.
But one of the ideas.
I want to get opinionated.
So one of the ideas that I've had is let's make CS0, like non-majors and majors alike, 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 slightly more coherent, sensible design language and be more fit for purpose.
I live in New York.
The condo building I'm in has a, you know, there's an app for the laundry room and drives me insane because they use menu UI for button, right?
And 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 themselves wanting to solve a bigger problem and then needing some background on, oh, this is how the web works.
This is how a remote API RPC call works.
You can't give people a solution to a problem they don't realize they have.
Right.
And until they are trying to solve these problems.
Those solutions that we present in theory are all just trivia.
They're just isolated academic, not connected to anything.
Like motivate that by like getting them into a situation where they need that as the answer first.
And then you can provide that 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 research works.
And I want them to grade part of your grade is critique of others, like look at their outcomes or their code or both.
Right.
And be able to say, like, that was great.
Did you think about doing a different thing here?
And then also grade them on.
Can you give feedback without being a jerk?
Because psychological safety and teamwork.
Right.
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 that's going to be software engineering departments and not CS departments.
And as closing for...
For grads right now, college students sitting inside of CS programs, software engineering programs who are seeing, OK, it's more competitive to get into the industry.
Tools are changing.
What advice would you get in terms of tactics, strategies to activities to do to maximize your chances of getting into the industry and then doing well there?
This might be risky, but most of my success in life has come from not doing the thing that everyone else is doing.
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 that might actually lead to less mobility in the industry like it's not i'm a c plus plus engineer or i'm a back-end engineer it's a i'm an engineer in embedded audio right like you understand those problem domains to a much deeper level.
And that's your actual advantage.
As closing, what's a book that you would recommend and why outside of your excellent book, of course?
I mentioned it earlier, but I'll stick with it.
Psychology of Software Teams by Cat Hicks, especially like there are a couple chapters in that that I could have that downloaded into the brains of every leader around.
I would be so happy.
Like the brains in jars analogy is haunting.
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 codebase 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 overly verbose codebases generated by AI.
As comparison, Uber's mobile apps had codebases 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 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' 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 have 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 engineer curriculum sounds like a step in the right direction to me.
Check out the show notes for related to pragmatic engineer deep dives on Google's engineer culture, measuring developer productivity, and the impact of AI and software engineering.
If you enjoyed this podcast, I'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.