The Pragmatic Engineer - Hypergrowth startups: Uber and CloudKitchens with Charles-Axel Dein

Episode Date: September 24, 2025

Brought to You By:•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Statsig built a complete set of data tools that allow engineering teams to measure the impact of their work. This toolkit is SO valuable to so many teams, that OpenAI - who was a huge user of Statsig - decided to acquire the company, the news announced last week. Talk about validation! Check out Statsig.•⁠ Linear – The system for modern product development. Here’s an interesting story: OpenAI switched to Linear as a way to establish a shared vocabulary between teams. Every project now follows the same lifecycle, uses the same labels, and moves through the same states. Try Linear for yourself.—What does it take to do well at a hyper-growth company? In this episode of The Pragmatic Engineer, I sit down with Charles-Axel Dein, one of the first engineers at Uber, who later hired me there. Since then, he’s gone on to work at CloudKitchens. He’s also been maintaining the popular Professional programming reading list GitHub repo for 15 years, where he collects articles that made him a better programmer. In our conversation, we dig into what it’s really like to work inside companies that grow rapidly in scale and headcount. Charles shares what he’s learned about personal productivity, project management, incidents, interviewing, plus how to build flexible skills that hold up in fast-moving environments. Jump to interesting parts:• 10:41 – the reality of working inside a hyperscale company• 41:10 – the traits of high-performing engineers• 1:03:31 – Charles’ advice for getting hired in today’s job marketWe also discuss:• How to spot the signs of hypergrowth (and when it’s slowing down)• What sets high-performing engineers apart beyond shipping• Charles’s personal productivity tips, favorite reads, and how he uses reading to uplevel his skills• Strategic tips for building your resume and interviewing • How imposter syndrome is normal, and how leaning into it helps you grow• And much more!If you’re at a fast-growing company, considering joining one, or looking to land your next role, you won’t want to miss this practical advice on hiring, interviewing, productivity, leadership, and career growth.—Timestamps(00:00) Intro(04:04) Early days at Uber as engineer #20(08:12) CloudKitchens’ similarities with Uber(10:41) The reality of working at a hyperscale company(19:05) Tenancies and how Uber deployed new features(22:14) How CloudKitchens handles incidents(26:57) Hiring during fast-growth(34:09) Avoiding burnout(38:55) The popular Professional programming reading list repo(41:10) The traits of high-performing engineers (53:22) Project management tactics(1:03:31) How to get hired as a software engineer(1:12:26) How AI is changing hiring(1:19:26) Unexpected ways to thrive in fast-paced environments(1:20:45) Dealing with imposter syndrome (1:22:48) Book recommendations (1:27:26) The problem with survival bias (1:32:44) AI’s impact on software development (1:42:28) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:•⁠ Software engineers leading projects•⁠ The Platform and Program split at Uber•⁠ Inside Uber’s move to the Cloud•⁠ How Uber built its observability platform•⁠ From Software Engineer to AI Engineer – with Janvi Kalra—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

At Uber, when did you join 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 Kitchen? 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 those 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 Axeldeen was engineer number 20 at Uber and saw first hand as a company grew from 20 engineers to more than 2000 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 ingredient leaks for 15 years. In this episode, we'll 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' personal productivity tips, including why he uses flashcards to memorize things

like architecture patterns and data science methodologies. How Charles thinks AI will change software engineering and why Migrations is the best use case cloud catches has found so far for AI coding tools. If you're working at a fast-based startup or plan on working at one and are looking for tactical advice on how to do well in such an environment, this episode is for you. This podcast episode is presented by Statsig, 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, Gerge. I'm very happy to be here. It is so nice to be back. And this is not 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 ask you to do iOS because this is where we needed, and you said, yeah, let's do it. It was Android.

It was a very interesting interview situation. I was doing iOS development back then. I did Windows phone before, and 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 in a backend track. And I did back in 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 us 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 a Python book, you know, 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 was? 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 time, 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, good hectic, right? Like you're growing 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. Sorry, it was, yeah, Android. It was pretty, 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 to engineer management, right? Yes, that's right. One year later, Twan Fam, was the CTO at the time, asked me to step in. And the best career decision ever was really a rewarding experience. And since then, since then, I've moved back and forth between software engineer and engineering manager.

And I really appreciate doing both. Like, I think I believe in really hands-on engineering managers, yeah. And so by being that early, you must have worked with Travis Kalnick, the co-founder of Uber, right? Yes. I actually still have some pretty good emails where we broke features. what was interesting at Uber is that we build a product that helped 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 were not paid on time and I remember 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 like the responsibilities that you have as a software engineer when you own things in production. Like 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, with some places that's what it is, but it was like how many people's rights 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. Yeah,

yeah. So right now I'm working at Cloud Kitchens, which is another startup that works in the physical world, right? And today we speak a lot about like AI startups and it's evident. 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? Like, 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 like startups and virtual products and social networks and their impact on people's lives that is not always positive.

Like we talk a lot about addiction, for instance. And software that is used primarily to optimize processes in the physical world, you can. says 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 hypergrowth is rarely there. Uber was an exception, and Cloud Citchens might be another exception. So at Cloud Citchens, 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 higher, 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. Like, it's really interesting to see that there's a bit more humility, there's less money floating around, which leads to probably better decision. 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 managed 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 hypergoat phrases at Airbnb, Coinbase, and Uber. As you'd expect, with real scale, these companies started to slow down. What used to take days started taking weeks, then sometimes even months. Not because people work 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 used 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 founders build a tool they wish they had during those chaotic hypergrowth scaling phases.

You can try it yourself at linear.com slash 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. You know, like they raise 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. Well, 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 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, it's like, head count, 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 like, like, like, black like 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 sonder 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. like 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. And 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 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 it led to, like, we were focusing a lot. Because we're due so much onboarding, obviously, we did so much hiring. So we had to optimize around that to like batch the days that engineers could could be hiring. we had this thing where if there was a crunch time for a project, 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 how, like what hyperscale actually meant in terms of 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 like 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 it most startup. You remember it, right? Like, it's, 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'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 of the things.

I would say, yeah, incidents definitely. Oncon. Onco was terrible. So you have those incidents at the same time. You also need to build new features and build new product and also deliver, right? Well, I remember that we had a lot of enthusiasm through the door. So I still think back how we could manage with so much. Like our on call was terrible.

Like we were waking 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 of 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 extreme 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 platform? How do we rewrite? Oh, and there are so much migrations. Yeah, to probably be too many.

Yeah, after 1,000 engineers or 1,000 employees, you don't need a customer, right? Like, you're going to have a team that are going to create migration request for other teams, and the company can operate in a closed circle, right? Like you can create a world. 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 learned. Oh, ready's breaks after that.

and post-grace break after that and or we have this cue here that is not dimensioned correctly or we have this instance or at the time auto-scaling wasn't really a thing. So really interesting, a good way to learn essentially

about your system's efficiency. Still to that day, right? That's a great way. I'm not sure if it had to do with hyper-scaling 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 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

and 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, a heart to still down.

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

that if we would have stopped the fixed assistance, 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 prioritize building new stuff. And sometimes you have also like regulatory context, and other things. Like, there are certain projects that that you must do,

and it's not really up to you to make that call. But yeah, coming back to the incidents and the fact that you had to announce, like, 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 and monitoring it with the 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 to much. 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 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, you know, it can be upset customers or money lost or churn or, you know, like real world impact? Yeah, and actually when I left to where, there was no tenancies, yes. Yet, we were using a dev server. I don't know if you remember that

time, where every engineer would have their own development environment where you would install the whole stack on one machine. Evidently, the machine was oversized for what we were doing. 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 and to win. 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 tendencies. 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 would detect a problem, the better because it speeds up the process, right? Like 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, we should have had a system flag it. And, you know, if we missed it, that would have been on us. But, and 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 this. I mean, it was kind of a good thing. But this stuck with me of like, 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. And 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 is, it 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 grow so fast, you keep hiring people, but you're hiring people a lot slower than 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, sometime 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 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 startup 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 automation, 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 said 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 own payments so everything in the Uber app there 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 pay TM and a bunch of others and we would just need every week we would need to make sure that the payment would work so we would go there we would order and Uber and like

see that the payment went through and we would actually do this manually back on what's something mocked up but every time we will go through it. And when we did it long enough, we're like, and we needed to do it manual 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 that 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, the 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 flow from the banks that you don't control.

So if those tests are constantly failing, then you get flaky test, and flaky test gets in your ignored. One interesting challenge during the hyperskilling time was hiring. And again, most companies will not be in hyperscale more, 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 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 funeral, 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 Uber, we do it at Cloud Citchens 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 the two. Yeah, I remember the, the two things that we didn't, I don't think many people places still do it. It's like first, we had a weekly catch up with the recruiter. So engineer managers and recruiters, we would do it. It's a bit like a team retrospective. And, you know, they would talk about things like, what are their sourcing strategies? Like, oh, what kind of cohorts are they targeting?

On LinkedIn has this new feature that I can, and they were shared tips that were like, oh, pretty cool. Or like talking about what kind of companies they're thinking of targeting it? And we'd be like, oh, what about this one? I just heard that they're, I don't know, they're, there are 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 recruiter has brought a lot of expertise. So they would ask questions like, okay, like 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 to you with the recruiter. So they asked, like, what is your tech stack? And we said, okay, Python, a little bit of Node.js.

Back then we were reducing Go. So they were like, okay, so we need people with expertise in these languages. We're like, no, 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. One hundred percent.

Like this relationship between the recruiter and the engineering manager is critical. And actually something that came from Twan 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 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. 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 experience. 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 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 interviewer training. Yeah, so we have the same process right now. So you have, you shadow first, the primary interviewer, and then you reverse shadow, meaning you drive the interview and then the other experience interviewer would give you feedback. Yeah, you're absolutely right. Like, 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 hyper-scale, hyper growth, sorry, and how might you know that you're getting out of it? Again, you've gone through this at Uber. At Cloud Citchens, 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 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. Hypergoat teams like Notion, Brexon, Placian 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. Statsig is our presenting partner for this 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 AB 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, the full 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. Open AI was such a heavy user of Statsic 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 Statsic.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 you, their reports also reported. reports also report to you you had something 30 reports and you had to do 30 uh performance uh check in conversations i remember that when you did the last one the the few of us more more experienced in years 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 have 30 reports you were expected to get still get stuff done i think you were still doing some somehow on work and like you could tell that usually you're pretty chipper usually but back then you're 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. So I've 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. So, 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, 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 wind you once a week if you need something more before that. Let me know. And then I think you also went more specific. I like you to make a plan on how are you 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 who are 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 the direction either to be a lead or if they want it 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 leak.

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 would 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 world 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 the 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 these are fully capable people. Like sometimes I think back on how in the industry, sometimes we have the tendency to kind of overbaby the junior engineer is like, oh, this person has no experience. Well, if you think back of like the people who build Facebook into the, you know, trillion-dollar company yesterday, they were 19 and 20, like,

dropped out of college. So all I'm saying is like people have a, especially the people who go through a pretty like high standard hiring process, they actually have a lot of capability to do. And I sometimes need to remind myself of that when I was a manager or a tech lead. Yeah, yeah. Plus the best way to learn is to make mistake. So, you know, if you want to invest in your people, you have to let them make their own. mistake. Uki 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. And is this collection of like really, really good reading resources? How did that start? How are you updating it? I understand that you start 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're 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. Oh, I back to automation.

Yeah. 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 was driven like a lot of engineering practices. And then I started in doing this. So one thing, speaking of personal productivity, right, that you can also invest in as an engineer is

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. But I try to read like a good bunch of like 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 Akern News. It's a good one, isn't it? It's the best. Yeah, it's still amazing. Akern News, I received like an RSS field 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 newsletter. The Bites one for Fontaine Engineer is 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 newsletters about the programming language that I use. So there's Python, Java for CK. Yeah, a lot of the software tech lead

is really good as well. You are an engineer yourself. You manage a lot of a lot of pretty good engineers. Can we talk about a story of a standout software engineer and what made this person stand out? Yeah, there are so many. so many good stories. I'm not sure I want to single out somebody in particular,

but some of the traits of like an architectically typically good software engineer, I would say there's a couple 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-focused 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's 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, for instance, staff engineer to really find creative ways to speed up execution or achieve a 10x improvement in quality. 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 critical, 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 Tim Bondari's, 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 gateway where they see the problem is not here and then they keep going, they go to the back end and they actually make the fix in the back end even though they are 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. 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 in time when a product manager can open a power request

that might be accepted, I think there's no, I feel engineers are necessarily becoming full stack with an expertise in their home stock. Martin Fowler 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 comes from the Valve software unbook.

But I've never seen that in real life. And he 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 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 mono repo at Cloud Kitchen, and that helps, right? Everything is in one spot. So you can ask those kind of question and get this kind of answer. And so what other characteristics?

So shipping, ownership? Yes, lift. So ship and lift. Ship and left. Yes, sorry. And I will add, there are so many things, right? But I will add one thing. Humor.

Taking yourself lightly. It's really important. I mean, evidently not limited to solid engineer, but I think humility and being able to be to self-deprecate itself. 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 a way of some engineers who are really stand out 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? So you have those debates on RFCs, on code, etc. And you see some tension and some conflict. clicks, 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 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 really good articles. And I love how it starts that I would like this repository to not be overloaded. So I will limit to the most important 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. There's so much reading, right? 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 the go end in hand, right? And you have to do both. Yeah. So you're saying a good way as to. read related to the problem area that your head is in any way, right? Yes, absolutely.

And 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? Like there are some really good non-technical books that are also useful. One of the best one I've read is complication by a surgeon atul Gravande. 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, blameness is very important and the intent is right, but sometimes it's not well executed. And when you completely remove the human component, I think you're missing 80% of the incident, potential mitigation.

Yeah, like, like, there's, 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, 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, is like, not. having to make a decision or that engine you're not deciding to try to mitigate it on the spot. And I mean, there are some things, but like there was that context of like, look, like, when

you're waking up in the middle of the night, like, 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 like this was one downside that I saw. And it doesn't always have happened like this. But in this case, that very important thing was missing. As a tired person, you're going to make mistakes. Yeah, and being too blameless, or at least not involving the human component, remove 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 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-martine, 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. So back when I started at Uber,

we were in hyper growth nodes. 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 is 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, like,

talking about some old school thing that doesn't work. The rule was so big we canceled 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? It's funny. I absolutely remember this.

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 like who to bring in. Yeah, 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 not.

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 a document together for my team saying, okay, here's how we usually do it. Here's examples.

Here's like pointers to internal sides. Here's how we try to keep it as lightweight as possible because I think that's the thing with a lot of these things. I wonder if this is why training is possible. 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 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 realize 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 for another team might have added additional things.

Again, I know some teams, and they'd, 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, you know, 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. It 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 the perception of movement. And it's critical, right?

Like, you have to manage the perception of your work. It works for a team. It also works for 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 for wonders. Yeah, and I really liked how you suggested that we do, we did, 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?

Highlights, you know, some good things. And then we also had low light. 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 while ahead.

And when we didn't, we then talked with the team or the engineers saying, did you actually notice? And usually 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 a trouble for being late. It's like, no, we just like to know. So we can help, we can talk about it. We can talk about the trade-offs because it's all trade-offs, right? 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 low-light 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 like 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 okay, should we cut scope, increase the number of engineers, which does not always work, right? Mythical commandments.

But then, yeah, those dates and making sure they are in your weekly update, ultimate source of inspiration when it comes to project management tradeoffs. And I feel that getting better at project management, managing your own project that you're working on, whether it's a one-person thing 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 experience and, frankly, you know, higher paid when you can take on more complex things. And there's only so far you can go without project management.

So I remember that at Uber we, there was some pushback. Some people said, like, I don't really want to do project management. And I was like, well, okay. So I guess two things that 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. And 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 management manager.

Like usually you have this TPM role, but it's most effective, I think, when you have like a project that impact 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 we'd even go as far as saying that project management is one thing, but I would also recommend getting it. 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 architecture 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. 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 future 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, which are just like big flops. And they put so much time and effort into this. I mean, we could even see it at Uber projects that were killed. I still remember to this day, date, we had a team who were doing jump bikes and they were

integrating it into the Uber app and they were changing some parts of our stack. And they came in and they didn't add tests. Like they added a feature

or something and they didn't add a 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 tests. In fact, I think they deleted tests even worse. And at first, I was like, like, how can they call themselves

software? engineers, like, 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 started 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 and 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 a 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 like the architecture for the next few years. And I would say especially the case for internal projects, especially,

because internal projects, you have 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, to to kind of make a balance on tech-dub, on how much to focus or how not to focus, or what is 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 at the other side as well, right? We have this kind of, like, kind of hacker mentality who just gets things done. And, yeah, it's a mess. It's spaghetti code. It's hard to maintain after.

Yeah, we'd say one, two things. it's tech debt if you know it's tech debt 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 it's 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 debt right like hide it

behind a clean interface use good patterns to make sure that then you can revisit that technical debt with minimal changes and keep trying 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, it's kind of bouncing back a little bit, but still pretty stuff 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. Like the press and the media is full of articles about lower 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. So 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. So 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.

And then 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 ends, we'll 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, then go with like the requirements, technical and non-functional and functional and then start with an architecture, etc., focused. think on the tradeoffs and things like that. So I think your structure method, I would say, definitely super useful. Then there is a topic of AI. Do we want to talk about AI in interviewing? We'll get into that.

Yeah. 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 sources who you talk with them and you tell them, here's this hyperprofiles 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 was now at a company at the time it was well known. You know, nowadays it's discontinued, but still. Yeah, you pick the right first experiences. You're absolutely right. Like you came up on our radar because of like the experiences that you had.

So I would say go toward companies that are known for the quality of their engineering because that's what, 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 choose AI. I would say don't choose AI to generate your resume. I've spent the last few days reviewing 30 resume, 25 out of those 30 were AI generated. Some even had 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 improvement. So there's going to be reduced, deployed. 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 choose AI keep it simple, keep it short keep it creative as well right like we like sources and hiring managers and recruiters they review hundreds of resume 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. But when you're 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 question and driving the conversation. It is what it is.

So if you use all the time, like 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 a behavioral interview. And by cell call, I mean, there's calls where you're not sure

of this person interested, but you would like to convince them to apply typically for, more high-profile people, oftentimes industry, 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 have gone up, right?

So that's a sell call. Exactly. 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, the best candidate, like, prepare 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 talk with a recruiter at a publicly traded tech company. There's a few thousand people. 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-level candidates.

and the people who were 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 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 that when you get to an interview,

first of all, it will be a red flag when you have been ignorant. And you're actually interesting enough you will stand out by putting in a little bit more than the basic preparation, which by the way could just be interesting. to learn about 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 the 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 Open AIS software engineer. She interviewed a 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 worked something, et cetera. And I realize, well, yeah, I think more people should do that. Yeah, if you're that careful about your career choices, I think that says 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 interviews, sorry, the resumes that have

been like 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 ask not to use AI. It's actually quite interesting. I think we'll go back probably to onsite's 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 abilities, 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. And 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 out a couple of fast-paced startups, Uber, you later work 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 hire 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-growth is probably over, but fast-paced startups are here to say, 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. And I'm 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 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 work 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 things for the past 15 years. I think a plain to-do file. And then I also use a GitHub repository for my personal notes. That's called PKK, 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 till to this day. For flashcards, what kind of things do you memorize? So for instance I memorize a whole Python standard library and not everything but a lot of it and it did help a lot in the beginning

and then you memorize like architecture patterns data science methodologies Yeah. Love it. A 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 call, 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 injury manager, meet other injury managers on the team or when I went to, for example, San Francisco, we were based in Amsterdam, 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, what do you do? How did you get into Uber? What are your plans after? And then as we warmed up, all are your plans after Uber? Like, where do you actually want to go? And those things have become really useful.

And 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 grab lunch with them. and it makes all the difference. Yeah, I think AB talked a lot about it. I think it makes her. 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 code. 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, yeah.

So that's why coming back to this, like, humor and self-deprecation, you want to work with colleagues who are. 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, 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 stuff you can learn from them.

Yeah, and I guess 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. And 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 iFC review is getting into tons 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 every way you're but it's second reading.

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, no, yeah, absolutely. What are some non-obvious recommendations to thrive inside a high-growth startup? Yeah, non-obvious. So 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 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, is really critical to be super successful. I talked about the best engineers don't stop at team bondari. they will keep going. Our industry, our work is mostly about building abstractions on top of abstractions, on top of other abstraction.

In reality, there's always leaky abstraction 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 like the weekly update helps is like you set your timeline and if you find like a creative way to to reach a timeline faster, it's a really powerful move. When it comes at working at high scale, at fast-paced startups, a lot of people have imposter's 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 who 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, have been really interested in ancient philosophy and storyism. And when you read those ancient philosopher reading, 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 try to work on those aspects so that you become a better engineer. 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 good drive. It's a good engine. Even Twan, CTI 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 impulsors 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-girls startup, 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.

So for instance, one of the books that I, none 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 algorithm. as well. Like, why did the kernel choose a red-black tree, for instance, instead of a hash map for certain data structure? So it's really interesting, really fascinating. So fundamentals about your programming language. Adjacent fields. So I mentioned complications by Artur-Garande 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 is a great way to improve your. 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.

And I guess as I going to the gym and, you know, working out, you're now working your kind of mind. Yeah. I've also been reading a lot more philosophy lately. I mean, evidently software engineer is a very scientific endeavor. But there's a lot to be said also about the fact that we handle concepts. So it'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 of problem.

Well, it's a core of human thought. It's a 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, Cal. 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 God 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, right? 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 this good argument 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 laying 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 in 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 strengths to go against difficulties and maybe opposition and humility. Because also when you're focused on logic, on truth, you can also say, hey, I was wrong.

I mean, sorry, or like 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 share that, no matter how senior or experience they are, how fancy I'd all they had, they had an over mind,

and they would change there, and they would go like, okay, yeah, let's build this idea, or let's go with your idea, zero immediately. A lot of the advice that comes out of, you know, like people who worked at Uber at a hypergo timer, today it'll be at Open AI. We could argue a little bit. Is that survival bias or not? It is. I think it is 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. right? The speed up that you get when you're focused on shipping definitely has some tradeoff 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 are 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 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 pole where the, so it was push.

So the server was now pushing. And it was far more efficient, faster, shorter delay, et cetera. 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 project overfocus on quality and constraints. when actually people want speed and being in control, there is this fascinating article about malleable software,

software that leaves a 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 spreadsheets is it the purest. What you see is what you get, right?

Like it's everything in front of you, supports mass change. I would submit that a lot of startup have an incomplete buggy implementation of Google spreadsheet somewhere in their tools because it's so effective. One interesting story from Uber time, the user's table and the trip table had two interesting columns. One was called user and trip tags. So user tags, trip type, another one, which was a free form list of tags.

And another one was user attributes and trip attributes, which was a key value. store stored as a JSON in this column. He was insane when you think about it, right? And it was massively overused. A lot of teams did not want it to add columns to the trips and users table. So what they did instead is a stick stuff in those colon. Free text is pretty much blonde. 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, like, 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, you know, reading what other fast school 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 Open AI 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 guard wells in place so that it does not catastrophically break your system but leave the user in control because you will get so much better like 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

odds 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, like 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-paced text prose that was written by an AI. I want to make sure I stay in control of what I write.

Because, yeah, writing is sinking, 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 workflows? 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 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 revolution and AI might be the biggest yet. Don't get me wrong, but every time we have those revolution, 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. And for example, your team is still hiring, right? Yeah, 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. Yeah. 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 code. Of course, you review. Because there's always things that go wrong. What about security or an increase of would we? have increased of attack surfaces

by using AI? Yes. 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 VAT 20,000 of repository. Well, agent are that at scale. So it's going to be an incredible time for security engineer. 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 used it to help with some of your documents, but do you think it changes the injury manager's role? It helps, 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 ping my manager for advice and maybe more basic stuff. Now I get a first review from an AI. It's either missed. 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, it'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. to generate my feedback review.

It's unavoidable of happening. But as you say, there is a point of writing as thinking and there's a reason companies try to force a little time to reflect on, you know, your relationship with this person or what you think of yourself, et cetera. 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 we 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 an interesting, very interesting contradiction with AI, specifically with text generation. I wonder if we're going to see more, we might see some other things in software engine 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. You know, users don't care, like what exactly code runs under the hood. so maybe it will 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. And 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 you were 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. You know, it can generate like pages of text. It's also very good at generating a lot of code based on a prompt. You give it a prompt that 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 times in engineers to not write verbose code, right? like on code reviews, we'll push it down. We don't want to copy, for example, functionality that exists elsewhere. We would rather reuse the abstractions. What do you think the impact might be if we just continue to start experience

that we will have a lot more code generated, a lot more wordy code than need be? Where will this lead? I think those startup 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, 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 exist 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 risk is you end up with so much code that you actually default on the code like being so overwhelming that when something bad happened, you cannot debug it yourself.

You have to involve other IPI that will fail. Yeah, we might relearn some lessons that we've already learned as an industry, you know, a few decades ago. Yes. And as closing, what is the 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 Stoubitt is the 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 remember, yeah,

remind people that most of Uber was built on top 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 type languages

as well. And then learn. I learned a closure. I never so that's the second, I guess, category. I never got the opportunity to use it that much. I think it's a beautiful language. Lips, 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. No, great, Charles. This was a really fun conversation. I'm glad we had it. Yeah, same. Gary, it was a long time overdue. I hope we enjoyed this candid conversation with Charles. One of the things I liked most about him

is how it 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 rolled 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 at your 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.