Hypergrowth startups: Uber and CloudKitchens with Charles-Axel Dein

At Uber, when did you join? I joined in 2012. At the time, yeah, the team was about 20 engineers. There was no roadmap, very little process to learn by doing essentially. What do you see? How is AI already changing software engineering, especially for the work that you're doing at Cloud?

kitchens we did our own study we found it was moderately useful every single time we have one of those revolution and ai might be the biggest yet don't get me wrong but every time we have this revolution the press and everyone speaks about replacing engineers we're still there what are some non-obvious

recommendations to thrive inside a high growth startup i talked about memorization using flashcards to memorize stuff very powerful and second i'm not sure if it's super non-obvious but extreme ownership so that means what does it take to thrive at a fast-growing company as a software engineer

Charles Axeldin was engineer number 20 at Uber and saw firsthand as the company grew from 20 engineers to more than 2,000 in just five years. He also happened to hire me at Uber and was my first manager at the company. Today, Charles works at Cloud Kitchens and has been maintaining the wildly... popular GitHub repository, professional programming reading links for 15 years. In this episode, we go into what it's like to work inside a rapid growth startup like Uber during its high growth times.

how to be a standout software engineer, including tips on how to lead projects efficiently and the importance of shift stuff and lift people around you mindset. Charles has personal productivity tips, including why he uses flashcards to memorize things like architecture patterns and data science methodology.

how Charles thinks AI will change software engineering, and why migrations is the best use case Cloud Kitchen has found so far for AI coding tools. If you're working at a fast-paced startup or plan on working at one and are looking for tactical advice on how to do well in such an environment,

episode is for you. This podcast episode is presented by Stansig, the unified platform for flags, analytic experiments, and more. Check out the show notes to learn more about them and our other season sponsor. With that, let's jump in. So, Charles, welcome to the podcast. Thanks, Gergely. I'm very happy to be here. It is so nice to be back. And this is not the...

The first time when we're sitting in a situation like this, it was a bit more stressful situation. It was an interview at Uber. You were the hiring manager. And I think you were the final interview in a series of interviews. And that's how I joined. That's how we started to work together. Yeah, and actually right before you joined, I don't know if you remember that, but I called you to ask you if you could change stack. I think you were hired.

As a backend engineer, and I asked you to do iOS because this is where we need it. And you said, yeah, let's do it. Android. It was a very interesting interview situation. I was doing iOS development back then. I did a Windows phone before. I don't know if you know, but my interview got messed up. I thought I would be doing an iOS interview, and then they put me on a backend track. And I did backend before, a few years before, so I was like, all right, let's do it. And apparently I did.

good enough on it, which was surprising. And then I was supposed to join as a Python engineer. And I didn't do Python before, but obviously Python, you can learn easily. And I was like, okay, let me learn it. So I got my Python book, Python 101. And then you emailed me saying...

Could you do Android? Was this typical of Uber back then to have this kind of hectic or what was the reason? It all felt very hectic when I joined. Yeah, it was definitely very hectic. And it's interesting because then when you... when you're during those hectic times, like you feel like this is not normal and I would much prefer a time where it's much more quiet. But then when it gets quieter, you miss the hectic time. So it was definitely that hectic.

It's not the most surprising things that happen when it comes to hiring. But yeah, a good hectic, right? Like you're going super fast. So you have to ask people to be flexible. And I think that's what people look for in startup, right? They want to see things that are very different, where they get exposed to a lot of different things. And that's definitely what you got with a panel.

for a stack, a background for another stack, and then you get hired and you get asked on your first day. I think it was close to your first day. It was a week before. Yeah, Android. It was pretty hectic. And at Uber, when did you join? You were very early.

Yeah, so I joined in 2012 thanks to the first driver operation. who I was working with before. And at the time, yeah, the team was about 20 engineers. Like engineer number 20-ish. Yeah, something like that. So definitely super interesting because there was no roadmap, very little process. So definitely discovering a lot of things as you go. And what better way to learn, right? Like when you are at a startup.

Things are very unstructured and you get exposed to a lot of problems and you make a lot of things up. You learn by doing, essentially. And it was a truly amazing experience. I think it was the same for you because you did. And then you joined as a software engineer and then you made your way. your management right.

Yes, that's right. One year later, Tuan Pham, who was the CTO at the time, asked me to step in. And the best career decision ever was really a rewarding experience. And then since then, I've moved back and forth between... Software engineer and engineering manager. And I really appreciate doing both. I think I believe in really hands-on engineering managers.

And so by being that early, you must have worked with Travis Kalanick, the co-founder of Uber, right? Yes. I actually still have some pretty good emails when we broke features. What was interesting at Uber is that...

we build a product that helps people make a living. And so when there's an incident, it's not only like a feature that is broken, it's also people who are not paid on time. And I remember this... this event where the payment process for driver failed and this was right before Christmas and so we got forwarded an email from a driver who couldn't purchase gifts for their kids and

I think that shows the responsibilities that you have as a software engineer when you own things in production. It's not only features, it's not only code, it's also potentially people's livelihood. I remember when I interviewed at Uber, actually, you told me something similar. And it was the first time I kind of like paused of like, oh, I could actually work on something that has real world implications.

in terms of people relying on it being important. And I do remember that whenever we did an incident review, it wasn't just like, I don't know how many ad dollars we lost, which again, in some places that's what it is, but it was like how many people's...

Rides could not be there. And then like behind that, there's a story, there's frustration. I mean, I've had before when, you know, like a driver cancels, for example, I'm in a hurry or it's stuck in a traffic jam, I'm late. And that itself is frustrating enough. Right now I'm working at Cloud Kitchens, which is another startup that works in the physical world, right?

Today, we speak a lot about like AI startups and it's evidently a very important sector. But at the same time, like all of those startups that actually change things in the physical world and have an impact on people's life, I think people should also consider joining them because... you can see the result of your work. So that's one. Two, the physical world is a source of never-ending complexity and challenges, right?

For instance, when it comes to delivering food, you have the optimization across space and time that is really interesting from a technical standpoint, from an algorithm standpoint, from a system standpoint. From a latency standpoint, right? Like you have a budget of time that is not infinite because the food needs to get delivered. So it's really interesting to get exposed to the physical world. And the other thing I would say is...

We talk a lot about startups and virtual products and social networks and their impact on people's lives. That is not always positive. We talk a lot about addiction, for instance. Software that is used primarily to optimize processes in the physical world, you can say that it's fundamentally good, right? Yeah, yeah. And very different challenges. I feel we are seeing a little bit more of a push where...

more people are considering and it's a bit more visibility of these software. But, you know, one thing that is just not as, I guess, sexy about them is the hyper growth is rarely there. Uber was an exception and cloud kitchens might be another exception. So at Cloud Kitchens, how are things similar or different to Uber?

So you're right, like the time of hyperscale startups is probably behind us. I think you did a lot of articles on this, the end of zero interest rate. What this means is that the model of this hyperscale startup that grows super fast and... extremely fast is probably behind us. And it's probably a good thing. I think the thing we do differently at Cloud Kitchen is we're much smaller in terms of team size and much more focused.

And yeah, you're right. It's really interesting to see that there's a bit more humidity, there's less money floating around, which leads to probably better decisions. I think at the time of Uber, there was probably like a lot of waste. in the way we hired, the way we built teams, the way we started projects. Actually, talking about how we manage projects at Uber touches on the original story of our season sponsor, Linear.

The idea for Linear came about when their founders were going through hypergrowth phases at Airbnb, Coinbase, and Uber. As you'd expect, with RealScale, these companies started to slow down. What used to take days started taking weeks, then sometimes even months. Not because people worked less harder, but because there were a lot more moving parts that needed to be coordinated.

As an example, in the early days of Uber, it took a single engineer about five days to integrate, test, and ship a new payment method to the app, Google Wallet. But years later, it took two months for three engineers on my team to ship and release Google Pay because there was so much more planning, coordination with stakeholders, working with other stakeholder teams, and the vendors themselves. As teams grow in size...

product development gets hit particularly hard. Every team involved in the process uses a different set of tools and workflows. This fragmentation means there's no scalable way to answer what's been committed, what's at risk, who's actually accountable. Who are we building this feature for? It's often a total mess.

The conventional approach is to compensate for tooling apps with more headcount or more status meetings. But in my experience, it doesn't help much. This is why Linear exists. To give high-growth teams the clarity and coordination they need without the overhead.

Linear's founders build a tool they wish they had during those chaotic hyper-gold scaling phases. You can try it yourself at linear.app.pragmatic and see why teams like Ramp and Clay also switched over. So let's talk a little bit about that. I do think hyperscaling is behind us because there was this special time where...

There was so much money on the market, and Uber was so good at raising money. They raised billions for a physical product for every single round. The valuations kept going higher and higher. We are seeing something similar right now with AI, but it's not in the physical world.

you can argue if gpus are but i feel that's a little bit different but let's talk about what it was like to be inside because because i remember when i joined it was crazy and one of my first memories of how crazy it was is when i became an engineering manager

I asked you, I was an apprentice manager, and you were my manager, and I asked you, how does headcount planning work? And you told me, the way headcount planning should work is we make a plan, we make an ask, and we do it. He's like, in reality... You keep hiring and when you hit your limit, you get more headcount because it just comes out of this black box and just more headcount comes out of it.

it's always been like this. And I was like, and you were like, don't worry, it doesn't make sense. Just keep hiring. Yeah, until it makes sense, right? And yeah, clearly there was like probably a lack of like financial... professionalism and being diligent with the company's resources. But I think now, as you've described, right, like with zero interest rate, it's probably much sounder like financial principles. driving like the headcount planning. But yeah, to come back to Hyperscale.

It's really chaos. That's what it is. But good chaos, right? Like chaos where you get exposed to many problems. And if you're curious, which I think is a key skill if you want to or key quality to have if you want to grow.

then you get exposed to so many problems at the same time, which means that you have to ramp up on those problems really, really fast. And you get to learn because the best way to learn is to try something, get feedback, and then keep on iterating with a continuous improvement mindset. So that was really fascinating. But you're absolutely right. The hyperscale meant...

one onboarding per week. So for instance, when you do one engineering onboarding per week, you have to standardize it, right? Like you have to structure it, you have to process it. Just in Amsterdam, we were a smaller office, but we had, as you say, an average one or two engineers joining per week.

in the office and we started off as when i joined it was about 20 engineers and every every week we would have one or two new people and i remember that as a result we actually we spent a lot of time improving the onboarding process, which is kind of weird to think now because a lot of companies that I talk with today, they don't care too much about it because they have a new joiner like every second month or something like this.

But we were focusing a lot. Because we do so much onboarding, obviously, we did so much hiring. So we had to optimize around that to batch. the days that engineers could could be hiring we had this thing where if there was a crunch time for a project we we might not do interviews for a week and the recruitment team was really upset about that because their targets were different. Can you explain what you saw, what hyperscale actually meant in terms of the...

the day-to-day and then how it later eased into just what normal thing is. Because I feel a lot of people have not seen it. They will probably not see it. So it's good for us to describe what we saw inside. Yeah. And by the way, on the hiring side, the irony is usually the team that needs the most new hire is going to be the most impacted.

by interviewing, essentially, because you have to interview for your team. At least that's how it's organized at most startups. You remember it, right? I don't want to say a never-ending stream of incidents, but a lot of incidents, right? A lot of incidents where you feel like you...

you're covering like the immediate action items that result from the incident, but you don't have time to actually fix the fundamental architectural root cause complexity or some other things. I would say, yeah, incidents.

Definitely. On call was terrible. So you had those incidents that at the same time, you also need to build new features and build new products and also deliver, right? Well, I remember that we... we had a lot of enthusiasm through the door so i i still think back how we could manage with so much like our on-call was terrible like we were woking up in the middle of the night like almost every night and we just we tried to fix it but it was just patches

But I remember that because a lot of new people were joining and people were very excited because it was from the outside, the company was very attractive. They brought so much energy and that energy definitely lasted for a good like four to six months.

And we had a never-ending stream of people who, you know, just as you were kind of getting tired, someone like, oh, cool, let's do this, let's fix it. And there was a mentality of let's fix this, which on one end was a lot of band-aiding thing initially. Later, as I think our growth slowed, we started to think about like, okay, how do we fix the system? How do we turn this into a platform? How do we rewrite? Oh, and there are so many, so much migrations. Yeah, too many.

Yeah, after 1,000 engineers or 1,000 employees, you don't need a customer, right? Like, you're going to have teams that are going to create migration requests for other teams, and the company can operate in a closed circle, right?

You can create one. Yeah, the incident is really the best way to learn about your architecture's deficiencies, right? Like you can look at the architecture on paper and you can see, okay, this component is probably a problem, but the best thing really to know the bottlenecks is to see what breaks. And especially in 2012 and 2013, every Friday evening, I would prepare to come back home and then something would break and then it would be firefighting mode.

And this is how you learn that. Oh, Redis breaks after that. And oh, Postgres breaks after that. And oh, we have this queue here that is not dimensioned correctly. Or we have this instance. And at the time, yeah, autoscaling wasn't really a thing. Interesting. A good way to learn, essentially, about your system's efficiency. Still to that there, right? That's a great way. I'm not sure if it had to do with hyperscaling or not, but we had this rule that when you are deploying a system...

that seems like a medium-sized change, go to the Slack channel or the chat channel and let people know that you're doing it. Because I... I think we're kind of used to this could cause issues. So it's just giving heads up that if you see something going there, just let us know. Again, back then, we didn't have that good observability. In fact, we had to build our own observability. There were no vendors that we could onboard. I do think that this high growth, high number of incidents.

hard to slow down and and we always had to keep shipping so the the trade-offs the reason we couldn't really stop and fix things Because we have, I remember with planning, we're like, okay, we have, let's say, 10 engineers and we can do three projects at max. And each project has such a high impact. We were talking the $50 to $100 million of incremental revenue for that team.

that if we would have stopped to fix the systems, we would have said no to bringing in that much extra revenue, which kind of didn't make sense. So we tried to do both. And we prioritized building new stuff. And sometimes you have also like regulatory context and other things like there are certain projects that you must do and it's not really up to you to make that call. But yeah, coming back to...

to the incidents and the fact that you had to announce deployment. This is why I think the most fundamental way to improve this is to decouple the release from the deployment, right? First deploy your code and you get it's behind feature flags so nothing happens. And then you turn on your feature flag just for your user so that you can test and then you can roll out slowly. This approach, very simple approach, works wonders in terms of providing stability because then...

You get into the habit of making sure that a deploy never breaks in. You first release and test with your user. And then because you're the one turning on the feature flag, you are presumably following the feature. monitoring it with a product manager, etc. So this is a very simple strategy to ensure that that would have been, I think if we had better used it, we would have saved ourselves a lot of unnecessary craziness.

One thing that was really unique about Uber when it came to deploying is for high-risk environments like banks, they would typically have... different environments. They would have the development environment. They would then deploy to the staging environment. They might have user acceptance testing and then production. And these are all physical environments that need to deploy it. Uber didn't really do this. Instead, we had the concept of tenancies.

So we would run the same code everywhere, but we would have a test tendency, for example, plus feature flags. What do you think about the upsides and downsides of doing either, of having the separate? stable environments, especially when we're talking about the physical world, about when you don't want to break things, when breaking things does have a lot of implications. It could be upset customers or money lost or churn or real-world impact.

Yeah, and actually when I left Uber, there was no tenancies yet. We were using DevServer. I don't know if you remember that time where every engineer would have their own development environment where they would install the whole stack. on one machine. Evidently the machine was oversized for...

What we were doing is, so we were installing the whole stack of Uber, or at least most of the stack of Uber, and then that's what you would use to test end-to-end. What's great is you could share it, you could go crazy with it. But yeah, I think we missed having a pre-prod or staging environment.

I think you need both, right? Like you need a staging, you need a way to have, or at least the three of them, right? Like you need a way to quickly deploy one instance of your service and then route traffic with it with tenancies. You need a staging.

environment where you can go crazy and probably some kind of like pre-prod where it's much more stable and you open an incident if something is broken. The idea being the earlier you detect a problem, the better because it speeds up the process, right? If you detect an incident at production stage, you're going to waste hours rolling back, maybe fixing forward if you don't have a good rollback story. So the earlier you detect, the better. I remember that we had an incident.

where someone on social media posted that something is broken at Uber. And I remember you were upset. And you were upset.

that we didn't catch it that our monitoring did not catch it and that someone had to post on social media i remember you might not remember what you told us like this is the ultimate failure of us needing to learn from a customer that our system is broken and instead of us like like like we should have had a system flagged and you know if we missed it that would have been on us but and this this this still stuck with me this lesson of

You were so mad, not because of the incident, but the fact that we did not have the means. We were basically flying blind and someone exposed us. I mean, it was kind of a good thing, but this stuck with me. Since then, I remember like, okay, how can we make sure that we will know and we will not have to have someone tell us like, okay, this is broken. Yeah, frankly, to this day, I don't think even on my current team, we still have to work on those things, right?

There are three metrics at Cloud Kitchen that we always look at for any incident. Time to detection, time to mitigation, and time to resolution.

The most important part for me is time to mitigation. It means how much time does it take us to bring the system back to a state where the customer doesn't see the impact, right? Resolution goes after. And if you... waste like one week of time because you did not detect the issue there you go this is what you need to fix and at scale especially at uber scale like being able to detect

is much easier because you have such a high volume that if something breaks, you must have some kind of monitoring that will detect it. One thing with hyperscaling is things are so fast. You keep hiring people, but you're hiring people a lot slower than... and what your growth is in terms of customers, features, all those things, automation becomes really, really important.

You've always been a huge fan of automation. I remember at Uber, you kind of built your scripts to automate this or that. What have you learned about automation, of how it works, how it doesn't work? Maybe some things are not as obvious about it.

The most recent thing I learned about this is this article I read about the Ironies of Automation, which is a pretty old article, but it's fascinating. And it talks about two things that I've definitely seen and I've made a lot of mistakes in this area. One... Sometimes when we automate, we replace user error with automation designer error, right? Like we are lacking context. We don't understand how the software or like the process is used. So when we automate, we actually...

put in the wrong automation. That's one. Two, because you cannot automate everything, you usually automate the simplest things and you leave the user in charge of the most complex stuff. So that's the irony here. It's like automation sometimes fails. So what can you do to prevent that? The simplest thing is observe and get a lot of deep understanding of what the process is.

You have to do it manually, right? Like we say, startups should do things that don't scale first. So do the things manually first. This will give you the business context, product context, operational context to then automate correctly. And then the second thing is transparency, right? So many automations, particularly in the developer experience world, automate so much, you don't see anything. And then when something breaks...

you are left to debug. I'm sure it happened to you at Uber with some of the developer experience products. Yeah, and when you set to do things manually, at Uber we had this really interesting thing called sanity tests. Sanity tests were, we were in charge of our team loan payments. So everything in the Uber app, there were like 12 different ways to pay from credit cards, Apple Pay, Android Pay. And there's a lot of like regional things. Like in India, there was Paytm.

a bunch of others and we would just every week we would need to make sure that the payment would work so we would go there we would order an uber and like see that the payment went through and we would actually do this manually back on what sometimes we mocked up But every time, we would go through it. And when we did it long enough, we're like, this is... And we needed to do it manually for a few reasons. One of them, it was just hard to automate because...

We had to talk with the real payment providers and a lot of them did not offer APIs to do this. There was also fraud detection. But we kept doing manually and after a while it became really, really painful. And then we figured out how can we automate this to some extent. And then we actually started to make progress. But we started with just this thing. And we did it for, I think, many weeks. And in India, we got so tired and frustrated that...

we were looking for creative ways to get out of it. Yeah, I don't know if you remember, but we had to ping an engineer in India to share with us the code that was sent via SMS. It was like so inefficient. I mean... End-to-end test topic is a fascinating topic, I think. There is something to be said also about automating them too much because the more, first like payment and login flows typically are designed against automation.

So I think that's one of the reasons we couldn't really automate them for a long time is because they are specifically designed to counter that. And then the other thing is when you automate too much, those like end-to-end tests, then... you get a lot of flakiness because you're not only testing

Your flow, but in the case of this SMS-based payment flow in India, you're also testing the quality of the SMS reception, any latencies there. You're testing many different flows from the banks that you don't control. So those... If those tests are constantly failing, then you get flaky tests, and flaky tests get ignored. One interesting challenge during the hyperscaling time was hiring.

Again, most companies will not be in hyperscale mode, but every now and then you need to hire really, really fast. This might be because you get a big funding round or for other reasons. What did you learn about what works? when you need to hire efficiently and you need to hire a lot of people, oftentimes experienced people.

you look at the whole process, right? Like you look at every single step at the process as a funnel, as a pipeline, and you see where you do you have a leaky bucket. So from a metric standpoint, it's very important to have that. The other thing is you build a partnership with a recruiter. So many people don't do that. You have to build this partnership so that you have a feedback loop where your recruiter knows what you're looking for and make sure that those candidates are sourced.

our phone screen from a recruiter standpoint and then get through the process. And then the last thing I will say is like every single step of the process, you have a continuous improvement mindset. One thing you remember we did at Tuber, we do it at Cloud Kitchens as well, is pairing interviewers.

You have two interviewers and this way they can give each other feedback. They can train each other. There is only so much you can do when it comes to interviewing training. And so to pair interviewers, you can share with... feedback between between the two the two yeah i remember the two things that we did and i don't think many places still do it it's like first we had a weekly catch-up with the recruiter so engineer managers and recruiters would do it it's a bit like a team retrospective

and and you know they would talk about things like what are their sourcing strategies like oh what kind of cohorts are they targeting or linkedin has this new feature that i can and they will share tips that were like oh pretty cool or like talking about what kind of companies they're thinking of

targeting and we'd be like oh what about this one i just heard that there i don't know there there's some negative news coming from there maybe people will be interested of joining from there and i've never seen that before and it was really good and When we started hiring, we would just sit down with a recruiter, like spend an hour talking through.

Here's what I'm thinking. Here's what this person would do. Here's what I think a good hire would be. But the recruiters bring a lot of expertise. So they would ask questions like, okay, for example, and a lot of clarifying questions like, I get so annoyed as an engineer when a recruiter emails you and said, like, I'm looking for five years of C Sharp experience. Because if you've done, you know, Java, Python, whatever, you can pick up C Sharp.

But we talked this with the recruiter. So they asked, like, what is your tech stack? And we said, OK, Python, a little bit of Node.js. Back then, we were choosing Go. So they were like, OK, so we need people with... expertise these languages like no no as long as they did some language that's okay in fact we don't care about the language that much and they're like oh okay so and because of this we help the recruiter

find better people or not reject people who could have actually worked out. 100% like this relationship between the recruiter and the engineering manager is critical. And actually something that came from Tuan Fan, which... you should have also on your podcast. He told me that every morning he would come and go and check out with the recruiters and say, hey, what are some of the interesting profiles you saw?

this week. And it's a great way to have this feedback loop. The recruiter bring a lot of value and have like their specific skill set and you know who you're looking for, you know who your team is missing. So this is like, if you don't have this tight feedback loop.

it's going to take a lot of time to hire. Yeah, and then we had this interesting thing with the pairing, as you mentioned, with interviewers. We always had a primary interviewer and a secondary, and the primary one would... lead with the questions the secondary would sometimes step in

And you can discuss in advance. And we had this concept of if someone signed off as an interviewer or not. And when they were not yet signed off, they might lead the interview, but then the secondary was a lot more experienced. they would give them feedback afterwards. So after the interview, they would come and say like, okay, here's some feedback on, you could have let the candidate talk, talk, talk a bit more. It was great that you jumped in and gave tips and so on. And we tried to...

Again, this was something I've not really seen before. Most engineers, I think, are just not really good at interviewing, and they rarely get feedback. And we're trying to get this feedback going, set expectations.

We also did some interviewer training, but as you say, it's hard to do interviewer training. Yeah, so we have the same process right now. So you shadow first the primary interviewer and then you reverse shadow, meaning you drive the interview and then the other experienced interviewer will give you feedback.

Yeah, you're absolutely right. Just because you're a great engineer doesn't mean you're immediately a great interviewer. You can become a great interviewer with training and with on-the-job feedback. So that's why this dynamic is critical. So how do you know if you're in hyperscale? Hypergrowth, sorry. And how might you know that you're getting out of it? Again, you've gone through this at Uber. At Cloud Kitchens, you might have had some phases for it.

What are kind of signs that you're like, okay, or this is just really intense growth and I need to operate differently in this mode? Yeah, I would say it's a bit what we talked about in the beginning, right? So a lot of hiring and then... things breaking left and right without giving you the time to fix the fundamental root cause. And I would say this is probably the best sign that you're getting out of this hyperscale is when you feel like, okay, now I have time to actually...

look at this thing holistically and fix and build a system that I'm pretty happy with. Not necessarily a second system from scratch. It's not always a good idea or rarely a good idea. But when you get into that territory. That works. Speaking of thriving in hypergrowth, one of the biggest challenges is maintaining release velocity while avoiding outages as you scale. From my personal experience at Uber, this is hard to do.

Most engineering teams think they have to pick one, shift fast and accept higher risk, or slow down releases to stay safe. But here's the thing. Hypergo teams at companies like Notion, Brex, and Atlassian don't have to sacrifice speed for safety. They use the same toolkit that powers Meta and Uber's experimentation systems, and now it's available to every engineering team. They all use Statsig.

Static is our presenting partner for the season and they've built a complete data platform that lets you ship features and measure exactly what each change does to your key metrics. This is the same infrastructure that growth engineers use to run hundreds of A-B tests per year. Every feature release shows you exactly how it moves conversion, retention, revenue, whatever metrics you care about.

Built-in analytics, feature flags, session replays, default toolkit. No switching between different tools or trying to stitch together your own measurement system. The gradual rollout approach is crucial here. Start with 1% of users, see how it affects your metrics, then progressively roll out to more users. If something goes wrong, instant rollback. If it's working, you can confidently scale it up.

The validation here is incredible. OpenAI was such a heavy user of Statsik that they decided to acquire the company. Talk about product market fit. Statsik has a generous free tier to get started and pro pricing for Teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statstick.com slash pragmatic. What can you do when you're feeling really overloaded? I remember, and you were my manager, but there was a time where you looked pretty burnt out.

We had performance season and a manager left the company and suddenly their reports also report to you. You had suddenly 30 reports and you had to do 30 performance. uh check-in conversations i remember that when you did the last one the the few of us more more experienced engineers we knew like we saw your calendar it was full and when you came out we were there we're kind of clapping that that you're done because it because it took like two weeks

And I remember at the time, like, it was, so you had 30 reports, you were expected to get, still get stuff done. I think you were still doing some hands-on work. And, like, you could tell that usually you're... Pretty chipper usually, but back then you were not chipper. What did you do to get out of this situation or to push through it? Yeah, I would say there's two things. There's one, personal productivity. It's a topic I've always been super passionate about.

always invested a lot. Like the first book I read on this topic was Getting Things Done by Alan, which is a pretty good, I think it's also a section in your book, by the way. It's a critical skill, right? Like the earlier you invest in your product. personal productivity, the more dividend it's going to pay. And I really believe in compound interest, right? Like you invested this. And then the second thing, it's a principle that works wonder everywhere. It's divide and conquer.

Yeah, you're right. I remember that time you have 30 reports, you cannot do everything. So now you're going to have to find people who can... take over from you some of those topics. So I remember asking you to take lead a project, for instance. And it's a great way because you give responsibilities to people. You help them stretch outside of their comfort zone and you're saving time.

So it's a win-win thing. I remember that you did it and what I liked about it is you were very explicit about the ask. You were like, I need you to, yeah, for example, lead this project and... I don't have as much time to spend on it. I'm expecting to check in with you once a week. If you need something more before that, let me know.

And then I think you also went more specifically, I'd like you to make a plan on how you're going to do this. Let's check in with it. And it was, yeah, so it was a way for you to spend less time, give more responsibility.

And actually, people liked it because people were growing professionally. And they also understood the reason of why this added responsibility is going to them. And if you're smart, which I think most people were, they understood, like, this is a good thing because with more responsibility... means that I now have more opportunities to prove myself. I can now grow in a direction either to be a lead or if they want to be later a manager or into the staff direction and so on.

Yeah, this divide and conquer is very similar to what we do with software, right? Like we create an abstraction, we give it responsibilities, we design an API that is clean, and then evidently some details might leak. some implementation details might lead. So with a project...

you're giving the responsibility of a project to somebody, but some issues might require your involvement and that's all fine. But then at the end of the day, that's still what you expect from the person who take over, right? Like you're expecting them to drive and to somewhat hide some of the implementation detail.

from you. And yeah, so it provides growth opportunities, that's for sure. One of my managers told me like one of the most powerful words you can or expression you can tell somebody is I need your help, right? Like this is very powerful, very simple, right? I need your help with this thing. And the employee feels also empowered to make decisions. Yeah. And by the way, I think you can do this not just as a manager, but also when you're a more experienced person on a team.

And you have someone who's less experienced and it does work magic. I think it does create a sense of responsibility. I think we also tend to sometimes forget that as soon as you hire someone, even if they're a brand new grad like this.

these are fully capable people like sometimes i think back on how in the industry sometimes we have the tendency to kind of over baby the the junior engineers like oh this person has no experience well if you think back of like the people who built facebook into the you know trillion dollar companies today There were 19 and 20, like dropped out of college. So all I'm saying is like people...

Especially the people who go through a pretty high standard hiring process, they actually have a lot of capability to do that. I sometimes need to remind myself of that when I was a manager or a tech lead. Yeah, plus the best way to learn is to make mistakes. So, you know, if you want to invest in your people, you have to let them make their own mistake.

Yuki is still right, one of your most popular GitHub repositories, which keeps going viral whenever I mention it. It's called How to Be a Professional Engineer. It has a few tens of thousands of stars.

is this collection of really, really good reading resources? How did that start? And how are... How are you updating it? I understand that you started to do it for yourself initially. And in fact, you already did it when we were at Uber and you forwarded it to people. You were like, oh, check this out if you'd like to become a better engineer. Yeah, I think the way it started is I wanted to...

automate the process of giving people feedback and sending them to certain good articles. So I started compiling this list of topics and I put what I considered like the classic article on this topic. So really like articles that have really changed people's mind, that are really influential and kind of... I've driven a lot of engineering practices. And then I started doing this. So one thing, speaking of personal productivity, that you can also invest in as an engineer is...

I have a good process for keeping yourself up to date with what's going on in the industry. And so I try to read, I mean, total one hour per day fiction work as well. We can talk about that later. I try to read a good bunch of engineering articles every day. And if I find a new classic article, I add it to the repository. And I've been doing that for the past 15 years, I think, something like that. How do you find where to read? What are your sources?

Yeah, so the main one is Iker News. It's a good one, isn't it? It's the best. Yeah, it's still the best. Iker News, I receive like an RSS feed with a 10 top article of the day, plus I check it because sometimes you have like some... diamonds that don't necessarily make it to that top 10 list. There are some really good newsletters. The Bytes one for Fontaine Engineer.

It's hilarious on top of this. Like every time I have a chuckle because it's like just so well written. I also follow like newsletter about the programming language that I use. So there's Python, Java for... Yeah, a lot of the software tech lead is really good as well. You were an engineer yourself. You manage a lot of pretty good engineers. Can we talk about a story of...

of a standout software engineer and what made this person stand out? Yeah, there are so many good stories. I'm not sure I want to single out somebody in particular, but... Some of the traits of like an archetypically, typically good software engineer, I would say there's a couple of things. There's one, shipping, right? So I've written three or four career letters. And a lot of career letters in the industry, after senior, they over-focus on meta work. Reviewing RFCs, attending meetings.

influencing that, strategizing this. It's really difficult to understand what's going on. So the first quality, and we try to put that in the Cloud Kitchen's carrier ladder, is the focus on building, shipping value. being creative, being an expert.

in your programming language, in system architecture. So that one, shipping is really key, right? So even at the above senior, like the staff engineer level, like you still place focus on, you still need to ship things. You need to get into production. Absolutely. And we expect... instance staff engineer to really find creative ways to speed up execution or achieve a 10x improvement in quality and that's that's what we expect not

only reviewing RFCs or attending meetings, right? So that's one, shipping and lifting, right? Lifting people around you. This is pretty cool, right? Like we are knowledge workers essentially, right? So you have to train people around you. You have to give a hand.

You have to help. You have to have a good attitude. I think the best engineers that I've worked with have this amazing attitude of ownership, of taking a problem and not stopping at team boundaries, for instance. A couple of stories here, but like... And software engineer was like identifying a problem and they are like a mobile engineer. And then they go...

into the API gate where they see the problem is not here. And then they keep going. They go to the backend and they actually make the fix in the backend, even though they're a mobile engineer, right? And by the way, the amazing thing is in this age of AI, you can...

really bootstrap that with AI, right? I feel there's starting to be no real excuses because before AI, you could say it is hard to onboard, it's hard to get to know, it takes time and effort. And I mean, it still takes time and effort to become an expert.

But as you say, like to unblock yourself, like at an age and time when a product manager can open a pull request that might be accepted, I think there's no, I feel engineers are necessarily becoming full stack with an expertise in their home stack. Martin Fuller posted a brilliant article, I think, about the expert generalist. It's funny because...

He mentioned that this T-shaped person that we often talked about, like this person who's an expert in one thing and one thing only. And then like broad on. It's... comes from the Valve software handbook. But I've never seen that in real life. And it made me realize that. Actually, right, what you're looking for is more like a rake.

Somebody who can go deep in a lot of different areas. And with AI, you're absolutely right. Like for instance, one of the best use case for AI I have seen so far for me is like, there's a problem with this feature. Find me where the code is. And then I read the code and I understand, or maybe I need to understand.

how much time it's going to take to fix this or that or to implement this or that. Find me the code where it is. And we use a monorepo at Cloud Kitchen and that helps, right? Everything is in one spot. So you can ask those kind of questions and get this. kind of fun. And so what other characters? So shipping, ownership? Yes, lift. So ship and lift. And I will add, there are so many things, right? But I will add one thing.

humor. Taking yourself lightly is really important. I mean, it's evidently not limited to Solid Engineer, but I think... humility and being able to self-deprecate. I like how you put it because I feel if you have self-deprecation humor a little bit, it's hard to have a big ego.

Because I feel that's the thing that gets in the way of some engineers who are really standout and really smart, but they become insufferable if they keep putting their ego ahead of them. And it goes against everything. They're not going to lift others if they're... if they don't have that learning mindset so yeah yeah and also like sometimes you have those debates right like so you have those debates on rfcs uh on code etc and and you see some tension and some conflicts

you more diffuse these things, right? So it's a really powerful move. Yeah, there are so many other things like structure and method. I think a good solid engineer has like a method in place for fixing problems. It starts with observability metrics, right? A good story here would be we are in an incident. You're debugging. Everybody thinks like the problem is in system A.

And then you have like a really creative engineer who says, actually, it's here. And we are all looking in the wrong direction. And here's a super quick way to mitigate this problem. This is like...

also solid engineering. It goes back to the shipping thing. You can only do that if you keep close to the code. Now, in this... repository you have a lot of a lot of really good articles and i know i love how it starts that i would like this repository to not be over overloaded so i will limit to the most

important and impactful documents. And again, about 10 years ago when you sent it to me, it was a lot smaller, but now it is becoming a little bit overbearing. Just there's so much reading right there. Again, I really appreciate that every one of them is worth reading. What is your take on the importance of reading versus doing? Because, you know, if you read all that article, like I'm sure it'll help you to some extent, but let's be real. If reading can make you a great engineer.

then anyone could just read the whole thing. How do you think about balancing this thing? Reading, doing? Yeah, absolutely. So evidently this repository is not designed for being read like head to cover, right? Like cover to cover. you are confronted with a topic. And what happens is usually during the day, you're in doing mode, right? So you need to get to results.

I think people will start looking at you sideways if you start taking a book and reading a book on the job. People usually don't really see that super well. So what you do is during the day, right, like you try to make it work and you're going to try many, many things. You might choose AI to unblock yourself, right? And then what you can do outside of work time is read a book about the fundamentals of the topic you're confronted with.

Because when you're trying to make things work, sometimes what you're missing is like the fundamental of this topic. And if you add them, it would unblock you and considerably speed up your process. So that's why reading and doing, they go hand in hand, right? And you have to do both. Yeah, so you're saying a good way is to read related to the problem that your head is in anyway, right? Yes, absolutely.

Yeah, reading outside of work, I mean, I know people might be concerned about saying something like this, but I would say, hey, we usually spend a lot of time on our screens. So... Rather than spending mindlessly 30 minutes on a social network, why not reading for 30 minutes? And by the way, you don't have to always read technical books, right? There are some really good non-technical books that are also useful. One of the best ones I've read is Complication by surgeon Atul Gawande.

It's an amazing book about how do you learn from mistakes and how to have a scientific process when it comes to learning from those errors. And there are so many other books like that. Another good example is like all of the... case incident post-mortem aviation incident post-mortem you learn a lot of things about the human component

of like an outage that are very applicable to software incidents. Yeah, especially because in software incident reviews, we try to keep them blameless. So we keep the human part absolutely out of it, which I guess... It's good in some ways, right? There's no finger pointing, but it can miss the very human nature of like, I mean, we're people, we make mistakes. It happens and it's kind of to be expected as well. Yeah.

Blameless is very important and the intent is right, but sometimes it's not well executed and when you... when you completely remove the human component, I think you're missing 80% of the incident potential mitigation. Yeah, like there was this incident where I remember it was...

It was a small outage at the middle of the night at 2 a.m. The engineer woke up and turned it into big outage because, I mean, you know, like they were just tired. It was frigging 2 a.m. They thought they were doing the right thing. But because it was a blame as postmortem, we kept going about how the system could have prevented this. And I'm like, I'm sorry if you're like, what could have prevented this is like.

not having to make a decision or that NGO are not deciding to try to mitigate it on the spot. I mean, there are some things, but there was that context of like, look, when you're waking up in the middle of the night, Either it could have been okay to ask for help or it could have been fine just to leave it and kind of come back into the morning. But again, because...

This was one downside that I saw. And it doesn't always happen like this, but in this case, that very important thing was missing. As a tired person, you're going to make mistakes. Being too blameless or at least not involving the human component removes the opportunity for finding training needs, right? And as an industry, compared to all of the other industry, we do so little training.

so for instance i was talking about like the feature flag if somebody's never been trained on why it's a good idea to use feature flag how to use them what are the internal tools that you can use what are some case studies Sure, they will not use it. And it's a huge missed opportunity. So if you don't cover those aspects in a post-mortem, you're missing those training opportunities. And yeah, we need to also be completely okay saying, yeah, mistakes happen.

And it's a way of life. And as my mom used to say, those who don't do anything don't break anything. Yeah. Speaking about training, I had this really interesting experience with you. I'll see if you remember. Back when I started at Uber, we were in hyper growth mode and we had a lot of projects going on and engineers needed to lead projects. We just didn't have the product managers, didn't have the capacity to lead them.

And so you decided like, okay, well, since everyone's leading projects, we might as well get people some training on what does good project management look like because we're all software engineers. We're not the experts on this. You looked and you found an expert on this. You brought that person in for a two-day training. And at lunch break, all hell broke loose. Engineers were like, what the hell is this? Like, this guy is talking about some old-school thing that doesn't work.

the rule was so big we cancelled the the training and i still think of this of like what went wrong or like could have we even done training or were we just doing things that was just not trainable or would have we needed to do our internal training do you remember this absolutely it's funny i absolutely remember this uh it was a very humbling experience because i did choose

the training company. The main learning for me is you have to build your own training. Only you know what your team needs and the mistake I made was to have somebody else come in and do a training.

Because you spend a bunch of time selecting who to bring in. Yeah, no, no. I mean, a big mistake for sure. Since then, very simple. I just be on my own trainings. I know exactly what the team needs. And the other thing is I keep... on improving it the true thing is like project management is not rocket science right like no we could go into details but it's essentially managing the trade-off between time cost and quality

And once you've said that, now you need to apply it to your team, give case studies, have people engage, and only you can build those trainings, right? And then that's what we actually did afterwards. I mean, I don't think it was intentional, but I started doing this. I started to put the document together for...

my team saying okay here's here's how we usually do it here's examples here's like pointers to internal sites here's how we try to keep it as lightweight as possible because i think that's the thing with with a lot of these things i wonder if this is why training is possible you

As an engineer, you want to make the process as simple as possible. You need to have some, you know, like, I don't know, checkpoints. Sometimes they're optional. But in the case of project management, for example, I think the only thing we had is, okay, you know, kind of, it's...

Do some planning up front. Decide how you want to do it. It's up to you. Do you want to do a big meeting? Do you want to do whiteboarding? Doesn't matter. Put together a plan. Make that a document. Send that out for comments. That was like kind of a fixed thing.

And then I think the only thing we mandated is have a kickoff meeting because we realized that when we don't have a kickoff meeting, the projects don't go that well. And then I think the third thing we said is like every week, send a weekly summary to your team, everyone on your team and a few stakeholders.

And then there was a bunch of recommendations in between. You could do this, you could do that. But these were the three things. And we did it because we, over time, we figured that this works for us. It might not work. Another team might have added additional things. Again, I know some teams, they mandate, let's say, retrospectives and all of those things. But in the end, every team kind of came up with their own process. Some teams kind of forked it or copied this document.

They added some things, they removed some things. Yeah, you have a ton of good content on your blog about like project management. Maybe one thing that most people don't realize is this weekly update thing, which is something I learned at my first job. an internship in South Africa, and my manager was sending this weekly update to almost the whole company. He does so many things, right? So one, it forces you to be explicit about your goals, your success.

your low lights, what you can improve, right? So that's great. And two, it's a good perception tool, right? It's incredible how just sending a weekly update drives a perception of movement. And it's critical, right? You have to manage the perception of your work. It works for a team. It also works for an individual contributor. You've been tasked to do this or that project. Very simple move.

Send a weekly Slack message. This is what I'm planning to do this week. This is what I did last week. That's it. Pretty much like a stand-up and maybe some key metrics, right? In writing, it works wonders. yeah and i really liked how you suggested that we do we did we for every week we did like the status of you know like is it on track like when are we planning to have the next thing shipped or whatever that was uh highlights

the you know some good things and then we also had low lights we just tried to keep ourselves honest and what i actually found is by adding low lights and by being honest and of course with low lights when there's like something at risk like mitigation what are we doing about it it just kind of forced

conversations early. We didn't really have surprises. When a project was late, we knew it a while ahead. And when we didn't, we then talked with the team or the engineers saying, did you actually know this? And usually it turned out that they kind of knew. They just didn't want to... bother with it. But by having that trust, again, it wasn't about like, you know, you're going to get in trouble for being late. It's like, no, we just like to know. So we can help, we can talk about it, we can...

We can talk about the trade-offs because it's all trade-offs, right? Like with project management, you can always decide when a project is looking at a slate, you could either cut the scope, you could try to pull in more people. You could just extend the timeline. Yeah, I mean, I think that's the three things you can really do. Yeah, absolutely. And the lowlights is an important section. I don't always include it, frankly, but one thing I always make sure to include is ETAs.

A deadline is the ultimate source of inspiration, right? Because if you look at the cost, which is essentially the engineering time, it's always a dynamic thing. How many engineers are working on the project is not always super easy to measure. The quality, which is the scope and what the project is aiming to ship, is also very dynamic. Like you have macro optimization at the feature level that people might not have. The date, super objective.

Right. We said we would ship on that day. We're going to be two days late. And then the discussion about, is it OK? Should we cut scope, increase the number of engineers, which does not always work, right?

But then those dates and making sure they are in your weekly update ultimate source of inspiration when it comes to project management trade-offs. And I feel that getting better at project management... managing your own your own project that you're working on whether it's a one person thing or or a few people it's a superpower as a software engineer because i think as software engineers we think that okay our job is to like write code but actually our job

is to solve problems and to ship solutions to problems that the business has made that be new features or products. And you become more experienced and frankly, you know, higher paid when you can take on more complex things.

There's only so far you can go without project management. So I remember that at Uber, there was some pushback. Some people said, like, I don't really want to do project management. And I was like, well, OK, so I guess two things could happen. Like one is someone else can do it and you'll just.

you know, you're not going to do it. Or like two, we could bring in a dedicated project manager. We could literally hire a person and they will be the project manager. Non-technical. They're going to keep pestering you for updates. You know, you're probably going to hate them. Yeah. But a lot of places still work like this. And some of it has to do with some people are just really resistant. So I don't want to do it. Great. Well, you might actually be worse off.

Yeah, I've never worked at a place where you have like those non-technical project manager. Usually you have this TPM role, but it's most effective, I think, when you have like a project that impacts 20 or 30 teams. Very useful. But then when it comes to like, once again, it's not rocket science. It's like a weekly update, making sure the project is on track, making sure it's still going to be delivering the value that people are expecting. And I would even go as far as saying that...

Project management is one thing, but I would also recommend getting into product management, right? Because the irony of the software engineer's work is there's a lot of blame. a lot of things that can be blamed on the software engineer, right? Like a feature is buggy, hasn't been tested enough, there's an incident, a wrong architectural decision was made. And it's very objective how you measure. There is one thing that is...

relatively difficult to measure and that most companies I think don't do a great job at, which is making sure a product is doing the right thing and was the right strategy in the first place and is shipping the right value. So as a software engineer... If you don't do that, you risk wasting not days, but weeks, maybe months of time working on a feature that is actually not going to move the needle for the customer. Yeah, or even years. I think we see products that even like larger companies.

bring out uh which are just like big flops yeah and they put so much time and effort into this i mean we we could even see it at uber uh projects that were killed i still remember so to this day date we had a team who were doing jump bikes and they were integrating it into the uber app and and they were changing some parts of our of our stack and they came in and they didn't add tests

Like they added a feature or something and they didn't test. And we kind of got into standoff with them because we're like, I mean, you know, like our quality bar, it needs to be tested. In fact, I think they deleted tests even worse. At first, I was like, how can they call themselves software engineers? We're at the same company if they miss these quality things. And for us, it was really important because we knew that we want to have stability, we have the real world impact and so on.

And after a while, when I talk with them, I start to understand that they're coming from a different angle. They were not sure if their team would exist in two months. And actually, it didn't. In like six months, it was kind of sold off or moved to a different entity. But they were just in a different stage. They were in survival. They were like, let's just get it to work. Let's test it.

If it's there, and this is what made me realize, that there's just different levels of software engineering. You know, when you're working on a mature product that's making a bunch of money, which was us. you have different goals than when you're, this was a startup and MVP stage, they weren't sure if it would even work. Yeah, the time cost quality.

management is very different depending on where your product is. So if you don't understand that, you're not going to be making the right decision, in particular when it comes to technical debt, right? Taking on technical debt is a perfectly valid thing to do when you don't know if your team is going to exist next month. It might be much trickier if you're building the architecture for the next few years.

And I would say it's especially the case for internal projects, especially because internal projects, an internal platform usually don't have product manager. So in a way, you are also the product manager. How would you suggest software engineers to learn, to kind of make a balance on tech depth, on how much to focus or how not to focus? Or what is kind of your mental model of deciding like how important is tech depth or not? Because again, I've seen...

Most engineers, I think, that care about the craft can kind of frankly go overboard on this. You're trying to fix it, make it perfect. But honestly, it doesn't matter all that much. But on the other side as well, right? We have this kind of like kind of hacker mentality who just gets things done. Yeah, it's a mess. It's spaghetti code. It's hard to maintain after. Yeah, I would say two things. One, it's tech depth if you know it's tech depth.

If you don't know it's tech debt, it's just recklessness, right? It's moving fast and not knowing what you're doing. I think we call it vibe coding those days, right? That's not tech debt. It's just recklessness. So you have to know, you have to care a lot about your craft to know.

where you're taking a shortcut. And two, I would say, condone the technical depth, right? Like hide it behind a clean interface, use good patterns to make sure that then you can revisit that technical depth with minimal changes and keep track of it, evidently.

One thing you've done a lot is hiring. You've hired so many people over time. Right now, the job market is kind of bouncing back a little bit, but it's still pretty tough out there as software engineers, as engineering managers to get hired.

What is your advice on a software engineer, let's say experienced software engineers, to get hired? How would you suggest that they prepare? Yeah, so first, you're absolutely right. press and the media is full of articles about lowering like a difficult job market for engineers. You've shared an article yesterday, but it's not what I'm saying. We are hiring, for instance.

I would say don't listen to those news. I mean, there are so many advices on the internet about preparation and things like that. It's difficult to say original things about it, but I would say... Definitely to have a structure and a method. You come in, most of the interviews you will have are technical interviews, hands-on. If you have a good method, if you have a good structure...

The interviewer, even if you don't succeed necessarily at solving the problem at hand, will see that and will reward you for that, I think. So for instance, for algorithm, it's to start with a brute force solution and then to keep improving and optimizing, right? For a system architecture interview, it's to start with a product.

And then go with like some requirements, technical and non-functional and non-functional and then start with an architecture, et cetera, focusing on the trade-offs and things like that. So having a structure method, I would say... Definitely super useful. Then there is a topic of AI. Do we want to talk about AI? We'll get into that. Yeah, but before we get to the interview, when you're hiring on your team,

I guess it starts with either applications coming inside or you also have so-called outbound sourcers who you talk with them and you tell them, here's this type of profiles I'm looking for. What could help you being discovered? I guess this will be your LinkedIn profile. And also for resumes, is there anything that, again, there's been so much advice. I even have a book about resumes, but is there some resumes that like...

you know, you think are better than others. The main thing people will look for is what are the experiences, right? Your experiences, which obviously is not a valid.

advice for people who are just out of college for instance but I would still recommend that they promote like the projects that they've been doing and for instance Well, and also I think this is important because when you're choosing your next job, if you have options, you could think about what will help my resume stronger, all things being equal or similarly equal. I had this early on in my career when I had the opportunity to join Skype. I actually like I.

It was the first job that I didn't take any pay rise. It was the exact same thing, but I would have taken a pay cut to do so because I knew that that was the first company that I actually recognized. And later, once I got there, suddenly... messages started to come in because i i was now at a company at the time it was it was well known you know nowadays it's discontinued but still yeah you picked the right uh first experiences you're absolutely right like you you came up

on our radar because of the experiences that you had. So I would say go toward companies that are known for the quality of their engineering because that's going to be the main feature. As far as like resume and LinkedIn, I mean, don't overthink it. Most people don't spend too much time on it. Don't use AI. I would say don't use AI to generate your resume. I've spent the last few days reviewing 30 resumes, 25. out of those 30 where AI generated.

Some even add in the skills, attended stand-ups. And there were a lot. So now I can tell like an AI-generated resume, it has a lot of like those relative number improvements. So there's going to be reduced deploy time by 30%. And no absolute number, which reduced by 30%. I mean, if you reduced it from two days, it's, yeah, sure. It's not very impressive, 30%, right?

So don't use AI. Keep it simple. Keep it short. Keep it creative as well, right? Like sourcers and hiring managers and recruiters, they review hundreds of resumes per day. So if you want to stand up, be original, be creative, don't use AI. Yeah. And I think maybe like as you're looking, it could be worth looking at other people's LinkedIn profiles and just making notes of things that you think are kind of like cool, original and like.

You can use some of that as inspiration. And this goes back to choosing the right company to work for, which is what are the technical problems that are going to really move your career forward? So that's why also it's a good idea to prepare questions for your interviewer. And one of those questions should be, what are the technical challenges that I'm going to be exposed to?

Because then it's going to give you a good direction for your career and you're going to be able to check whether this company makes sense or not. And then once you're on the interview and you're talking with, I mean, the technical interviews, I think that's pretty straightforward. You just need to be good at it.

talking with the hiring manager, someone like yourself, you know, like who are people who do pretty well on the interviews? I'm assuming don't ramble, for example. Yeah, I would say don't ramble and also short answers, right? The dynamic of the interview, it's the same here, is like somebody's asking questions and driving the conversation. It is what it is. So if you...

If you use all the time, the interviewer is not going to be able to ask that question. For the hiring manager, I mean, it depends if it's a cell call or if it's an behavioral interview. But by cell call, I mean, there's calls where... you're not sure if this person is interested, but you would like to convince them to apply typically for more high-profile people, oftentimes industrial, maybe people who are at a company that...

is known to have really good benefits for example someone working at meta right now it's kind of hard to sell them because the stock is just going upwards so their compensation might might have gone up right so that's a sell call exactly um and and then You can prepare by asking smart questions, right? So you research a company and you have a good list of questions to ask. I think the best candidate prepares the interview, even those conversations with the hiring manager.

And what this says about the candidate as an interviewer, it says that if this candidate prepared the interview really well, that means that they're probably going to also prepare their work really well when they are at the company.

It's kind of surprising that we even have to talk about these things. But I talked with a recruiter at a publicly traded tech company. There's a few thousand people there. They're a well-known company. I just don't want to say the name because I don't want to put them on the spot. But this recruiter said that they were recruiting for director and VP.

And the people who are coming in did not know the company's products. Like this company makes a bunch of different products. And she said that like 90% of people just didn't. didn't do the basic research of like, and we were not talking about software engineers. So I think I'm going to just plus one that when you get to an interview, first of all, it will be a red flag when you have been ignorant. And you actually...

interesting enough you will stand out by by putting in a little bit more than the basic preparation which by the way could just be interesting to learn about a different business what they do think about what their business model could be this goes back to You can actually use this later when you're in an elite position. Maybe one day you'll become a founder. All useful information. Yeah, and you have to manage your career, right? So if you...

don't know anything about the company you're interviewing for, you cannot know whether this company will actually empower your career or not. So this preparation is also in your interest.

Well, yeah, and also preparation is in your interest to see how the company is doing, for example, financially and business-wise. It would be nice to know if there's a likelihood of the company doing cuts in the next six to 12 months, which might be hard to tell from the outside, but if you do zero, preparation... on the podcast. I had Jambi Klarna, who's at OpenAI, a software engineer. She interviewed 46 different companies and she researched all of them and then she made this list of like...

based on, she actually researched their products. She tried to use it. She looked for Reddit reviews for all of these to decide finally where she would go because she wanted to go to a company where it has a good trajectory. you know, her stock could be worth something, et cetera. And I realized, well, yeah, I think more people should do that. Yeah, if you're that careful about your career choices, I think that...

Say something also about like your qualities as a software engineer. We were talking about like a previous colleague of us, right? Like who has the same structured mindset when it comes to picking their next startup, right? And that applies to everything. You have the same structure and method for picking your next career opportunity and also to pick your next technology to use in this or that architecture.

so with ai how is ai from your perspective creeping into the hiring process it's everywhere right you already told me that

You can already see the resumes that have been written or prompted by AI. But what else are you seeing? Yeah, we see it a lot in interviews as well. So for instance, we explicitly asked not to use AI. It's actually quite interesting. I think we'll go back probably to on-site interviews in the industry a lot more than we used to. It seems unavoidable. And by the way, this is not to say that AI is not a good tool when you're...

on the job. It's just a really bad tool when you're interviewing somebody and you're trying to get signal because you don't know if you're only testing their prompting. which is a very important skill, but it's not the only skill. So that's one. So I would say use AI as a coach, as a trainer, but certainly not as a cheating partner.

As a trainer, it's a really powerful move, right? Like you can, for instance, you can prepare those questions about the company and ask whether those questions make sense. And you can also prepare an architecture interview. There is so much you can do to prepare and train yourself. but I would not use it during an interview. So you've worked at a couple of fast-paced startups, Uber. You later worked at other startups. You're now at Cloud Kitchens. What have you seen people do?

to be successful at these startups i've seen when i hired people at uber a lot of them hit the ground running but some of them struggled because it was just a big pace change and these are all fast-paced startups and you know hyper hyper growth is probably over but fast-paced startups are here to stay in fact what i'm seeing with

startups of today, they're even faster. They ship faster. They get to product market fit faster. What have you seen engineers do who do well in this environment? I would say first, like...

Personal productivity helps a lot. So investing in this early in your career so that then you can hit the ground running really rapidly and you stay structured and methodical when you're on board on a new company. Sorry, but by saying investing in personal productivity, so figuring... out how what works for you like what kind of methods may that be to-do lists or pomodoro or or focus time or whatever exactly yeah yeah so how do you keep track of your commitments

How do you keep track of your reading? What worked for you or what have you kind of, what phases have you gone through in this sense? I mostly use a method called getting things done, which is... Not rocket science, fairly simple. And then I've used the same tool, which is called SYNC for the past 15 years. I think a plane to do...

file. And then I also use a GitHub repository for my personal notes. That's called PKM, personal knowledge management. That helps a lot as well. And I try to memorize stuff as well. with flashcards and key. Those are things that I've used consistently, and it pays dividends still to this day. For flashcards, what kind of things do you memorize?

So for instance, I memorized the whole Python standard library. Not everything, but a lot of it. And it did help a lot in the beginning. And then you memorized architecture patterns. Data science methodologies. Yeah. Love it. Standard library of your current language or like some issues you have, bash commands that you use.

consistently. Yeah, so I would say personal productivity does help reading fast and being able to synthesize and summarize like document. I guess the best way to do it is to practice, right? So like read. Read, exactly. Definitely prioritizing meeting with people and understanding their context.

Because there is only so much you can find in the internal documents and in the code, right? So understanding the history of the technical decision, it helps a lot when it comes to maintaining that platform later on.

So I'm not sure if you recommended this or not, but at Uber, one thing I started to do after a while is meet, when I became an engineering manager, meet... other engineering managers on the team or when i went to for example san francisco we were based in amsterdam meet spend that time to meet with them in person and then starting with like i edited a short summary of short presentation of our team just a few slides to say here's what we do it was meant to be really short

but it was just a conversation starter. And then I asked, like, hey, what do you do? How did you get into Uber? What are your plans after? And then as we warmed up, what are your plans after Uber? Like, where do you actually want to go? And those things have become really useful.

I realized, like, as an engineer, I probably should have done more. And I saw some of the best engineers. They actually just met in person with another tech lead or another engineer on the team or grabbed lunch with them. And it makes all the difference. Yeah, I think AB talked a lot about it. She might have been the instigator. It makes a lot of sense, right? Like you're going to work with people. You're not going to only interact with God.

So getting to know them on a personal level is critical if you want to work well with them. And they'll just be nicer to you. And it's nicer. Yeah. And you'll be nicer to them. Yeah. So that's why coming back to this like humor and self-deprecation.

You want to work with colleagues who are really good at what they do. That's for sure. But you also want to have fun, right? Working with them. Like it shouldn't be like a... an annoying thing or frustrating thing so the best way to do that is to get to learn because I'm convinced that everybody has like an interesting story and and stuff you can learn from them so yeah and i guess one one thing like in a fast girl company like conflicts are a bit more common

Just because people try to get things done, there's a lot of email or Slack messages. And sometimes, you know, they can come across as aggressive or passive aggressive. And I still remember to this date where... This was, again, back at Uber. We were emailing a lot back and forth with the San Francisco platform team. And there was this guy who was just an absolute asshole at times, just like in the response. And then once he was in Amsterdam and he was such a nice guy.

But once we got to know him, you know, and someone asked, like, why do you write this? Like, oh, I just write really fast. Like, it was really late at night. Turns out he was writing at 3 a.m. and he wasn't caring too much. And like... Every now and then I get back to the point of like, well, I guess software is oftentimes more about people or at some point people start to become really important, especially inside a company.

Yeah, that's why my number one advice when a code review is not going well or like an RFC review is getting into terms of comments, just meet, right? Like meet face to face. You're going to hash this through in less times and it's going to take you to have all those.

exchanges and frustration and you're everybody's second reading the thing i mean let's be honest also a lot of people in startups are like english as a second language so we don't necessarily understand all of the nuances of the language contrary to code, right? And also some people cannot express their own nuances or they have a hard time, especially in writing. Yeah, absolutely. What are some non-obvious recommendations to thrive inside a high-growth startup?

Yeah, non-obvious. So I talked about memorization. Yeah, using flashcards to memorize stuff, very powerful. And second, I'm not sure if it's super non-obvious, but extreme ownership.

So that means you feel like the team is yours, the project is fully yours, and really going out of your way to understand all of the dependencies and overall context it fits in. It's really critical to be super successful. I talked about like the best engineers don't stop at team boundaries. They will keep going. Our industry, our work is mostly about...

building abstractions on top of abstractions on top of other abstractions. In reality, there's always leaky abstraction details, implementation details, right? So the more you understand about the stack you rest upon, I think the more...

effective you're going to be as an engineer. It also applies to your tools. It applies to your programming language. It applies to everything. Yeah. And then one thing you used to say a lot is under promise and over deliver, which I guess is easier said than done. Yeah, this is where also the weekly update helps. It's like you set your timeline and if you find a creative way to reach a timeline faster, it's a pretty powerful move. When it comes at working at high scale...

fast-paced startups, a lot of people have imposter syndrome. Did you have this? And did you see people have it? And how did you work around it? How did people conquer this that you work with?

Yeah, you always have this. I think to this day, it's a good thing to have it, actually. We often talk about the imposter syndrome as a bad thing, but I think actually it's the engine that drives your curiosity and is like... What's going to move you toward essentially like improving yourself and having this continuous improvement mindset. What's really interesting also in the world of like startup mindset and culture and things like that is when you look at it.

I've been really interested in ancient philosophy and stoicism. And when you read those ancient philosopher readings, it's still very applicable to us today, right? Which is, don't over-focus on your... emotion but like just get at it right like just just try to work on those aspects so that you become a better engineer i'm just

I want to do just one quote, which is Dan Heller, which we both know. It's a really good way to phrase this thing, I think. Imposter syndrome is underrated. A lot of talk goes into overcoming imposter syndrome. I say embrace.

self-scepticism and doubt yourself every day what else to add right like it's a it's a good drive it's a good engine even tuan um city of uber like acknowledged it and I think it takes a lot of humility to say that you feel like you have imposter syndrome but it's a good thing and I guess You typically have impulsive syndrome when you feel people are smarter around you, where you feel you might not be fully up to speed with.

wherever you are, which is typically at a high growth startup, like it's going to be a rocket ship, right? So I guess it's kind of natural to feel that, right? In fact, if you didn't feel that, like you might ask, are you at the right place? Is this really, truly a high growth startup, which is...

which has ambitions beyond your own ambition. Yeah, you want to be impressed by your interviewers, for instance. That's a good way to know whether you're going to be at the right company next. What are some non-obvious reading recommendations you might have for engineers who want to get better?

Yeah, so I would say read the fundamentals, not necessarily only the most recent technical books, right? So for instance, one of the books that I, non-obvious book, I would say, is like the Linux. programming interface, which goes into what is the API that is exposed to by the kernel. It's fascinating because not only does it explain the kernel and it's super useful because most of our stack is built on top of Linux. Exactly.

So that's one. And two, it also goes into the historical technical decision. There are some really interesting algorithms. as well. Like, why did the kernel choose a red-black tree, for instance, instead of hash maps for certain data structures? So it's really interesting, really fascinating. So fundamentals about your programming language.

adjacent fields so i mentioned uh complications by atul garlande fascinating read and i would say fiction as well read a lot of fiction first because i mean it's not all about like work and also because it trains you to be a better writer reading good fiction It's a great way to improve your English, improve your writing skills as well. And I guess your reading skills. You mentioned how it is helpful to be able to read fast and digest information fast.

i guess is is as i go into the gym and you know working out you're now working your your kind of mind Yeah, I've also been reading a lot more philosophy lately. I mean, evidently software engineering is a very scientific endeavor, but there is a lot to be said also about the fact that we handle concepts. There's a very conceptual work that is very similar to philosophy.

And so, for instance, I listened to your interview with Dr. Osterhout about the philosophy of software design, right? And he mentioned that at the core of software design, you have this decomposition. Well, it's the core of human thought. It's the core of reason, right? Like reason is about distinguishing between different concepts. And I mean, it's not an irony that there is philosophy in the title of this.

episode because it is what it is, right? Like philosophy is exactly that. It's distinguishing between different problems. That's really what classical philosophy is about. Yeah, in fact, when it comes to, for example, designing a new system, you need... you kind of need to go down a path. Like you can argue if it's a philosophy or not, if you're doing microservices or monoliths, but the argument can turn into kind of philosophical against there is no one right or wrong.

And I guess at some point you need to go with one of them. It's fascinating how there are some parallels. Yeah. When you're writing an RFC, you're making a case. So then there is a big component of logic. How sound are your arguments? So for instance, at Cloud Kitchen, in the competencies, we have a big section about truth. And we have one competency, which I like really much, which is called QED.

A quad erat demonstrantum, what needed to be demonstrated. And it focuses on how well do you make your case? Do you eliminate bad arguments? Because when you read an RFC and you have like one good... argument in the middle of like 15 bad ones you feel like yeah i'm wasting my time

As a reader, it helps you uncover that. And as a writer, it helps you realize that so that you focus on these good arguments that you have and you make it really strong. And it really helps your career, I think. It almost feels like if you're a good debater and you're also good at... out your arguments in a logical way, it helps you be a good software engineer because we need this, right? It's a logical field where the best people, like obviously there's a human part, but...

You need to build up your arguments in a way that's understandable, easy to read if it's in a document, which a lot of it is. Yeah, there's two virtues that are really important and I think under-focused. in the startup world is courage, like the strength to go against difficulties and maybe opposition and humility. Because also when you're focused on logic and truth, you can also say, hey, I was wrong.

I mean, sorry, you make a case, somebody comes back with a really strong rejoinder, and you say, well, yeah, you know what? You're right. This is not the right architecture. And it's a great way to grow, right? Yeah, and the best engineers always shared that. No matter how senior or experienced they are, or how fancy they had, they had an open mind. And they would change their, and they would go like, okay, yeah, let's build this idea, or let's go with your idea. Zero humility.

A lot of the advice that comes out of people who worked at Uber at a HyperGo time, or today it'll be at OpenAI, we could argue a little bit, is that survival bias?

Or not? It is. I think it is. It's definitely Survivor bias. You listen to us, for instance, and we're going to talk about all of the things we need to fix some of the chaos. But in a way, you could argue that the chaos is probably why the startup was successful in the first place, right? The speed up that you get when you're focused on shipping.

Definitely has some trade-off in terms of quality and maintainability and reliability. But I would submit that in most cases, it's probably not what you're looking for. You're looking for to first building a product, building a successful business. and the rest comes after. And I think the industry has a tendency to overfocus on what comes after, the quality, the investment in the internal platforms.

Well, actually, yeah, it's fine in the beginning if it's not standardized, if it's not that structured, if what you get in exchange is speed. I think Uber had this thing, which we just got rid of just as I arrived. It was called the ping. Every five seconds or so, the app would send a ping to the server. It would ask me, send me the data, and the server would return.

a blob of information the the waiting times the edas for the different like you know like different categories and a bunch of other things and the app would display that data so this was a pull mechanism And initially, they started off with a few pieces of data, and they did it because the mobile developers were tired of waiting on the backend developers, and they could just add things into this ping package. And it became a...

pretty large package, and it was just causing a lot of data. And in 2015, Uber was still working like this. It was now scaled to millions of people, and it was just really, really inefficient. But then eventually, I mean, it kind of worked. and a refactor came and then uber changed it to be a pull where the so it was pushed so the server was now pushing and it was far more efficient faster shorter delay etc but in the end i was like it worked

There are so many examples like that. We were talking about internal tools and automation in the beginning, right? I think when it comes to automation, a lot of automation projects over-focus on quality and constraints when actually people won't. speed and being in control. There is this fascinating article about malleable software, software that leaves the user in charge. Best example being spreadsheets. So many internal tools start with a good Google spreadsheet.

Because there is so much you can do, right? You don't need to ping an engineer to add a column to your table. You can just modify it. And what's great with spreadsheet is it's... the purest, what you see is what you get, right? Like it's everything in front of you. It supports mass change. I would submit that a lot of startups have an incomplete buggy implementation of Google Spreadsheets somewhere in their tools.

because it's so effective. One interesting story from UberTime, the user's table and the trip's table had two interesting columns. One was called user and trip tags. So user tags, trip tag. Another one, which was a free form list of tags. And another one was user attributes and trip attributes, which was a key value. Stored as a JSON in this column. It was insane when you think about it, right?

And it was massively overused. A lot of teams did not want to add columns to the trips and users table. So what they did instead is just stick stuff in those columns. And then it started exploding, I think, roughly after I left.

Which is fair, but so many products were bootstrapped thanks to that. It's absolutely amazing, I think. So that's why those really... shitty internal tools approach, they do work because you get speed out of it and you might validate very quickly that actually you don't need this feature or product in the first place and you're going to save a ton of engineering time, which is usually...

the limiting factor. So is it fair to say that what you're saying is if you're at a fast growth place, instead of reading what other fast growth companies did, their blogs, their best practices, maybe you're better off just looking at your... most pressing problems, solve that and then do the next thing.

Or like also, or as with anything, there's a balance here or just be more like be skeptical whether, you know, the company like Uber or now we're going to hear about OpenAI or all these like very successful companies when they say why they were successful. Maybe that's not the full story.

Yeah, I would say because usually the limiting factor is the engineering time, I would say optimize for leaving the user in control so that they can change things on their own without having to involve engineers too much. Put the guardrails in place so that it does not catastrophically break your system, but leave the user in control.

because you will get so much better product adoption. By user, I mean like usually internal operations team, internal business team, your product manager, right? Like lean on this direction. rather than having a super constrained product that takes a lot more time to ship and that might not even solve the problem perfectly because you are missing this or that ops contact, particularly the case when you build a product for the physical world.

So one of the big changes we're having, obviously, is AI. AI coding tools, AI use everywhere.

What do you see? How is AI already changing software engineering, especially for the work that you're doing at Cloud Kitchens? And what are your thoughts on how it could change as it just becomes better? Yeah, I mean, so much has been written. Every week there's a new article, new analysis, new prediction. We did our own study. We found it was moderately useful. It is useful. So the thing I can add is...

For myself, I think it's particularly useful when you have a well-defined problem that you're trying to solve, navigating the code as a coach and as a trainer. As a manager, I use it a lot to review my document. As a matter of principle, I never copy-paste text prose that was written by an AI. I want to make sure I stay in control of what I write.

Yeah, writing is thinking, right? Like it's the same process. So I don't want to outsource my thinking to an AI. Like I would be really, really sad if that was the case. And when you're saying with engineering, you found moderately positive impact, is this to do with kind of using autocomplete, using it to generate some parts of the code? Did you go further in terms of like, let's say, code reviews or trying to automate some?

Yeah, so we use it for all of those use cases. I mean, obviously, I don't write as much code as I would like to and as I used to. Well, but now you could. Actually, it's a great point. I did a lot more coding lately because it... With agent in particular, it enables you to multitask. You have 10 minutes before a meeting, you issue a specific prompt, you have your meeting, you come back and then you review the code. Yeah, I would say...

Coding-wise, Refactor is really good at that. Refactor, well-specified APIs and interfaces. Anything that is more complex, I feel like it's still failing. I'm sure it's going to get better, but I think the design component will always be a human being thing. The other thing...

Every single time we have one of those revolutions, and AI might be the biggest yet, don't get me wrong, but every time we have those revolutions, the press and everyone speaks about replacing engineers. We're still there. You remember when machine learning really... picked up, people were saying, yeah, so we won't need software engineers anymore. The truth is we actually, it's a data scientist that was really a job role that was under a lot of like challenges.

because of machine learning and ready-made models. But yeah, I don't think we're going to replace. And for example, your team is still hiring, right? Yeah, we're still hiring. I think it's going to enable engineers to do more, to focus on more interesting tasks. We talked about migration. I think migration is potentially a great use case. We hate doing it. And it needs to be done. Yeah.

Yeah, so migration, great use case. So for instance, at Cloud Kitchens, we had a migration, and the teams that was owning the internal platform put together a prompt that you could copy-paste to do the migration and still review the card. Of course, you can review it. that go wrong um what about security or or an increase of of would we have increase of attack surfaces by using ai yes i mean i think that's the most obvious thing as well

Security engineer is going to be a great job role. There's going to be so many things. Lately, the main source of, a big source of vulnerability was like the supply chain attacks, right? When you take control of one of the dependencies of a project. by typo squatting or by just taking control of the repo, for instance. And then this way you can get remote code execution on remote virtually thousands of repositories. Well, agents are that at scale. So it's...

It's going to be an incredible time for security engineers. So far, so good. There haven't been so many problems, but we're going to have so many. It's absolutely obvious. We need to prepare for that. What about engineering management? I mean, you mentioned how you use it to...

to help with some of your documents, but do you think it changes the engineering manager's role? It makes some things easier? Does it make some things harder? Yeah, I use it as a coach. So for instance, where I would have potentially pinged my manager for advice. and maybe more basic stuff. Now I get a first review from an AI. It's hit or miss. Like sometimes it's extremely valid feedback. Sometimes it's totally useless. And it's a good first pass, I think. But I would say never copy paste text.

from AI. I think we're going to lose skills if we do that. Well, one thing I think more people are going to use it. I talk with engineers. One thing, you know, engineers, a few things engineers don't like to do that much. Meetings. migrations, performance reviews. Yes, performance reviews. So if they listen to this, I have reached out to some of my skip level engineers and I told them, hey, don't use AI to generate the feedback for your manager. Don't only use AI at least.

Yeah, he's going to find it funny, but there's even one engineer who took some of my Slack messages and then took our competencies and asked AI to generate. My feedback review. It's unavoidable of happening. But as you say, there is a point of writing as thinking and there is a reason companies try to... force a little time to reflect on your relationship with this person or what you think of yourself, etc.

There's also one thing, which is nobody wants to read AI-generated text. The moment I tell you that this text was generated by AI, you lose interest immediately. So I would much rather, what I tell people who might be tempted to do that is give me the prompt. If you don't have time to write good English and stuff, which by the way is not that important, tell me what you would have asked.

the AI to generate, and that's what I'm going to read because this is where the data... There is this irony, right? It starts with a very small prompt. It's bloated into a massive text by an AI, and then somebody else will use an AI to summarize. the content, why don't we just exchange a prompt directly? We're not going to lose any information that way. I feel it's a very interesting contradiction with...

with AI specifically, with text generation. I wonder if we're going to see more. We might see some other things in software engineering slowly repeat as we learn, right? Because I feel this is... Yeah, you just want the original information, the prompt. Yes. We'll see if software might or might not be the thing, because people don't really care about the software. Users don't care what exactly code runs under the hood, so maybe it'll be different.

Until there is a problem, right? Until there's a problem. That's why... The other thing is, I think you talk a lot about that on your blog as well, the importance of code review. The first time I... used AI to generate code, I did not realize that it would be my code. So I did not really, really proofread it that carefully. And then I put the PR up and I got a lot of feedback and I was like, yeah, I agree with all the feedback. This is really bad.

What I did after that is make sure that you read the code that was generated so that it becomes yours. Because at the end of the day, if something breaks, you're going to have to do this anyway. And that's probably the most interesting aspect, which is... Reading code that you did not write and making it your own is much higher cognitive load than writing it in the first place.

And as a consequence, that's why we're still going to need engineers. Because at the end of the day, the moral agent, the person making the decision and putting their stamp is still a human being. I wonder if... An interesting second-order effect of AI. It's very good at generating a lot of text from a prompt. It can generate pages of text. It's also very good at generating a lot of code based on a prompt. You give it a prompt, it generates the code.

As a result, it's pretty obvious we're going to see a lot more code generated. If you think about, you know, the professional engineering teams that you worked on at Uber, at Cloud Kitchens, at the other startups, we spend a lot of time as an engineer to not... write verbose code, right? Like on code reviews, we'll push it down. We don't want to...

We don't want to copy, for example, functionality that exists elsewhere. We would rather use the abstractions. What do you think the impact might be if we just continue the thought experience that we will have a lot more code generated, a lot more worthy code than need be? Where will this lead?

I think those startups might fail because... Or slow down, right? Yeah, because if they're only doing vibe coding with very little code review, it's going to become unmaintainable, even for an AI. So I would say you have to stay in control. You have to have strong code review practices in place.

Yeah, one thing I often see when I ask AI to generate, it's trained on Stack Overflow content. It's trained on not necessarily the highest, best quality code. It's whatever's on GitHub or whatever's open source. I mean, some open source is high quality. High quality, yeah.

But a lot of stuff that's open there and can be used for training is not. Yeah. So for instance, you will see that it's reinventing a feature that you know already exists in the standard library or in this or that library. Very often a failure mode, I think. So I think this is one of the, yeah, one of the risks is you end up with so much code that you actually default on the code, like being so overwhelming that when something bad happens,

You cannot debug it yourself. You have to invoke other APIs that will fail. Yeah, we might relearn some lessons that we've already learned as an industry a few decades ago. Yes. And as closing, what is a programming language that you like most? And which one would you like to learn?

Yeah, difficult question because I love programming languages. I love this quote from John Stubut. creator of C++, right? There's only two types of programming languages, those we complain about, and those nobody uses. So in the first section, I would say Python. Why? I mean... It's so effective a language. So versatile.

A really great, by the way, interview choice. If you have a coding interview, it's a really smart move because it's so effective, right? You can get so much done. It's a professional language nowadays. Might I remind people that most of Uber was built on top of... of Python in the beginning. So it's a really, really powerful language.

TypeScript is pretty good also in that destination. I usually prefer dynamic languages because they leave me much more in control. I love statically typed languages as well. And then learn. I learned Clojure. So that's the second category. I never got the opportunity to use it that much. I think it's a beautiful language. Lisp dialects are really cool.

Love functional programming, but sadly I haven't had the opportunity. Rust is pretty good too. I learned it as well in that section. Great, Charles. This was a really fun conversation. I'm glad we had it. Yeah, same. It was a long time overdue. I hope you enjoyed this candid conversation with Charles. One of the things I like most about him is how he keeps trying out new stuff and is an absolute productivity geek. I hope this came across the conversation as well.

For more tips on how to lead projects as a software engineer, check out the Deep Dives into Pragmatic Engineer that I wrote in the past, where plenty of lessons come from working with Charles. They're linked in the show notes below. If you've enjoyed this podcast, please do subscribe in our favorite podcast platform and on YouTube. A special thank you if you also leave a rating for the show. Thanks and see you in the next one.