Developer Experience at Uber with Gautam Korlam

Vi- coding this is a brand new term what do you think it stands for it vibe coding is just you trying to figure out how the system should behave when you're prototyping the good thing about vibe coding is you're able to like basically iterate much faster with this agentic loops that now you're just

focusing on how would I actually achieve my outcome rather than the exact way to do it. Because you can always change those details later. If you have the right abstractions, you could swap layers out. So I think that's changing the way people think about software because if you're someone who has taste and knows...

This is the outcome I want to see on the UX. You may not even need to know a framework. You should experiment with it till it feels right. And of course, you need to massage it to make sure it doesn't make it harder to evolve later on. I think a lot of the software today gets you to the initial. It looks great, but then how do you maintain it is basically...

Gautam Corlan worked at Uber for almost 10 years, joining as Android engineer number eight and was the founding engineer for the mobile platform team. He grew from Software Engineer 2 level all the way to Principal Engineer and worked on developer experience and scalability challenges throughout his decade at Uber. Gautam is now the co-founder of Guitar, an agentic AI starter that automates code maintenance. In today's conversation we cover

How Gotham accidentally deleted Uber's Java Monorepo, which had thousands of developers committing to it. Uber's in-house engineering tools like Monorepo, SubmitQ, local developer analytics, and DevPods. AI's impact on software development, why Vibe coding will spread, and why Gotham believes junior devs will thrive with AI tools.

Uber's engineering culture is very unique, even across tech companies. And this episode was a perfect inside look of its early days. If you enjoyed the show, please subscribe to the podcast on any podcast platform and on YouTube. Welcome to the podcast. It's great to have you. Thanks so much, Greg. Glad to be here. Thanks for having me. It's good to reconnect because we talked a lot while you were at Uber. You were on the platform team.

And your work touched a lot of the systems that we worked on. Every engineer causes outages at Uber. I did it. People on my team did. What was a memorable outage that you might have caused accidentally or deliberately? So this is a funny story. Towards the end of my career, I accidentally deleted the Java monorepo at Uber, and there were thousands of devs committing this.

Yeah, the Java monorepo, that was one of the, we had two big backend monorepos, right? Go and Java. Go and Java, yeah. So this was after we did the migration on like almost everyone using the Java monorepo. Yeah, it was pretty funny because what the story is essentially, I don't think many people know about this because I recovered pretty quickly. I was trying to test something out, like a test repo. And I was like, hey, I need to copy the Git.

push command because we created the repos on push. So I copied the URL from the Java monorepo, but I forgot to change it. And then when I pushed, usually at Uber, they prevent you from force pushing. And it said, hey, I can't force push. And I didn't read the message. Then I was like, why is this? I should be able to force push. And I did with some special flags.

And there's only a few people, maybe like three people at Uber who can force push with that flag because I was part of the platform team and I didn't want anyone else to do it. And I pushed and then summoned. Pings me on Slack. Hey, so the repo says initial commit. What's going on?

So you were a principal engineer at this point, right? Like you were one of the most senior people and you were there for a long time, right? This is like not some, you know, you didn't know what was going on. So I mean, that's why I had the permission to push.

So whole repo gone until you reverted minutes later. It was tricky because we had to get back from a backup. Yeah, it was not too bad. It was like a few minutes. And I think we had an instant review. It was luckily at a time when we had a submit queue. So the queue would... pause automatically and said hey no work is lost right uh we had really good backups in place so we reverted quickly and i was like gotta be very careful with those like copy paste commands wow

Well, but I guess you tested the backup actually worked. You should have just said that. It was just a test. I went just to see if the process actually worked. Yeah, chaos engineering. This episode was brought to you by Sentry. Buggy lines of code and long API calls are impossible to debug, and random app crashes are things no software engineer is a fan of. This is why over 4 million developers use Sentry to fix errors and crashes and solve hidden or tricky performance issues.

centric as debugging time in half no more soul-crushing lock sifting or fake user reports like it broke fixed it Get the context you need to know, what happened, when it happened, and the impact, down to the device, browser, and even a replay of what the user did before the error. Sentry will alert the right dev on your team with the exact broken line of code so they can push a fix fast.

Or let Autofix handle the repetitive fixes so your team can focus on the real problems. Sentry helped Monday.com reduce their errors by 60% and sped up time to resolution for next door by 45 minutes per dev per issue. Get your whole team on Sentry in seconds by heading to sentry.io slash pragmatic. That is S-E-N-T-R-Y dot I-O slash pragmatic. Or use the code pragmatic on sign up for three months on the team plan and 50,000 errors per month for free.

You know, like, how can we imagine, like, what was the response of, like, your manager, the incident review? I mean, yes, sure, you were an experienced engineer, but come on, this was a big deal, right? So the good thing was since we had the Summit queue, and we can talk about it a little bit more, only thing it affected was the amount of time it would take for a commit to merge onto main. So usually everything would get serialized.

All that it looked like was there was a little 20-minute delay where we recovered everything. And then everything just flowed naturally. So it was just like a random CI failure you would see. But we had so much recovery. automated in place it was almost a non-event and the only SLO we broke was the latency SLO no reliability SLOs were broken so that was pretty good like all the systems we put into place in the many years actually worked to save me that day

Okay. And this is a good way to say into the next one, Uber's unique engineering stack. I worked at Uber. I worked for a lot shorter time than you, but we overlap. You were there when I started and you were still there when I left. Uber had a lot of unique systems. Can you talk about some of them and how they came about and why? Why did Uber build so much of its stack? Well, Uber and also you built a lot of that stack, right?

Yeah, absolutely. So when I joined Uber in 2014, I was like Android engineer number eight, I believe, if I remember correctly. And there was no unit test. So I wrote the first unit test for the Android code base. Then I set up the Artifactory. Yeah, it was pretty funny. We were shipping so fast that people were just, you know, integration testing using their mobile phones because it was just very, very fast growth. This was in 2014, 2015?

2014 is when I joined yeah so then I brought in Artifactory so we could share stuff and over time what ended up happening was a lot of the Stuff you take for granted today, the cloud-native SaaS products for observability or hosting source code were just not built for our scale back in the day. So we had to build a lot of stuff in-house to solve some very...

crazy problems. So we had commits going in almost one every minute, I think. And that might not seem like a lot, but when you have thousands of engineers working on code bases where you can easily go into merge conflicts, that was a big deal. I hear a lot of companies saying it, or at the time it was popular to say, it's not built for our scale. What was that scale? I mean, you mentioned the one commit per minute, which I can actually attest to that, that build systems.

At least mobile build systems could not handle that. But what other scale was considered just way bigger than what commercial vendors supported? Yeah, absolutely. So I think the build system part was definitely one because builds are taking just way too long.

I think we embarked on like a big app rewrite, I think, when you were there. I think you talked about it before. It was funny. I was actually in Amsterdam and that happened in between. And then my boss calls me up. Hey, this build time is like getting crazy. somehow bring it under control. Oh, that was you. Yeah, I was there. And it was almost an hour something plus. So if we actually serialized all the commits one by one to make sure there was no merge conflicts.

It would just take forever. And if you did not do that, our main branch would be red. We had this graph where it was like red, green, red, green, red, green. And it was impossible to work because there were so many teams trying to hit their deadlines. And you were depending on so much work from the other teams, like the networking library or the platform experimentation or a feature library from some other team. It was just not possible to do this without GreenVein, essentially.

So it's not just the build system time, but also the fact that when you push something, if you don't run tests against the other part of the code. then you're just not going to have a good time because you will just be stuck reverting stuff. Someone would be on call all the time. So it was a combination of factors that made it very hard to work with.

Yeah, and also we did do that on that project specifically. We turned off end-to-end tests, I think, for two or three days to speed things up. And it sped things up. And then we had so many regressions. And it took more time to, I think, you know, for two or three days, we turned it off. And for the next week, everyone's fixing the regressions that kind of sneaked in underneath.

Yeah, I think we got a request at some point, can you just turn off CI? And I was like, you know what's going to happen if we actually did that? And I had to really talk people down saying you cannot just turn things off. It's going to make things worse. So there was the submit queue. Can we talk about what SubmitQ was and why it was unique, at least initially to Uber? Even to this date, I'm pretty sure only a few companies have anything like that.

Yeah, I think submit queue is essentially a way for you to guarantee a green main. So it's a way to kind of serialize your commits coming in and make sure that they play nicely with each other. There are some... or open solutions now but when we did it at the time we had actually a paper that we published it was fairly novel because we had very low tolerance for

main being red so we'd always want to guarantee a green main which means we had to figure out how do we actually test changes coming in and make sure that the cross dependencies between different commits were considered so it's just a way to kind of

handle commits at scale, and make sure that when everything merges, everything still builds with each other. And that's a trickier problem than it sounds because we had to test things in combination, discard some paths, and do a lot of processing on the backend.

But there was just one of the systems I think we had to build a ton more, which I can talk about as well. I was the consumer on this side. You know, I was just using it. It was just a build system for me. But I didn't realize for quite a while that, you know, like my team, you know, the.

10 of us who were working on it, we didn't really have merge conflicts with each other because we were working in different parts of the code. But it took me a while to appreciate that when I was pushing something, at any given time, There would be maybe 10, 20, 30 people on the same code base in mobile working. And each build would take 20, 30, 40 minutes. And then behind the scenes, actually, I understood only when I read the paper that you were.

You know, looking, checking, like, is this code path in conflict? If so, which one should we build beforehand? There were, like, all sorts of probability models. There's a bunch of math in that paper as well, right? There's a lot of ML models, too. Like, I think we had to, like...

estimate what would potentially cause a failure and speculatively try to go on paths that might be green to try to optimize and then backtrack if we didn't make that goal and we would make that model better over time. So it was quite interesting, I think. If you didn't notice, that's a good thing. It means that it worked as it's supposed to do. One thing that Uber did as an engineering practice was monorepos.

Can you tell us how it started? Uber had multiple monorepos, but it all started with the iOS monorepo. And I recall you were there. Can you tell us how the decision was made to... go from having a bunch of separate repos, initially in iOS, later on Android, and say, like, all right, let's just do one big repository. And, you know, why did this happen? And what happened next? So it's funny I mentioned, I think, early on...

We didn't have tests. At that point, very, very early on, we had two apps, Rider and Driver, on both iOS and Android. And we had another repository called Library, which is a common component between the Rider and Driver app, which was just a sub-bondule you would pull in.

And it was really painful to pull in as a submodule. So we said, hey, let's set up some sort of Cocoa Parts Artifactory thing where you could download stuff from somewhere. But as we grew, we realized we couldn't put everything in one place. We had a networking team. experimentation team, a analytics focus team. They all wanted their own sort of nice little playground so they could experiment. So we went off and had hundreds of repos for a while, but everyone was just, you know.

unaffected by everyone else could focus on their priorities and deliver but then when you wanted to pull in these changes let's imagine the networking library changed you had to update networking Then the analytics library that relied on it, then maybe the experimentation, maybe some other feature library. It was really painful to upgrade and pump. And we were sort of on the hook because anything that the product teams don't do, the platform team ends up being.

the kind of like catch-all and you're like, Hey, this is not going to scale. I think someone on the iOS team was like, Hey, we should just go to a modern repo. We'll just take a weekend. Famous last words. I know, but they, It took a while. It didn't take a weekend. But Iowa's team did it and it was very effective for them.

uh it was a lot of pain initially and i think happened the same time they're moving to a new language swift as well so that was like double whammy they had to do both um they pulled it off and the gains and productivity were massive because you don't have to go

bump libraries because we were not an open source, you know, make sure the interfaces are nice for external consumption. It's one company, one code base. Why can't they update my library's public API and just update all consumers in one shot? It should be possible. So mobile did it and then Android quickly followed suit. We actually froze the code for a weekend and we moved everyone over. And it was painful at the start because the build systems, as I mentioned, were not.

meant for hundreds of modules in the repository. We have seen some changes to Google to make it better. And then after a while, we migrated to a new build system back from Facebook at the time. And we wrote some auto conversion from the existing system to the new system. So we had both at the same time. That was really successful because once things were fast, the NPS improved again. Mon repo was good.

The gist is monorepo, non-monorepo, if you don't have tooling, it's going to suck. At a bigger scale, you have to invest in tooling. As your companies grow, typically this need becomes more and more obvious as things start slowing down. And then later we had the Java MonoRepo and we migrated over to Bazel and we had the Go MonoRepo. I think what we realized with the MonoRepo was that the main thing that helped us do was it was standardized, which meant to make a big change.

One team could go do it. A centralized team could just take the burden of updating this one networking library for everyone or updating Google Play services for everyone. You just cannot do that in hundreds of repositories. It's just a very wasteful amount of work.

And what was the biggest pushback that the teams initially had? Because I remember the mobile ones, they actually happened and it was, you know, like... very practical but then when the java and the goal was happening i remember a lot of teams were dragging their feet like i'm not sure we want to do this it's gonna you know slow things down do you remember what the biggest

you know, like skepticism was and then how it turned out? Yeah, the biggest skepticism is usually right now before monrepo, I could break an API and not worry about it. The tax is paid by someone. Eventually, this is deferred. It still needs to get paid. But in the monorepo, if I do it, I have to think about my interface design more and my builds are going to be slower for this argument.

With the new build system, we kind of said, hey, the builds are not going to be slower. But people would always come up with reasons saying, hey, if I did this upgrade, then I have to do it for everyone. So we said, okay, you know what, we will make it possible for you to just upgrade.

your part of the code in some scenarios but otherwise we want to have everyone be standard it does make things a little slower but then as a business it makes a ton of sense because You might not see the macro picture on your team that you might be slowing slow a little bit, but everyone else gets like a huge productivity boost because they didn't have to spend the time you did on each and every one of those teams to like get up to speed.

Is it safe to say that monorepos, often, not always, they... They bring an almost necessary friction where making certain changes will be painful because they should be painful. Because when they were not painful, they were masking something. down the road of let's say you know i update a dependency to to something else and then it has to trickle down otherwise you'll have these problems but they'll only come out in weeks or months later

Yeah, to be fair, you can also do stuff without the monorepo. I know companies like Amazon, Netflix do multi-repo setups, but they build tooling specially to handle those cases where you have golden version sets that work with each other. It's a little bit like a monorepo without being a monorepo. So you can make both work, but monorepo is just generally easier, in my opinion, just having considered both.

But if you want to go the other route, you absolutely can. You still have to invest either way as your code base goes. And what were some other kind of novel slash innovative things that... It sounds like you had to invent some of these things at Uber because there was just not a solution that you could buy or it was just really expensive or not built for this use case.

Absolutely. So the other thing I think which is interesting for us is, as I mentioned, build times are a problem. We only knew because we first had to measure it. I think back in the day, a lot of the measurement products for developer observability were just not built for...

the entire SDLC. So what I mean by that is like you might have like a CI Jenkins back in the day that would tell you how long your bills would take. But you had no idea how much your indexing time would be in your IDE. And we had very complex projects. Or you had no idea what was the time between pushing and code review. So we built a system at Uber called Local Developer Analytics. We call it LDA for short, which was like a little demon that used to run on your machine.

collect information about your system, what's your CPU usage, memory usage, but also integrate deeply into a lot of the CLI tools, the IDE. So we would, for example, know when you opened your project. which file you went to where which part of the file you're actually like coding the most which files would have the most bugs and then you could also see like a funnel like in a traditional product funnel because we would care about like developers as like a end user

you would see like analytics saying, hey, there was a drop in the funnel. People could not create PRs because this part of the build process would error out more often than the others. So you would know what to target. And it's fairly novel because I gave it a few.

talks at a few different conferences and not even big companies had something like this back in the day. And I think we still use that today to power a lot of the dashboards and the deep analytics that we get from the developers, workflows. Yeah. You've been in developer productivity. You talk with a lot of people and know a lot of people. But what do most companies do? Do they just ask developers? How does it feel?

I think that's a very important thing to do for sure because even if you have all the measurement, if the development doesn't feel right to you, you still want to ask that. You want to have a survey, which we did. In fact, when I...

I remember when we started doing the surveys, I think we had like an NPS score, negative 50 something. And when I left, it was like positive eight or something like that. So I call that as a win that we did a lot of effort. So you do your survey as the very first step, which we did. But then you measure the easier things like your commit.

time to like review code or time to like build code stuff that's out of the developers control you want to like minimize and also time spent in meetings like those are things that you could probably get easily but the deeper stuff is only worth it if you see that those bottlenecks are adding up

like if you're making changes but you're not seeing like people are happier because you'll always see developers complain build times are slow or id indexing is that's when you know okay we need to measure things but now i think

Products like VS Code JetBrains have better analytics. I think we worked with JetBrains, for example, in trying to make them understand, hey, these are some of our problems. It would be great to have solutions out of the box with these. And some of those did make it upstream into... products that everyone uses today so we call that as like we kind of had to forge our own paths and eventually all the vendors would catch up based on what the industry was doing yeah but it's interesting how

Back then there was nothing and you kind of like pinpointed, I guess one advantage that Uber always had is a, we had a lot of developers and there was actually a dedicated, you know, what was your team's name? Was it developer platform? We were called Developer Experience. They had multiple names. I think we were Mobile Infra first, then Mobile Developer Platform, then Developer Platform. That was the final name we had. But funnily, actually, the team was not that big.

My team was about 10 people and we supported about 1,000 engineers and that's roughly the breakdown. So you would see that speaking to peers in the industry, the teams are about the same. You have like a very small code centralized team. And then you have a much bigger product organization that they support. So it's very common. And that means that you have to find ways to scale yourself and be effective.

And then there was another project that I remember that was just taking off just in my last year. It was called DevPods. What was that? So I think a lot of people might have heard the term cloud developer environments or developer environments in the cloud. So we call these dev paths and what it is essentially is a container of your...

code, your build system, artifacts, your IDE indices in the cloud. And what we did at Uber was fairly unique in the sense that we figured out some ways to make it boot really, really fast. and have a pretty much everything pre-index and it is one of the most loved products there because you could essentially multiplex yourselves now rather than trying to switch branches re-index your code or context which you could have

10 different dev parts working on different features. And they could have everything warm. You could context switch quickly. You could kick off a build and go do something else. It was actually great. I think we...

put a lot of engineering effort to make that scale really well. And it was a fairly small team as well. Actually, a bunch of those folks are still in Amsterdam now working on the product. And can you just explain? Because I think most companies just do not have anything like that. Like as a developer, what... Can I imagine that? Like, okay, I joined Uber, DevPots is there. What does that mean for me? So when you onboard previously, we used to have this like...

bootstrapping script you would run. It's funny because we have a bootstrap shell script that everyone just keeps updating. There was a shell script, which usually worked well, but sometimes it crashed and then we would have to you know, ping the on-call of your team. But it was a pretty involved script. Like, it would take sometimes minutes to run out. Yeah, it was pretty complex. A lot of magic under the hood.

And the problem with that is it's hard to keep it forward and backward compatible with your system updates on Mac. So it was definitely not worth maintaining over time. But the DevOps is interesting because I think... just when we started seeing all the solutions like VS Code Remote or JetBrains Projector become a little bit more mainstream, we said, hey, why don't we move this development stuff into a container? It should be easy, right? But it's actually much more than that.

These containers can be huge, multiple gigabytes, right? Because some of these artifacts and indices are huge. We have to make sure we also use compute efficiently. So we would have to have multi-tenant because developer workloads are very spiky. They don't...

always have like a stable pattern like a server workload which means that you have to like understand when to scale up and down we have developers in different time zones so we have to also like provision machines closer to them so the build caches will be warm

closer to where they're working. Otherwise, you don't upload everything from a data center in the US, but you might be working in India and the latency will be really bad. It's a lot more nuanced, I think, than just spinning up a container.

solutions out there now are just focusing on contentizing stuff but not thinking through a lot of these other factors that are important so we went through and made a lot of improvements here some of that stuff actually one of the funny things i remember is uh i think jetbins had this like

one shared index thing that they had a while back where you could download a index of the project but i think the way they were doing it previously you would have the full path of the system in the index so you would download a denormalized path and then you would normalize it to your system just populating all the absolute paths would take a really long time we measured it was like it would take an hour to actually like

that shared index for chat paints. But then on DevOps, what we did, we just said, hey, everything's in our control. Let's just put everyone at home user. So it'll be like closing the laptop and opening it again. So we could just throw the cache there. Everyone was at home user. So now, no more time spent denormalizing the cache, which meant we had a six-second boot up, which is pretty insane for a dev environment. So you would come in, you would say, DevPod, start something.

And you're done. You don't need to do any bootstrapping, nor learn something. And you would have one flavor per model repo you'd work on. So a data engineer or like a backend engineer or a mobile engineer would have their own flavor. And that's very optimized for that. So it's basically you go in and say like DevPod start and then in a few seconds you have your web, sorry, your local editor. You're using your local editor, but it's kind of like connected.

magically from your perspective. So you feel like you're working locally, but it's just all set up. It works. You can build immediately. You can run your tests, et cetera. Yeah, you would have lots of codes as well. So you could run a lot faster than running it locally. That's pretty awesome. I previously did a deep dive on cloud-based development environments, I think, two years ago. One thing I'm noticing is there's not much talk about these things, even though they're just so darn efficient.

Do you see kind of excitement in this space or is just AI right now, you know, blurring everything out? Because to me, this was a really big win. Yeah, I think the environments are still good. I think a lot of companies do want to use this for efficiency sake. The challenge usually comes with, I think the understanding that I have talking to peers in industries, if you start to start with the solution.

rather than the developer workflow. Hey, we have a container environment. Make it work for your developer workflow versus you have a particular way to work. Let's make it work in a container or VM. So we took the other approach and that is why we were so effective. We were like, hey, these caches had to be like...

super fast load other stuff can come in async and not everyone would have that insight if left to their own devices teams might devise a docker file that has stuff but then how are you getting it up to date as your team churns out more code

our indices actually getting up to date. Otherwise, you're spending a bunch of time after bootstrapping to re-index stuff or re-download stuff. So you'd push these updates every few hours completely transparently in the background. So it was very much like a golden path that we had to like...

kind of happen upon. And that's why I think if you have that knowledge of the entire developer workflow, you can adapt it to each company's individual working style. If you give a general purpose thing, it'll work.

but may not actually work so well out of the box and you may not have the investment you may want to make to make it work for you. Yeah, it sounds like there's no, you know, free lunch. You need to put in the work and, you know, Uber had like so many years of like understanding, investing, like being there. Speaking of years, you spent nine years at Uber, and when you joined, you were an inch two, is that right?

More than NG2 when I joined. NG2? I guess, yeah. What is the lowest level? Whatever the lowest level was. Yeah, and then... When you left, you were a principal engineer, which is, there's not many principal engineers, like several, like a few dozen or something like that. So then you were promoted. Actually, yeah, maybe a couple dozen. Yeah, not that many.

out of the closer to 2,000, 3,000 people working in tech. And so you were promoted, I think I counted four or five times in nine years. Can we talk about your... journey like how how did you do it and what did you learn on the way yeah absolutely i think one of the cheat codes is obviously joining early helps a lot especially for getting on a rocket ship

But it's hard, right? Because when I joined, we didn't have as many people. The platform teams were tiny. It was so small. It was funny because I jumped straight from entry level to senior. So I skipped a level because the first year was just... put through the paces of we need to get a lot of stuff done and I was shipping really fast so that helped obviously one jump up but it gets harder over time I think your roles also change a lot over time

uh one of my good friends early on in the platform team said hey if you can get into a niche and go deep It can really help over the long term, especially stuff that people may not want to do, like developer platform, developer tooling. Not everyone likes to do it. But if I said, hey, I really like this because I'm passionate about it, that helps because then you become the go-to person.

for that aspect. So as the company grew, it was very obvious that, hey, I had to scale myself to larger and larger efforts. So starting on mobile, then I started working on backend stuff and then on more holistic entire organization stuff. And that takes breaking your own comfort zone a lot, challenging yourself every year or two. So every two years, I kind of do some introspection and say, hey, am I doing what I want? Do I enjoy what I'm doing?

What can challenge me more? And then I try to go for that. And usually the path opens up if you go that way rather than trying to chase a particular level. Because then when you're pushing the boundaries, the next level kind of becomes obvious.

and then past the particular point it just also helps to have a lot of connections like social capital mentorship those are very important at like a big company right so i definitely went and got some mentorship with some more senior folks that helped a lot to understand how these principal engineers operate and what's required is more than just the engineering, it's also the business side of things. How do we actually solve problems and focus on the business metrics?

And bring that to engineering rather than start from bottom up. And when you say, you know, like you need to get some social capital and mentoring, like it can sound a little bit of hand wavy to people of like, but how did you. How did you get that? I'm not going to ask how you went about it, because it sounds like you didn't say like, oh, I want to get social capital. But what were things that you did that you think actually helped?

build up and people saying oh you know like like gautam i really trust this person i know him he's a go-to person etc yeah so one thing that helps is i have this habit of just helping people a lot so when people come to me with like a problem with their

Dev environment, I would just drop everything and say, hey, let's try to figure it out. I'll spend a little bit of time, time box it. And if it fixes the problem, then I have some social capital. It kind of accumulates over time because they would send someone else to you. And over time, you can automate some of this stuff.

And I think I was one of the early people on the platform team to have office hours. So I would say, hey, anyone can come in and just talk about your problems. And we would just empathize a lot with everyone and say, hey, I know this sucks. They're working on it. It helps a lot to humanize the problem, right? Because developers just usually bring you on Slack. And over time, what happens is like as you solve more and more problems, it's always good to like attempt.

And if you can meet the expectation, just say, hey, I can't solve this right now. Then try to say, okay, that's not in my area. Let me just try to help you out. And that really helps build trust with the other side. And then when you go for mentorship, it's like, hey, I...

clearly know you have the right sort of like mindset you have the right goals in mind or like the right intentions so i would love to help you kind of go to the next level so that's usually what helps get very strong mentorships yeah and I can just plus one a little bit on the helping people because, you know, I was in Amsterdam, which is, we say it's a distributed site, but we were just not in HQ. We were a relatively small office, you know, like compared to SF or even Paolo also in headcount.

We felt a little bit isolated. And sometimes, like a lot of times, we would feel blocked by SF in reviews and anything. And after a while, I knew that if I wanted to... You were one of the many people on the platform team, but I think either someone told me. There was this thing, if you cannot return anyone on the platform team, try Gotham. He usually responds.

And just thinking back, it was just wild to me that like, I did get responses from, you know, some, sometimes and like unexpected, like unexpected, like I didn't think I would get anything. I was just trying, but you did like spend. time on this. And I just imagine that you had a lot of these things and I'm not saying you necessarily did it all the time. And obviously people like me were doing it sparingly, but it built so much goodwill.

And also trust of like, wow, like I just felt that whenever you did go on a problem, you actually took it seriously. Like you, you kind of did it. And as you said, often you would tell like, I cannot do this right now, or it's not, it's not an issue, et cetera. I didn't see everyone. In fact, I saw pretty few people doing it. So it's interesting how it feels like something that would not scale.

But I guess to some extent it did. Is this like the starter mentality of like, you know, do things that don't scale? Yeah, I think it definitely doesn't scale in all cases, but you can make it work. I think. It's funny because some people won't even try because it won't scale. My suggestion is like, hey, let's meet the person and see. It may not even be an issue, right? Sometimes what you might discover is people are just finding it hard to find the right documentation.

because they just looked at the wrong guide and that's where they're coming to you then you can just go make that fix and then you have much larger impact but if you don't talk to people you have these broken windows like you have the big picture but then you lose touch of what's actually happening on the ground

It's hard. So I think my policy was always like, hey, I can always talk to someone, spend a few minutes. And if it's like a very esoteric thing, I'll say, hey, I can get back to you. But if it is not, I would rather just point you.

The right way. People joke when I left because they're like, hey, we should go build Gautam LLM because he would know the answers to like, you know, pointed things at least so that we could find the right information. So I was sort of like an encyclopedia of where to find stuff. And you were a principal engineer towards the end of your tenure at Uber. What is a principal engineer?

at uber and and also previously we had an episode at meta meta has archetypes above staff engineer do you think you fit into an archetype or did you see kind of archetypes at the principal level at uber yeah i did listen to that episode that was very it's a very good episode by the way i think there is some resemblance to an archetype although we don't actually call it that so either you have depth in a particular area

or you have a lot of breath and sometimes it's a lot of internal influence or you might have a lot of external influence right so it really depends on where you want to take your career.

uh i focus a lot on depth like as you can see my specialization is like productivity and how some amount of breath because of all the social capital and talking to a lot of people usually makes you understand what are some of the business problems that uber is going through so that was actually a good bonus for me because if i never talked to people i wouldn't even know oh

These three teams are trying to solve the same problem. Maybe we can centralize it or do it more efficiently and I could come up with solutions. And people will be like, hey, how did you know that would work? Because just talk to people. There were definitely lesser archetypes probably than meta, I would say. But usually it's a bunch of breadth and depth.

Having people to sponsor you helps a lot. So the mentorship angle is also part of that. If you're working with more senior engineers and they see you actually grow, they can give you feedback where you might be lacking and you might be able to kind of work towards that goal. So I think...

That's one of the things I would recommend anyone who wants to go in that path. With principal engineering, it's a lot more, you have to enjoy understanding how engineering meets business than just pure coding or just pure, what do you call it? not soft skill stuff a lot lot more soft skills need to be honed at that point it's like

Going and giving talks helps. And it's funny because when I was growing up, I was not very good at like, you know, public speaking, but I made myself over time more comfortable. That helps also like build external influence. And a lot of the... early folks that are using our product right now are people i met in the community and then they kind of have that trust that they built over time so this is a lot of people who are using your product right now at guitar right yeah

Yeah, so I guess that's a good reminder of how, I guess when you're doing something, hopefully it'll help you outside of when you're at your current company and also help you while you're at the company. Yeah, my tip is generally if you really focus on the people side of things, you will do really well in these higher levels because it's a lot of relationship management, both managing up and down and shielding your team from some of the noise.

And if you don't enjoy talking to people, it's harder. I mean, you can still do it. There are people who do it, but it's a very unique path and not everyone can do it. But the most common path is usually like understanding and spending time. talking to people and figuring out solutions that are more creative over time and that also kind of makes you a problem solver not just like someone who can just you know code and finish up things up but that's

course like you can have different archetypes as you mentioned so it really depends on where you want to take things yeah but i guess at the principal entry level it's kind of given that you're just you can code efficiently whenever and however it's just like you might not do it all the time by choice right

It's funny because there was a graph someone sent me of like number of years of the company and number of commits per year and number of reviews. And there was like a little... graph like you know like an asymptotic graph and there were two or three dots at the very extremes and I said hey one of them is me the other one is you

Then I was like, damn, I should ask my boss for a raise. So you were still writing a lot of code and doing a lot of reviews? I do write a lot of code. Even here at Guitar, I write a ton of code. I love to review stuff because it really opens up your... perspective of what else is happening. I like to comment on documents and understand where there are inefficiencies potentially. But just over time, I think you have a muscle to just do it.

But it does not mean that you write tons of code. It just means that you have consistent, higher impact code. So a really interesting topic is, given that you're a principal engineer, which was... either the highest level or or maybe there was one level above it but there weren't many levels above that How was it like for your manager to manage you? And I know you also talk with a lot of principal engineers and you have some thoughts on what are some tips to manage these very, very senior...

Can you help explain your relationship with your manager? Was it really a kind of a boss or more of a partnership? What worked at this level? I think that's a really good question because I think as you grow in levels, you're more and more sort of like a peer to your manager. You help your manager. get stuff done too because you have broader influence sometimes it can be hard as an em

to push for a particular priority because there's not enough senior people that can back. It might be just your direct developer person that's sponsoring that. But having someone on the team that's senior enough can... completely change thoughts for example to get some things practiced one tip i will give managers is like if someone's asking you hey i'm at a senior staff or they want to become a principal after like the senior levels if they come ask you it's hard you should

probably not ask that question to a manager because at some point you'll have to figure things out, right? There's very few managers who probably can help you after a particular point because they're maybe done it before or have.

a lot of experience at the company but most managers tend to work like senior or senior plus level and past that it's more like they're almost like the principal engineer on the team is load balancing a lot of stuff technically so the manager can focus on uploading everyone else so the relationship is very much like a peer like more than like hey it's the boss

But it does help to get feedback. I think managers are a very good asset when you want to do non-engineering stuff. For example, you want to get stuff unblocked. engineering angle is not working because you've tried to rationale with some team they won't listen sometimes you just got to take the uh hey this is the priority you need to get this done like to unblock yourself So that's what I would say for EMs who might be looking at higher level engineers. Basically, give them agency.

But of course, check in often and make sure that they're unblocked because they can do wonderful things as long as your org is not getting in the way from them trying to actually have impact. Yeah, this is always interesting because I don't think we really talk about this too much just because there's not many of these engineers. But even when I was a manager, I actually promoted someone.

actually two engineers a level above where i was right i mean it was a bit easier for me because i saw examples but it's always Interesting. And I feel it kind of goes hand in hand. Like for these things, those promotions really help usually the manager as well. And as you said, for a lot of managers, it's a first and there's no playbook after senior or staff. It's all unique. It's all based on.

the business needs for for the company in that specific area yeah but if you're going to keep up with the engineer then they can pull you up as well with them because then you can become higher level and you can focus on bigger picture stuff because you hear a lot of stuff from an org or a company perspective from the engineers because just talk to so many people then you might have opportunities that you may not have if you're solely focused on your team.

Before we jump back into the episode, I want to let you know that the audiobook version of my best-selling book, The Software Engineer's Guidebook, is out now. You can get it on all major audiobook platforms like Spotify, Audible, Liberal.fm, Apple Books, Google Play.

and also DRM-free MP3 files. I started writing this book after a decade of working as a software engineer when I was working as an engineering manager for a few years already at Uber. Here's a review from the book from senior principal engineer Tanya Ridley.

who is the author of The Staff Engineer's Path. From performance reviews to P95 latency, from team dynamics to testing, Garagay diversifies all aspects of a software career. This book is well-named. It really does feel like the missing guidebook for the whole industry.

You can get the book at engguidebook.com or search for the Software Engineering Guidebook on your favorite audiobook platform. I hope you'll enjoy it. One thing we just kind of mentioned as natural is you always worked on a platform team, but when you started... I'm pretty sure there was not yet a platform team there. And then there was a split called the platform program split. It was a very famous email that I think later we saw. I only read it. Can you talk about...

What was before there was platform and program teams and how did this split actually play out from your perspective? Yeah, so I remember when I was interviewing to join Uber, they asked me, hey, what do you want to do? You want to do some platform stuff. I said, I want to build tools for developers. And they're like, okay, you're hired because no one wants to build tools for developers. The longer version is the platform team sort of existed. We just used to call...

it i think mobile had it first i think but then the other ones we just had unofficial platform teams they were working on core infrastructure pieces um the platform teams were essentially made so that the other teams could move faster and not duplicate stuff right

There's a lot of stuff that goes into building features and mobile was just very new back in the day. So things were just not as well figured out as they are today. So you had to build a ton of stuff internally. So if you're doing this on every team, then it's a lot of waste.

I think when we decided to do the platform programs bit, we said program teams don't need to worry about a lot of the underlying layers, similar to a cloud native environment. You worry about your business logic, your product metrics.

and we'll give you all the building blocks which could be a mix of open source wrapped in our own layer and our own architecture that makes so that you don't mess with the other features because everyone has their own way of building banners or their own way of like styling things not at all consistent for like

app like uber you need to have a common design language so you use common components stuff you would do on a website or take for granted today just didn't exist on mobile right so it had to be done that way to kind of make things move faster so you don't have to rebuild like another widget or rebuild like another analytics processing thing and do something in the back end so one pain point or i wonder how big a pain point is but one thing that looked

challenging to me. I was not on the platform team. I was your customer. But, you know, we always pinged you with questions. And as you mentioned, like a year ago or so, there were 10 engineers for about a thousand engineers. What did support look like and how, what practices did you figure out? Because I. I saw a lot of practices like office hours, on-call rotations of where to bring, et cetera, that I have not seen anywhere else. Like the platform teams were advertising.

these things it was it was almost like i don't know like having a a vendor almost like there were like contracts there were actually slas It was published how fast you can expect things, where to escalate, how to tax something with high priority, et cetera. I've never seen anything like this. How did you figure out support? How important was it?

Sure. So the angle that I think we thought about was like, hey, for everyone else, the end user is the customer. For us, the developer is the customer. Let's not treat it as like another internal thing. Let's really be customer obsessed. But that was the value we had to do with it. we're extremely focused on the customer experience. The developer experience for us is the customer experience, which means imagine if your Uber didn't show up, you'd be very upset. So if your build didn't finish...

Exact same feeling. Okay, I cannot ship my code. So we need to make sure that there is reliability and latency guarantees for that exact same reason. So all the product, I think like minded folks had like very... much honed in on product analytics. We said, hey, let's think about what is important for the developers. We asked them things like build time.

They said, hey, I want to make sure my CI is reliable, has no flaky tests. Can you make sure the flaky tests are not blocking me? Because it's expensive with the build cart. You have to chase the release train. And that's not fun. I'm sure you've seen your team complain about like, hey, I had this flaky test.

I had to like resubmit this diff and that's not going to merge in time for the release train. Yeah. And just like staying late. I'm not sure. I think the release train left on Wednesday night. So Wednesday night was the cutoff. Or morning, I'm not sure, but I know people stayed longer on those days to catch the release train, meaning getting their PR, as we call the diff, merged on there.

Like it was, as you say, it was, it was, it was a big deal. I didn't actually realize that you were like obsessing about it, but it kind of makes sense because after a while it wasn't an issue. yeah because that's when people complain a lot that hey i tried to cache the train but then something was out of my control the infrastructure was flaky so we miss this

deadline. Now, I'm on the hook as a platform team to ensure a hotfix happens, which means a bunch of other teams are going to get disturbed because they have to retest all their workflows. It has a lot of ripple effects. And these are not obvious unless you think about, oh, we cared about testing because the end user will see the impact if you don't test all these features again. Yeah. So for us, actually, the metrics are very important to have.

We would have SLOs, we would publish them, we would try to keep them, we would review if we miss them and then do incidents management and retrospectives so we could avoid those. A lot of the good tooling came out of that was to ensure high reliability. highly like low latency which means you could ship product really fast as a company and the infrastructure would not get in that way

And that is why some of those metrics you see matter is because once we actually talked to the developers, we knew what actually mattered to them. That's what we focused on. So is it just, I'm just thinking about this, but is it safe to say that, I mean, I think we can agree that the platform team or the developer experience team at Uber did a great job, but they did a great job because you ran it like... like a product team.

Like you, as you said, you talk with the customers, you, you figure it out how to map the, how they feel or what they care about into metrics. You then monitor those metrics. And then you kept iterating on these things. Like if I replace this with, you know, like a paying customer.

It's the same thing, right? That's what a great product team does. Absolutely. You have to write a product talk because then the incentives are good on both sides. Because if the developer doesn't like the product, then you should... you should kind of be like okay what do i do to make it better so if the company is shipping high quality product then we should also ship high quality product for our developers and that's how we took pride in making sure that our developers could deliver

to the end user so yeah you're absolutely right the metrics I think a lot of people might focus about at a high level may not be enough you're right you have to talk to people you have to look at the funnel where are people dropping off like

Things like the onboarding, for example, for new engineers. Where would they have difficulty? Like the DevOps, for example, was like, hey, people would go look at these outdated docs and they would try to set up an environment and then just spend a lot of time.

So having a developer just eliminates that. And then later, you might have a situation where a build failed and there's a very easy quick fix. You should automate that. You should not ask the user to go to it. If there's a linter failure, in my opinion, We've failed because a link should not complain, it should either fix or not. Just telling them, hey, there's a problem is not going to do anything. You're so much pressure to ship product that if it's not blocking me, I will merge anyway.

right so if it's blocking me if it can be autofix why can't you have autofix right that's kind of how we took things i like that what is your take on measuring developer productivity Your team was called Developer Experience. I'm sure developer productivity came in. This is a very heated topic these days. It seems that for the past few years, and there's a lot of back and forth of what can you measure? What can you not measure? Should you measure diffs per engineer or per team?

team. You probably thought a lot about this or have been in the middle of this. What worked and what didn't? Yeah, so I think the very first thing we measured was just sentiment. So talking to developers, as I mentioned, the NPS survey was very easy because it was a very quick signal to see if things are in the right spot. If everyone's super happy, then there's no problem. But that's really the case. you know, problems that pop up.

I think as you mature your measurement, I think a lot of the frameworks we see out in the open are sort of inspired by what Uber did early on and took some of the good picks out. I think when people talk about like... devs per engineer. They're not really saying, hey, you should commit more devs per engineer. Is something preventing you from moving as fast as you could potentially? Because I can tell you that engineers, if basically nothing blocked them, would love to write code.

right if you're an engineer yeah you want to ship code you want to feel proud about what you shipped there's no one who'll come in and say hey i don't want to write these minutives i want to write code because it makes me happier right

And what we were looking at those signals for was, hey, do you have too many meetings? Do you not have focus time? Because devs were usually a matter of focus time. So when we improved that, we saw focus time improved. I think when we had COVID, everyone was working from home.

The JavaScript engineer shot up and everyone thought that, hey, people are working so hard. It is amazing. It's just because people just didn't have too many meetings initially. And over time and everything went to Zoom, it kind of... came back again down a little bit. It's usually a way to make sure that your infrastructure is letting people move as fast as they can.

And as you move roadblocks, you're focusing on the right things. And in fact, actually, one of the things we measured is time for code review. More than anything else, the time to review was the biggest bottleneck. Because as you mentioned, you would put up a PR in Amsterdam.

might wait for a review from SF. That's already like a 10-hour delay. And I think the P90s are pretty crazy. It would take days to get code reviewed. And that would just be the biggest blocker more than anything to ship product. and honestly like ci time is like a blip compared to the amount of time it takes to review right so the in the big picture i think we work to improve turnaround time by nudging people by auto approving prs that had minor changes that semantically would not change

the meaning or the behavior of the peer, that helped a lot because you didn't have to get another approval for making a comment fix. So you're doing a small stylistic change, for example. So that helped kind of unblock a lot of those scenarios. We had auto approve or auto land, which helped because if you're approved, then it would merge immediately. So you don't have to rebase and worry about conflicts. A lot of these kind of small things can actually have a really big impact.

But if you don't measure, you wouldn't know. So I think in terms of developer productivity, when you talk to your engineers, they might say, hey, I feel less productive because I can't do something. then your metrics should flow from that rather than just blindly taking a framework and saying, hey, this is a framework in the industry. This should be it, right? It may not actually work. I mean, it's not also the same for all kinds of developers. Is it safe to say that at Uber, you know,

developer productivity was measured in the sense that there were these charts, metrics, it showed the super engineer on your team, you could see it and how it changed over time, the time to code review, focus time, et cetera. But is it safe to say that These were measured with the intention of finding bottlenecks and what to improve, and they were not measured with the intention of

using them for performance reviews, promotion, or figuring out who's the low performer. Is that a fair assessment? Yeah, that's the usual controversy. People tend to misuse it. Guidance is always like, you know, look at them at a high level. And that is where a lot of these were aggregated, right? And you can find ways to like dis-entivize people from bringing those up.

right because you can easily catch bias we had for example folks on the performance company that would be there just to catch bias that hey are you just looking at diffs or you're not looking at the quality and sometimes like people may not have as much output because they have other

contributions they're making. They might be writing docs or they might be influencing strategy. They might be working on unblocking teams or figuring out product and business goals and distilling them to requirements in engineering.

So it was definitely like, I think initially people thought of it that way, but that was never the intention and that was never the case. In my experience, at least on all the companies I've been, we never looked at it as like anything more than, hey, it's just good to know that, hey, if you haven't done any PRs, that's a... that flag potentially. We had zero PRs in the entire year. Explain yourself.

We will clarify with the manager, hey, what's going on? What are they doing? But we never say that as a blanket, okay, that means nothing. So we always want to use this as a way to say, if there are red flags, we catch it, that there might be something else going on.

It was mostly used for unblocking teams from shipping fast. Yeah, so it sounds like it's just like if you have data and you can gather it and that data can actually help you build the right things, I mean, it would be silly not to do it. And as you said... start with from what the pain points are what people complain about i mean we always complain about well that was there like it was always about code review and how long it took code review to take and

I don't think we ever measured it. I think I left by the time this was there. But if we would have measured it, it would have just really shown that our team was... We probably have like, you know, like our median was probably more than a day because we were waiting a team on the other side of the Atlantic. And then we.

figure out how to cut those ties. Code is really a bottleneck, especially now with like AI tools, you could just generate a bunch of code and throw a PR. That's really the bottleneck. You're bringing alignment or figuring out product requirements or making sure you're not breaking the experience takes the hardest. So just measuring.

Output in terms of PRs is probably going to be harder as a justifiable thing after this new age of AI tools because people are just shipping so much more. We use a lot of AI tools at work, including our own, and we ship a ton more than we used to back at Uber. So you're now in the business of AI tools to help engineering productivity and engineers work better. How do you see these tools changing?

how we do software development. I'm talking obviously about the usual suspects, the coding, autocomplete, the co-pilots, also the agents, and also everything else that's coming. Yeah, absolutely. So we are very thick in the space, obviously. the autocomplete is a huge boost because it kind of in many cases helps you sort of like less type less but think more

So I think you probably use a bunch of these tools. I do too. It removes a lot of the grunt work, but it won't remove your thought process because the taste in what you want to do is still there, just not the how sometimes. It's like, okay. This makes sense, right? But I feel like a lot of the tools are either focused too much on their completion or they're only on the code review. I think back from when we learned things at Uber,

We had a lot of inefficiencies in things we wished we could solve with some sort of intelligent layer. I was, for example, going unblocking things. Like, hey, I knew exactly what would need to happen to unblock a build. So having some sort of energetic...

understanding of things that are happening in IDE, why did you type this character? That affects what's happening in code review, and that affects what happens on deploy. That affects what happens on your incident, for example. There is nothing that's cross-cutting. So that's kind of what we are trying to solve with guitar is like have this whole STLC under the purview and not just focus on the point solution of I'm just an IDE code complete.

or I'm just going to be on your CI reviewing stuff. A lot of those solutions currently are, I believe, good starting points. And my experience, like how I've seen technology shifts happen, the... Much nicer or more important unlocks happen a little bit later into the cycle because since we're very early in the cycle with AI, at this point, people are just experimenting stuff. But I believe that there's a huge value add for agents just because...

As you mentioned, there are some things that are so obvious when you think about it that, hey, we wish we wrote a script to automate this for support or for documentation. Those can be potentially driven by agents. but then still have the human in the loop when things need to be approved. That's kind of how we think about it. And as you're using these tools, how does it change your development?

obviously we're writing less code because now there's just more suggestions or there's also agents. But, you know, like... What does it allow you to do? Are you just moving faster? Are you actually having deeper thoughts? I'm just interested in what it means for you, the current version of.

These agents that we know, it's the start of the cycle. We never know how long it'll go, but clearly it's only been no more than two years. Yeah. I think it allows you to explore more paths that you previously didn't have time to explore because you could experiment much faster. and discard ideas much quicker. Because when you're prototyping, you don't need the full rigor. You can put them behind a flag and then say, hey, this looks good.

I think people are calling it vibe coding these days. Like, hey, this has the right vibe. We can experiment with this. Of course, it's harder when you have a lot of other constraints. You have to make sure the software is... secure compliant a lot of people are not thinking about that when prototyping right so it lets you prototype faster which is great and I think what's also happening is I feel now there's all of talk about

hey, junior engineers are going to get replaced. I think it's the opposite. My take is that junior engineers are going to thrive because they are coming with new knowledge, new ways of working with these tools. and are going to be much more effective because they don't have bias of working a particular way. They're able to achieve things that, for example, it would take a long time to even wrap up. It doesn't mean that you shouldn't know the fundamentals.

If you think about 20 years ago, they had a DBA and a HTML and a Java application engineer. There was no data engineer. And a webmaster sometimes. And a webmaster. There was no like SRE. That job no longer exists. No. There's no like front-end person. There's no mobile person. There's no like data engineer, ML engineer. There's so many more archetypes now.

or like, you know, subcategories. I think with AI, the general engineer is going to see a rise again, which means I'm able to jump into, for example, front-end without not doing much front-end because I can understand that, okay, this is what I expect. to happen and i would like to have uh this outcome with my with my software which means i can then focus on the other parts of the problem you mentioned vibe

coding. And this is a brand new term. What do you think it stands for? Is it just prototyping? Is it just like throwing out ideas or is it a bit more than that? I think it's vibe coding is just you trying to figure out how the system should behave when you're prototyping. The good thing about vibe coding is like you're able to like basically iterate much faster with this agentic loops that now you're just focusing on how would I actually.

achieve my outcome rather than the exact way to do it because you can always change those details later if you have the right abstractions you could swap layers out so I think that's changing the way people think about software because if you're someone who has taste and knows like this is the outcome i want to see on the ux you may not even need to know a framework you should experiment with it till it feels right

And of course, like you need to massage it to make sure it doesn't make it harder to evolve later on. I think a lot of the software today gets you to the initial, it looks great, but then how do you maintain it? basically sort of like left for a later time and i think a lot of people who are still coding with ai are early in the prototype phase i don't think at enterprise scale that would work because i can imagine it will probably mess with your entire

abstraction layer you already put in. So you have to really constrain it to work well. So wipe coding is great for prototyping at this point, but that's also why I think you can move a lot faster with less constraints because AI has a lot more freedom to explore. One of the problems that we're seeing, and if you're using it, you'll also see there's this...

Eddie Osmani called it the 70% problem that, you know, like vibe coding and these things that they get you started, but then it can get just really confused and stuck. And people see this like people who are not really technical, they kind of get stuck. And that's where experienced engineers really shine. You said previously that you think junior engineers will do great there.

How do you think less experienced engineers can deal with this? That's one. And then the other is, is this where we might see senior engineers actually thrive and spend more of their time? Yeah, I think the... Main differentiator there is like when things go wrong, understanding why they went wrong, which means strong CS fundamentals, strong sort of system knowledge of, hey, how does the entire thing work end to end? So senior engineers usually tend to have a better...

bigger picture so if they adopt these new tools actually they can get a lot more productive i can tell from my own experience that adopting these tools i'm able to get a lot more stuff done because i know for example this is how i expect my system to work

which means I can delegate to... I used to give it to a more junior person to understand the system. Now I can just give it to AI and I can check the work and I can come at it. But if you're very... stuck in the base and not want to use these tools you can still do it it's going to be a lot slower and that's totally fine too it's just a matter of like how quickly you want to ship and for things that are not critical you may want to still experiment to see what's out there because the things

The way they're going, the tools are getting better every day, which means over time, a lot of the mistakes that are happening today will start to disappear. They'll be like other agents that will check the work of... the first agent so they're not going to be as many mistakes you still want to have a human in the loop before you check in otherwise you will not have full guarantee that whatever you're shipping to the user is going to be good but you definitely want scene engineers to focus on

the high level system level knowledge and the agentic loops can be more nuanced and like more focused on smaller parts of the puzzle.

After nine years of Uber working on developer experience, you've now co-founded a company called Guitar. How are you thinking about... continuing this developer experience and also what's your approach to ai what are your bets on where the space is going to go yeah that's a good question so when we found co-founded guitar with my co-founder sally and raj we basically

saw that a lot of the inefficiencies we had, tools were not available back in the day at Uber. We saw because we had a golden path for developers. Now with agents, I think... We talked about DevOps previously, right? Like, hey, there's a golden path for a developer to get stuff done. So what if an agent had a golden path to get things done for a particular enterprise? So we're thinking of guitar, like the agents were building at guitar.

uh we just are going to launch a new product pretty soon and you can check us out at guitar.ai the agentic ai we build is actually inside the ide on the code review system inside your deployment it's across the board so there's no reason why you can't autocomplete like a deployment shop and not just be stuck inside IDE right and having an understanding of things like hey how are things going in production which part of the code is slow

These dots are usually what engineers connect, right? The context is what flows through your brain. And if there's a standardized path for an agent to like evolve software and maintain it, it becomes much easier to focus on the business value.

And one of the things that people dread doing is maintaining stuff like updating libraries or fixing tech debt or adding coverage. We feel like a lot of that grunt work can be done very efficiently with agents. So that's where our focus is that we don't want to be just like a code complete.

or within your point solution, we want to have it across the entire stack of software development. And we have that experience working on this for many years, talking to peers in the industry. There's a lot of potential for disrupting the space.

And the stuff we wish we had that, hey, I wish someone was on call during this time to fix a small thing. We can make that happen because we can give the agent powers to like unblock people when you might be asleep, which means you'll be on call less often. So we're thinking of it from a holistic developer experience standpoint, and producing more code is just one part of it. It's about doing it reliably, maintaining it, and making it understandable.

newer developers can understand what's going on. Because if you just let AI run amok on your code base and not have an idea of what's going on, then that's the recipe for disaster. So we feel like there's a lot of opportunity for making the entire experience end-to-end.

much more standardized so that the golden path for developers and agents is like really well laid out now like you know when i'm listening to this like One part of me is, if I'm a business owner, I'm like, oh, that sounds great because over time I might just have less developers because I'll have a really capable agent.

And as a developer, obviously one thing that pops into your head is like, wow, we might have a smaller team. Hopefully I'll still be there, but I might have fewer colleagues or I might be the unfortunate one to get the cut. Let's just run with this, that this future is coming and we will have a lot more capable agents. In this case, what do you think developers will do and what are skill sets that...

are worth investing in so that you will still be an efficient, a great developer in the future. You know, seen as a highly efficient developer 10 years from now, you know, your managers will be like, oh my God, like we cannot do work without this person. We need this person here.

And we should probably give them a raise because they're underpaid. Yeah, I think, as you said, there might be less people in a business, but there'll be more businesses. That's typically how a lot of these technologies go. If building software is easy, then the value unlock will be like actually the taste and the experience for the end user. Like what do we actually provide? If every website looks the same because you prototyped it.

in like a website builder then that's not going to be your differentiator right like even I think during the mobile era a lot of apps came up to do things like to-do lists or you know like reminders or like you know just scrolling social media But then eventually some clients are great UX. They will not because they're just a joy to use. So knowing what matters to your end customer is going to be differentiated for engineers to hone in on. So that means understanding the business really well.

And then the other thing is like, how do you build something for scale? Essentially, as you grow the business, you don't need as many engineers probably, and that's okay. And that might be fine because if you're at a smaller company with less number of engineers. if you have equity for example you might have more of the pie which means that's a good way to kind of incentivize people to experiment with more ideas and usually competition is good in that way

So you may not be bound by those restrictions that you have to always be like a big company. I think we'll start seeing smaller, more efficient teams who are going to be more productive and will deeply understand the product. And that's going to be, I think, a good. it like compete with other products in that space like the taste the art that goes into like crafting great UX or great end user experiences is going to matter more than how you wrote the code

Now, if I'm thinking, because I think it's a good thing back that, for example, even 15 years ago, 10, 15 years ago, we already had this, right? Like WhatsApp, they were... barely at 50 people when Facebook acquired them for $19 billion, which is crazy. This was no way I know nothing, but clearly they were a very efficient team. Instagram, I think 12 or 13 people.

Also, they built an app that was already 30 million users with that small, like even today, that would be a big deal. So it's like to get that skill set of. You, as an engineer, being able to do a lot with these tools with the small team. You mentioned taste. You mentioned art. What other things that are worth focusing on that should probably help do a lot more?

Yeah, I think having an understanding of the system layer is good. So I think the scalable part we didn't cover. So how does your app or software scale to more users? What parts of the system are? Less efficient, more efficient, because all code might do the same things, but less or more efficiently. And how do you maintain it? So that's the challenge a lot of people run into as software systems grow.

Is it easy to upgrade because you have less external dependencies? Is it harder because you have so many versions? The software might work the same today, but okay, three years down the line, if you can't upgrade and move faster, your competition is going to basically...

move faster than you because they started on a clean slate. We see that all the time. I think there's a lot of legacy technology or database systems. People are trying to move to modern systems. It's a big cost, right? And that's very expensive. A lot of engineering time wasted.

So building for basically maintainability is going to be important as well. Building for either AI agent maintainability or human understanding so that you don't have to look at outdated docs or do an expensive migration. I mean, for example, if I could wave a magic wand and move all my micro repos to a monorepo and everything just worked, that'd be awesome. I don't think any system can do that today yet. Maybe it would in the future. But if that's a reality because you designed your software.

to move that way that's great right so having that knowledge is not because ai agents are fundamentally based on expert knowledge right so if your knowledge is like understanding of your entire business because they can't really tell you How should you write your code for your end user? What matters to one business may not matter to the other. Some parts of the software might work well for one segment.

but not work so well for the other segment. So really understanding those business values will differentiate just AI-driven code versus how do you actually use that code to make your business actually thrive. Again, it might not happen, right? Or it might happen slower than we expect, etc. But what I'm hearing is, even if it does happen, having expert knowledge helps.

having tastes and you kind of get taste from seeing things or failing things. So is it safe to say that it's probably a pretty good strategy to try your best to go and work at companies that are either building stuff at scale?

Or they just have kind of taste, you know, they're startups that are known to do these things so that you can build up one of the muscles of like scale, taste, if you can switch between them. Because in the future, I assume that some of the kind of... repeated like the the successful people who you have a pattern will will will probably have the pattern of like oh they worked at companies that kind of did pretty groundbreaking stuff at their time

and now that we have these tools well yeah they're they're doing even more groundbreaking stuff and they probably build a bunch of their experience yeah the experience matters a lot like knowing a lot of the stack helps like when i was at uber i didn't do much work on front end but now i'm at guitar

I'm doing front-end, I'm doing infra, I'm doing a bunch of stuff. And I'm using agents to help me. We use our own agent to rewrite a bunch of our stuff. And I was like, okay, now I understand why this works that way. I'm a general engineer now. I have strong fundamentals, let's say.

I can see the system, I know this is how it's supposed to work now i've up leveled myself without spending it's kind of like that matrix movie where neo gets that you know upgrade to like no kung fu yeah but doesn't mean that he can beat the master yet you know like he still has to train up and understand it

Yeah, I like that. So with that, let's go with some rapid questions. I'll just shoot out some things and then you go, what is your favorite programming language and why? Rust. Rust. Since when? Yeah. Since guitar, actually, I was initially like, oh my God, thrust has a bad reputation for being hard, but it makes things so safe. It's hard to have, I think, like outages if you design it right. I mean, you can still have them, but like...

You can really understand the type safety is there to help you out. And you start treating it like your friend, then it unlocks a lot of stuff. You've spent a lot in Java and Go, right? You've probably spent half your career in those. Yeah, it's funny because when I graduated college, I told my friends I would never work in a company that does Java. And I did Java for nine years. So, you know, never say never.

What's an AI-powered dev tool that you use and like? We use our own agentic thing quite a bit. We call it Jimmy, which is a new agentic. Jimmy, yeah. We use the cursor as well, like, you know, the autocomplete, but we feel like Jimmy gives a lot more end-to-end stuff for us. So we've been using it very heavily, but you can also try it out hopefully soon. And then I use a bunch of other smaller, like...

claw directly obviously for question and answer stuff uh how to play with like some of the newer deep seek research and models and stuff like that because i've been hearing good things about them for more deeper work but haven't had a chance yet And what's a book that you'd recommend? My favorite book, I don't read too much, but I read this book early in my career called Head First Design Patterns, which is a little old at this point, but the patterns are really good because it really...

makes you understand how you can layer things. A lot of software today is just abstraction over abstraction over abstraction if you think about them. So it really helps you understand what pattern makes sense when and when to use it, how to transition between them.

I would highly recommend that. If you're trying to go into a more systems-level approach and want to design software for maintainability, that's very crucial. Making it pluggable, composable, and replaceable under the hood. A lot of the migrations we did at Uber was zero downtime.

No code fees. When we did the Java migration, there was no code fees. So that was a crowning achievement. Yeah. Yeah. And it banks these days still, you know, like they will shut down their thing for some migration for like a whole day on the weekend. in 2025. It's a big difference, as you say. Well, Gautam, I really enjoyed this conversation. It was good to reconnect and just see how developer...

productivity, empowering developers, you're still just running with it. Yeah, I think this is the area I love. like working in this area i can't see myself doing anything else i've been doing it for 10 years i hope to do it for 10 more we'll see but i hope i can make more developers productive

I hope you also found this episode about Uber's internal tools to build productivity and AI's impact on software engineering as interesting as I did. You can find Gautam on social media as linked in the show notes below and check out his company guitar at guitar.ai.

For more deep dives on Uber's engineering culture, check out the Pragmatic Engineering articles linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast and a special thank you if you leave a rating. Thanks, and see you in the next one.