How do you think about Python ecosystem today, the Rust ecosystem and the Go ecosystem? The Python ecosystem is a lot of infrastructure, a lot of provisioning machines. Rust, I think to work with binary data, if you build a load balancer, you build a database. Go in particular, I think it's just a good language for building web services and really kind of only web services. Speaking about AI-authentic coding, how are you using them?
I had to build my perfect control system to get my logs and visualize what's going on production. And I've never done this before, just because I give them that for. Why have you become so much more positive about these AI coding tools? So the biggest thing is that Armin and Runisher is a widely known open source contributor and the creator of Flash, a popular Python web framework. He was also an interior number 1 of Sentry and is now building his own startup, making heavy use of AI tools.
Today with Armin we cover, why AI coding tools are making the choice of programming languages more important and not less. Python versus Go versus Rust versus TypeScript and which languages choose for startups and why. What Armin learned about error handling after 10 years of Sentry and why typesafe languages like TypeScript don't seem to reduce errors and many more. If you're interested in understanding more about the strengths and weaknesses of programming languages, how Elle and changey how startups are built or want to know more about error handling, this episode is for you. This podcast episode is presented by Staffsake, the unified platform for flags, analytics, experiments and more.
Check out the show notes to learn more about them and other season sponsor. Let's jump in. So Armin, welcome to the podcast. Hi, happy to be here. So let's talk about programming languages.
You've been very deep into Python for many, many years, well over a decade and now you touch on other languages. But with Python, how have you seen the Python itself change? And can you give us, for those of us who are not as in depth in Python, give us a bit more detail about the 2 to 3 migration drama, which I think if you work with anyone who worked with Python, you've heard the moaning. I was a dooper when this happened and there was a lot of back and forth, a lot of delaying. It seemed very rare for across any languages to see what happened from Python 2 to Python 3, which seemed like breaking changes, lots of disagreements, some people just wanting a lot of very competent and good engineers wanting to stay on the kind of 2, which is lower than 3.
So what happened there? Yeah, so fun fact. This year was the Python documentary, which grew to invited me to be part of, which was very nice. And I had that documentary had a segment on it on the Python 2 to 3 migration. And it basically made me go back in time just to remember all of it.
Because in many ways, my memory was incredibly fuzzy and hazy. I also remember certain parts of one another. So if you really want to go into the deeps of like Python 3, look at the Python documentary, there's a whole segment on it. But I think in retrospective, I think you can't do it anymore. It was just at this moment in time, it didn't kill Python.
But I think it could have, right? If people didn't put a lot of energy into actually make that migration work, it could have been quite problematic for language. Because if you go back to Python 3, oh, and 3, one and 3, two, there were so many missteps in the original library designs and decisions to be made. And so as someone who maybe hasn't participated in this originally, you have to consider that Python started out with just basic byte strings like C. Eventually, it gained some Unicode strings as an option.
So you give the U in front of the string and it became a Unicode string. And Python 3's biggest motivation of existence was to be a lot more strict about strings and move everything to Unicode. What wasn't quite anticipated is that migration was a little bit more nuanced in practice than designs. There was a very simplistic view of what Unicode looks in the real world. And that just didn't look like that.
And I actually think that Python's messy Python 3 migration also had a really positive impact on other ecosystems, like you want to, for instance, because there were like two things happening simultaneously. Python 3 got a little bit more linear to working with non-unico data. But also, a bunch of the situations where Python made it very hard to work with Unicode were actually all kinds of configuration issues. So I remember not every Linux had UTF-8, it was still very common for you to connect to the university network and not find UTF-8. Which had all kinds of really funny things on the file system.
Sort of these things converge a little bit, so the Unicode story got better. But you had millions of lines of Python 2 code that couldn't work on Python 3. And the initial assumption was you can just migrate once and then you're Python 3 and you're good. And that's not what happened. We had to maintain libraries simultaneously for Python 2 and Python 3 for many years.
And I remember meeting at the Python language summit in Florence where I proposed to bring back the U prefix on Unicode strings. So you can have them optionally. Because I noticed that if they were there, I could write code that supports Python 2 and Python 3. And I still remember it was a huge pushback. Why would you even want to maintain a library for both two and three?
You should just move to Python 3 and make everybody move like that. But that just doesn't work like that. So what really made the Python 3 migration ultimately work was a lot of effort putting a lot of people. And just a more realistic look into that you have to, it took 10 years or more even. You have to just support both versions in one form another.
That is what made it work. But I think the Python 3 migration also left a pretty important data point for future languages to approach this better. And I remember Rust early on specifically pointed at the Python 3 migration to demonstrate why it wants something like an addition system. Or I forgot what it's called, but basically I targeted opting into new features or opting out of all features. So that you can have code bases even within the same project from different versions.
Nice. And speaking of the different system programming languages, you mentioned Python has been, was your favorite language for a very, very long time. Later you helped introduce Rust into sentry partially for performance reasons as well. And now we're also playing with Go. How would you compare these languages?
And when you think of a language, what is your mental model of what is this language good for, not good for, what would I use it for? I wrote a bunch of blog post, which I'm not quite about languages, but they're sort of about my general split brain in a way. Because I have two programs in myself. One is I like building cool open source software, hopefully thousands of people use and put a lot of handcrafted efforts into it. It's like this, with watchmaking of source code writing.
And there is a care lot about the language, a care about the API and everything. But then when you build a company, when you build a product, none of that matters. Like, is it right once run many times code, but not right once right many times against the code code? Right. And so what makes Rust amazing, I think, for crafting really cool open source code also makes a suboptimal programming language for a startup, because there's much more friction in it.
It's a much more precise language. It's a great lift up compared to C++, which is in many ways what the alternative would have looked at sentry for binary file processing. But it's a much less capable language for a startup when it comes to rabbit iteration. Can you give examples of this friction? But what would it?
It rust compiles so incredibly slow. Speaking about tool choices at startup and scale ups, here's a friction point that hits most growing teams. You're running feature flags in one tool, analytics in another, and trying to debug user behavior in a third. When you want to know if a feature actually improves conversion or if something that you ship is causing a bug, you need to manually assist to get your data from these different dashboards and then hope that the user segmentation matches up. Most things up end up in this situation.
You should feature to some person of users, then wait a week, check three different tools, try to correlate the data, and you're still assured if it worked. The problem is that each tool has its own user identification and segmentation logic. That's where Statsik comes in. Statsik is our presenting partner for the season, and they've solved the tool integration problem by building everything with a unified platform. Instead of stitching to good point solutions, you get feature flags, analytics, and session replay, all using the same user assignments and event tracking.
So you ship a feature to 10% of users, and the other 90% automatically become in control group with the same event taxonomy. You can immediately see conversion rate differences between groups, drill down to see where treatment users drop off in your funnel, then watch session recordings of specific users who didn't convert to understand what went wrong. The alternative is running ETL jobs to sync user segments between your feature flag service and your analytics warehouse, hoping to time-snow to line, and then manually linking up the data that might have different user identification logic. That's a lot of work. 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 statsik.com slash pragmatic. There's a huge factor. You write a lot more code compared to Python, you spend a lot of time thinking about types. I love types. I think they're great.
But certain things are incredibly hard to express with types, and I don't even have to think about it in Python, right? Working with them. And I think one thing to consider here is dynamic and steady language. I've aligned a little bit more over the years. I remember the dynamic keyword learning in C Sharp was a great thing because it showed people they can have a statically compiled language with in dynamic runtime type, for instance.
And TypeScript took that entire idea and applied it to JavaScript. You can have both worlds in a way. But Rust is very straightforward. There's static types. If your problem is a dynamic type problem, then you're basically going to create the dynamic type wrapper.
Left and right. It is also that the border checker, as great as it is, is a huge problem because it doesn't allow to express certain things that other programs expect it to be, like it's chasing bores. So you can have a struct that bores into itself coming from C++. It's like, why the hell? Why does it do that?
Here's my problem. I want to solve it. The compiler says no. It's like, no, you're wrong. It should work.
So that is like, you can run yourself in the corner. It's incredibly hard to come out. So I think from that perspective, there are a lot of problems which are not rust shaped. There are a lot of problems which are in fact rust shaped, but a lot of them are not. So one of the reasons I'm using GoV right now for the new company I'm working on is because it is a very pragmatic language.
And if pragmatism is what you're after, then why not? And you can expect it to hang around and it's not super sexy and it's like worst case, even if Google is not maintaining it. You can imagine that but with dozens of other people who want to keep it alive. Even modern Java is actually an awesome language. It has virtual threads and makes me happy.
Like I don't have to deal with promises all the time. So I think a much more pragmatic view when it comes to what a company should build its stuff with because the focus is not so much the code. It is the product that you're building. So you're now doing a startup. Is it a few people?
Is it yourself? So at the moment, it's me and a co-founder, but we just started hiring. And also it's me and a co-founder, a bunch of clothes and a bunch of codecs and everything. So there was definitely change in a sense that there's an army of interns that also now writes code and that has also changed the way I'm looking at things. So now it's you and your co-founder with the startup.
You've got an army of clothes and codecs and you're expecting to grow the team to hire. As you've settled on the technology you said in this case, this is a lot of it will be Go. But what does a programming language need to give you? And for example, why was Python is very flexible? Okay, it's a bit slow but you said it was a good choice.
What would you say is this good middle ground between Python and Rust and so on? Yeah, so right now I think if you're built any company at all, you're going to end up with Python in there if you want it or not. It will be impossible for you to build a company that doesn't have Python code in it. Do you want to build your main service with it? Probably not.
But if you do anything with ML, if you do anything with data processing, Python is going to be in there and you can write nice code in Python too. So it's like that's going to be there. Good luck not having JavaScript in the company and if you have JavaScript you have TypeScript. So those languages are going to be there. And other questions like how much of that code that you write overall is in those languages.
And I actually felt that I don't want to build back in services and eat on one of those languages. And not even for performance reasons but just for ecosystem, like what the ecosystem is like good at. In my particular case right now, a big part of what I'm doing at the company is parsing emails. And that's just not something JavaScript is amazing at. And something actually Python is quite good at but I think at scale is Python a good choice here.
And I looked at it and I made the decision that I wouldn't. And from the experience of doing Rust in that space at century, I felt that I can totally imagine at scale. Like Rust will make its way back in but at the moment I don't think that that's the right trade-off. And when you say at scale, this is just thinking about when you will have to process huge amounts of data, lots of process running and so on. We're talking specifically about the performance capabilities of line.
I think it's a scale of the company and that is not necessarily measured by how much data goes through it. If you scale a company either by the number of people working on it or the complexity of how much data goes through it, you have to make trade-offs and sometimes that means introducing your language. And so it's easier because of performance reasons or because you integrate into some ecosystem that's particularly strong in some certain environment and then all of a sudden the language is here. Why did Rust exist at century? Well, it didn't just exist because I wanted to write Rust.
It also was like, well, now we have a problem with performance. How we going to solve it? And on the one hand it was like, well, we could probably write a go service here. But I didn't want to maintain another service. So Rust was a pragmatic choice of embedding it in Python.
And then later on when we did native symbol processing, the alternative to Rust basically would have been C++. And for my experience of working with C++, we used C++ on the project first, which is a lot of crashes. And I just didn't feel like I want to maintain that. And so then there was no choice of using go because there was no go ecosystems. Unless I would have built everything zero, it wouldn't have worked.
But Rust was growing and Rust had the same problem in the compiler. So the Rust ecosystem for debug files was really good. And there was another company also working on it for Mozilla at the time. So there was already two shared interests in this. And that was a really pragmatic choice even though the language was Rust.
And maybe we already did a little bit by putting Rust into places where it wasn't the most optimal choice, like the ingestion system. I think at this point probably wouldn't make that decision again. But it would have been non-pragmatic at that moment to say, like, you know what we're going to do. We're going to go into the corner for like nine months. And we're going to build this all in this now.
Because for the size of the team at the time, the problem was too big. And so we had to reuse something. So that's one of the reasons I think why I can't imagine that my company is going to again end up with adopting a language further down the line that it kind of initially set no to just because the situation makes it necessary. And it doesn't necessarily have to mean that performance is the reason. It cannot just be ecosystem stability or anything like that.
And speaking about ecosystem stability ecosystems, how would you think about Python ecosystem today, the Rust ecosystem and the go ecosystem? Python ecosystem is a lot of infrastructure, a lot of provisioning machines. So that's why I'm using it for it now using Pulumi with Python to get infrastructure up. It is really well entrenched in machine learning. So that's I have a little data pipeline going on that uses Python.
It is also pretty good still at bringing services, web services to some of the things Python is good at. We're not necessarily right then like the main application logic in it. Maybe, right? Because if I'm doing a whole AI first company and all it does is inference, I'm just waiting on a network layer anyway. So maybe putting some things together with Python is great, particularly also if you start to do a chanting thing.
So we want to have code execution on demand. Maybe that's a good choice. So I think Python is a great future in it. I just don't think it's the most natural language to pick for a service way. I think it's going to be a lot of that higher throughput.
I think at this point, Go is an easy language to write than Python for a bunch of engineers because Python is increasing complexity and Go didn't quite as much. So I find it to just be a better trade off for complexity too. So Russ, I think if you have, if you work with binary data, if you maybe, if you have a, you build a load balance, you build a database. Or maybe the database is not people talking about seek and stuff. But if you build like a rust shaped problem, which I think is actually defined as you single binary to distribute for some reason or not.
It can't deal with the garbage collector. You want very predictable performance. You really care about data layout. It's also good. But rest of the benefit that if you also then work in something that requires concurrency and we're afraid of mis-managing memory and crashes, like modules that might load into some other high security environments.
Like a browser seems like a pretty good choice. Working with, again, like a dwarf files, like working with just data in general. I love Rust. And I think it's such a pragmatic language also for if you extend Python. So if you already have a Python problem and now you have a performance problem or you have an ecosystem integration problem, and Rust happens to fit into that.
Writing extension modules in Python for Python in Rust beats everything else out there. It's a really good choice for that. Go in particular, I think it's just a good language for building web services and really kind of only web services, maybe some command tools. One of the other reasons why Rust, I think, is impossible to get rid of is WebAssembly never really took off, but the use cases of WebAssembly are impossible to get rid of at this point. There's so many things you actually have to bring into the browser and Rust can do that.
I try that with Go. It's not a great experience because of the garbage collector and some of the complications that come with running go in the browser. So you wouldn't do that, but with Rust you can. So I think you kind of have to approach this from a perspective of what am I doing here? What's the problem that I have?
And then you say, I want to have not more than three, four technologies in the beginning. What did I use it? And then finally, I guess the one that we didn't talk about, which is about the JavaScript type script ecosystem. When the browser, you can't get rid of it. On the server, I think there's, I'm very conflicted on this because I actually think that it's a pretty good language environment at this point.
Particularly, hypothetically, if someone were to make the JavaScript two, like the Python three of it and get rid of some of the naughty stuff, I don't think anyone should be doing this because I've seen a migration, but there's a lot of good stuff in the language now. That's just also some really old-dumb stuff. Why am I not building back-end services with TypeScript right now? Actually, it's because of the npm ecosystem. Like, that ruins it for me.
I'm a low-dependency kind of guy. I want to control my shit. And I feel like it's impossible for me to build productive in the JavaScript ecosystem with under 500 dependencies. And that makes me uneasy. On the browser, I can live with it because I don't have much choice.
But on the server, they really have to do it. They have to deal with the fear of all of it and managing it. So it's like, that honestly ruins it for me more than anything else. And so maybe that will change as the ecosystem is mature in other ways. But that really, I think, is the biggest reason.
And it doesn't have enough benefits from the server that I wouldn't just say. Like, this is the idea that you have a unified codebase. And every time I'm trying to make a unified codebase work, I just realize that the browser, actually, is sufficiently different. It's very hard to actually have a unified codebase. And so then it just be explicit, like, to some open API chain and some code generation.
It actually feels much better. Yeah. The biggest argument I keep hearing from developers for TypeScript is the unified codebase that you can have a React and TypeScript and then on new, let's say, node, because that's the express or whatever. On the back of the now, you have to say language and people can contribute, which I think was very, very compelling, especially before we had AI tools, because now you didn't have to learn a new language. Now it might change.
I said this recently in a sort of talk about the meat up, which is I think right now the floor is raising the ceiling, not really, in the sense that the expectations that everybody has in everything is much higher than it was before, but also because the expectations are higher and more tooling to enable it. And so code generation, for instance, right now is in a much better state than it was even just two to three years ago. You can even buy off the shelf open API to SDK generators now. Right? It's like, I don't even know what the company's called, but stainless lenses is one of them, which generates all the APIs for all the AI cloud providers right now.
Yeah, for as the case, yeah, they're one of them. That was a huge cost of doing anything essentially is like, how do you keep this SDKs around? It's nice. Well, I have an open API chain and again, somehow magically on GitHub and SDK appears, is it really so important for me to have a unified code base if the code generation is so damn good? Like, all of a sudden it doesn't matter quite as much anymore.
So I think that there is definitely some value to it, but you also have to imagine that if you have the unified code base, then the boundaries are sort of accidentally very undefined. I think if RSC, I know this is a lot where like, it's very hard to actually reason your head around what's on the server, but it's not. So actually having this extra boundary for me is almost like a feature. Speaking about AI agent decoding, one thing that was very interesting that you mentioned is there's two of you in the startup right now, and you have just a lot of kind of, you know, like these AI interns running around, cloud code, codex. How are you using them? What are you seeing from them?
And by the way, can you also share what you're building with them? Speaking of how Armand is co-founder using an army of AI interns, she'll just how much software engineering is changing. Our work as a software engineer is no longer sequentially doing one thing after the other, but we can kick off parallel to work with AI agents. This is one of the biggest changes in the software industry in a long time. A leading example of this change comes from our season sponsor, Linear.
Their cursor integration lets you out cursor as an agent to your workspace, this agent that works alongside you and your team to make changes and answer questions. Say you have an issue with Linear, like a bug fix or a small feature request, you just mention cursor and ask to take a look at it. Or you can simply assign the cursor agent to a ticket and follow along its progress. This delegate's the issue and off cursor goes. Curser then runs in the background, writes in the necessary code, opens a pull request, and once you root the changes, you can merge it.
It might not always one-shot task, but it's pretty good, mostly because the agent has access to context that's already linear. Project plans, backlogs, issue description and discussions. It's so useful. You can now delegate bug fixes, trivial work or tedious tasks to the agent, then come back when it finishes. Linear sort of feels like ground zero. You've got to try it out.
Head to linear.app.pragmatic. Yeah, so we scoped out the email to be in a fascinating space to work in. And so you can kind of imagine what the kind of problems that you have when you work with emails in one form another. And maybe a little bit of why we went into the email is because one of the things that is very evident now of the biggest shift in at least my lifetime, what's capable of computers is that natural language processing is now available at scale in many languages for a reasonable amount of money. And that's a good reason to go into email because email is all about natural language and there's a lot of good data in it, but it has been very hard to work with the data in the past.
If you read my blog, you noted my opinion on AI stuff for programming was incredibly negative up until February, March, where it slowly moved around, and then it may have was like, holy shit, nothing is going to be the same anymore. And one big reason why I'm actually so bullish on this is because when you think into, and actually think it doesn't really work as well for teams today, I think maybe there are ways I'm going to see as I'm scaling up this company, like how it is going to work at scale. But one of the reasons why I think it will actually be really good is because if I look over the years of all the stuff that I wish I would have been able to do, I just didn't have the time for it. And I had to make this explicit decision not to do it. I have too many cases of this, right? I remember we were reworking the grouping algorithm at Century.
The grouping algorithm, what is that? It's like making sure that two errors, which are very, very similar are grouped into the same group. It's a data problem at scale, but it's also one of very specific data. So we spent like three weeks building just a basic visualizer for ourselves to figure out if the new algorithm works by the new old one. I go for a fact that I get this tool in 30 minutes on this side from Claude.
It's around 5,000 lines of code and it looks better and has pretty UI and everything. So the sort of, there are many projects that didn't go anywhere because their legwork needed to build yourself this bespoke tooling to even be able to pull this project off, like a migration system or something like this. It's just too much. And so that's, I think, one of the big changes I'm noticing for myself is that I have so many better tools around now. That's just making it much better to work with. I move from Terraform to Pulumi for one of the services just to see how it goes.
And I had Claude build me my perfect control system to get my logs and visualize what's going on in production. And I would never have done this before, just because it would never work. Not a big question. How about this work on the codebase? My co-founder is not a technical co-founder, but that doesn't stop him from using Claude or Codex now.
And it's actually great because it means that even someone who maybe, normally, in certain stages of the company, there's a bunch of stuff where you wish you could do something, but it actually requires maybe more coding skills than otherwise. And so there's an entire codebase where I basically don't look at. Which actually validates a core part of the feature we're working on. And it's just vibes. And it works. It's not pretty, but it doesn't necessarily, because the whole point of it is figure out,
is this experience that we want? And this is great. And then things like how much of the code that I'm writing, which I feel like this is going to be a foundation of what we're doing, is at this point, it's authentic. And like, I guarantee you it's 180%. And it's like, there's very, very deliberate code, which is not written this way, or like where I really put a lot of effort into it.
But most of the code that exists in this codebase is not so important. It's a bunch of API endpoints. It's a bunch of open API specifications. It's a bunch of run-of-the-mill pieces of code. They should look nice. They should pass all the tests. They should follow exactly the architecture that they want.
But if you were to compress them down and say, like, what's the actual information contained within them is very little, right? And so with the right approach, you're actually very productive with this. What made you so negative, or like just pretty negative up to around February or so, the things that you were just really skeptical about? And then why have you become so much more positive about these AI coding tools or agenda coding, right? The biggest thing is that it actually now starts doing work that I hated doing, but I know I had to do.
So that is it. As an example, yesterday, I really had to figure out why one of the endpoints that I have worked running there in production didn't work quite as it should. And it was not a problem of the error in the code. It was a problem of AWS permissioning. And there was a chain of three things that I did wrong. They all resulted in, it couldn't do what it was supposed to be doing.
First, there was an IAM permissioning error, and then there was a wide listing error in a different system. And then the final fuck up was, I forgot what it was, I think, but the final fuck up was also something where maybe that was actually logic. But the point is it was one error and one error and another error. And you couldn't see them all at once. And I was also busy doing something else. I was looking at this. I know I need to debug this.
But if I'm going to do this now, it's going to take me at least two hours. But it didn't matter because Claude was doing a lot of it. I still had to copy paste a bunch of things into logs. But it knows so much because it has well-knowledge access, it can combine a bunch of things together. And I could make progress on what I was doing while he was also fixing and debugging this production issue.
And that is a significant improvement. The same thing with one of the things I hated the most was creating repo cases. But I know that every time I go to the repo case, I enjoyed it so much more. And now I can say Claude, make me the repo case for this. This is roughly what it looks like.
Let's not try to fix it. I figure out how do we get this one function that can keep calling in a loop. That is what we're trying to figure out here. So I was not able to get that experience out of cursor, even with the enchanting mode, prior to May, April. But that was really what changed my opinion on it.
And then as I started going deeper and deeper into, okay, now that I know that I can do this and I can do this, I also got incredibly adventurous in giving it more things to do. And now I have a new sense of where it could go just by giving it the things I don't want to do, but staying in control of the things I do want to do. And that was a big shift for me, was recognizing that it can do that in a way. And so far, what are you seeing in what these agent tools change about software engineering and what are things that don't change, especially you've been writing code for like what 20 years or so?
So since the architecture and overall complexity and how you build things in a way that something stays maintainable, as it scales into a larger and larger company, there's a lot of experience in it. And I also didn't have all of that experience at any point in time. So I felt like this is one of the things where I really like as time went on, I learned a lot more, which gives me a benefit over my prior self that didn't have that. That is going to continue to be true. Now, there's an argument to be made that maybe Claude is like systems like this will help you and maybe can even bootstrap these sort of things around it.
If you fully delegate everything that you're doing to machine, then the person that doesn't do that has a natural view. Right? Because there's going to be some innovation that is not in this thing set. So right now what these systems spit out is sort of our best understanding of how stuff worked up to this point. Right? And so having something that maybe at scale is not in this corpus yet is where some of the data comes from.
It also creates a better culture in a company if you're not completely delegating everything to a machine. Because what's the point that it's just a bunch of like this? This is one of the reasons why I want to hire more people now. It's just because Claude is not a human. And it's just that there's an energy to a well-running company and to motivate people that's just a computer counterplace.
So I think that is a big part that sticks with you as an engineer. It's like understanding how to create your systems, understanding when the code that it produces is more right versus more wrong. So I don't think much of this has changed. I feel the same programming with Claude, even if I physically write less code. It's just that I don't know that the physical act of punching the keyboard is not quite the same anymore.
What has changed of that? I think the cost of building your custom tools went down. The ability to make better decisions now for me is heavily improved. In part it is because it goes very well. It searches the internet very well.
If I now have a problem of a type that I didn't have before, it can teach me this problem. As this one of the things I use a lot of is I don't actually want to get the answer. I also want the answer, but I also want to understand why that's the answer. It can do that and it can put it into the perspective of it. I'm not very good with a lot of very complex math.
I found that everyone said why I need to do that. Having Chetchibiti down it down for me helps me a lot. It's like it's seemingly, if a problem is presented in a certain way, it works very well for me. It's a problem is presented in a different way, but it can be an abstract way in which you have it in many papers. I'm not nearly as good as I should be, I think, for what I'm trying to do.
But Chetchibiti helps me grasp it quicker. I think that's a huge change. The other thing that definitely has changed and I even wrote about this recently is that it brings a whole bunch of people into programming that didn't do this before. I wrote about it before, but I had a four-hour conversation with a traffic controller on a train who talks about how he's Chetchibiti and how he can even do some programming with it. That's the program now.
He's a very specific problem. He wouldn't have programmed before, because there's Codex in the Chetchibiti subscription. He's able to solve some problems that he wasn't able to solve before. That is a huge unlock. We are going to have many more programs just because the by-product of asking a question, Chetchibiti is programming.
He's going to keep running that code and maybe one solution changes to it. One of the side effects of last being so popular is that it has been in university courses. It has been onboarding for new programmers in boot camps and things like that. I've been exposed in one way or another through how long it takes for someone to learn programming. That's not a thing that you do in a day.
For you to be a productive programmer, it's capable of speeding up the program. That's a couple of months of work. Now someone can press a button and get something. Then maybe in short programming, maybe that's like, now I see the effect of having produced something. Maybe it didn't do all the things, but it's still the same gratification I get from it.
Then maybe that's a way for you to, for people that wouldn't have gone into programming, to actually go into programming because the onboarding has been so much easier. We talked a lot about programming languages. Then you have very specific, you have your opinions on them. With AI and Cloud CodeX and all these more and more capable agents being here, how do you think the importance of programming languages will change? Do you think it'll be limited to a few people or just fewer and fewer people like yourself and others who actually have spent a lot of time understanding the pros and cons of programming languages are thinking well beyond?
Because it sounds like you can just tell AI to solve it in whatever you give it in a system code base. It'll just do it, right? So there is an argument to be made that programming languages might not be that important anymore. What does your take? Well, I think I will be consistent with the prior thing that I said, which is I think I have a lot of respect for programming languages because of the trade-offs that are in there.
With AI now, I think you might have to start looking at different trade-offs. The reason, another reason why I end up with Go in my startup is because I just noticed how good Go code scales for AI because the abstractions are very thin, it understands the code better. So clearly, there's some, I did the measurement, right? I made it write a certain type of program in different languages 10 times and see how often did it pass? And it just noticed that it did so much better on Go than it did on Python and much better than at Rust.
Clearly languages matter because the quality of the Asian is going to do it will matter. And then is any of the languages I have right now, is that the perfect language for both a human and a computer combined work environment? I don't know, maybe from the pinnacle of programming languages, but maybe there's also exactly the moment in time where some of the comments are like, I have a brilliant idea of what the better trade-off is here because the cost of doing this kind of stuff is going down with AI, but because of this and this stuff is going up because of AI. So let me rebalance this in a different way. So actually, I think that programming will continue to matter a lot, particularly the trade-offs that the programming language implies on the runtime environment matters a lot more.
So I don't think that's going to change. I think it's just going to, everything accelerates. Everything is going so much quicker right now, or it feels to go so much quicker because the fundamentals are shifting around. And this is not just with now everybody wants to build all the new things. It's also like, you feel like if you're not working all the time now, you're missing out on some of the changes.
And I don't think that's just on the product side. I think it's on the text side too. I'm pretty sure that a bunch of people who are feeling like, I want to be the first person to build the programming language that works really well for agents and humans, but it's not just one person, a lot of them who are looking into this at the moment. It just feels so, like there is in fact a moment right now to build the perfect language, or a better language that works in an environment because we are probably not going to get rid of the chandel coding. What is the likelihood that all of the languages that we have right now are the best ones?
Probably not that high, right? So it will be the same and different in many ways. And one thing not to be underestimated is that the likelihood that computers are just going to program and no human is going to be in a loop, I don't think it's very high. I think the human will stay in a loop longer than we want, and in many more cases than we want. And so you cannot go down to say like what the optimal output is, right?
A bunch of assembly code because nobody can review this anymore, right? And so if anything, the tradeoff won't happen when you're right, when you're right, you're right, when you're high level, so that reviewing is easier. Also don't forget that the thing with assembly, right? One of the reasons we have higher language languages is assembly needs to be different for every architecture type or every CPU type, which is why Java was so popular in the early 90s, it ran on both Macs. I do think I can just have the AI ported to my operating system.
They could make the argument that maybe they didn't need it anymore. I don't think that's the opinion that I hold, but it changes the cost of some of those things, right? But you mentioned an interesting thing, which is how everyone seems to just be working all the time, which is this interesting contraction of how AI or these ages you can kick off and you could in theory go to sleep and have it just run in loops for you and so you could work less. But in fact, we're seeing working more and we now have this thing, which is very amusing to observe that AI started to work. So we observe that AI started in particular or increasing demanding or advertising this 9.96 from 9 a.m. to 9 p.m.
6 days a week, especially in NSF, they're putting it in the job adverse. They're posting it kind of probably online that in the office at midnight or after midnight, people are still there and working hard. You share some thoughts on this as well on your blog. It costs quite a bit of service. But what is your take on this? Because you did say there is a lot of energy right now.
There's a feeling of not wanting to miss out clearly. That's why these people are doing it. So, a handful of thoughts, one of which is I actually have the credit Peter Schienberger quite a lot of pushing me into agent decoding because he worked in a comic called PSP.K. which is sold. And then I don't want to tell you a story but long story short at one point, he was kind of stopped programming and then he fell and I was like, hey, I found this computer which borrows from me and he doesn't sleep anymore.
I'm so addicted to it. You should try this in a way. I didn't quite say it like this but I'm skeptical. But the computer that does your work, you can't sleep because of the dust kind of so amusing. I realized that it does something with your brain if you do this in a chandel coating thing.
Because in the beginning, if I'm not having it running and doing something, I'm just wasting time right now. It's a huge part about it. It's almost like a drug. It has this instant gratification of something happened. And you can kick it off again. It's like this is a lot of machine.
And I think I attribute some of it to that. It took me a while to actually come out of this. Because it's not very standard. I did fruit and night with chandel coating. Not because I felt like I'm incredibly productive when something was using for my startup.
This is blowing my mind. I just want more. I think to some degree, because if you're so AI close, that probably also contributes. The other one is I think everybody sees the change and wants to do as much as possible. I think the tricky bit with the 9 and 6 thing is that 9 and 6 defines a very specific kind of work regimen, which is you work 12 hours a day and you don't have a weekend.
I never did something like that, even though I probably worked sometimes 80 hours a week. And the reason for this is that I know that I cannot be productive all the time. If I work late at night, I will shit in the morning. I have your kids, I have a wife, family is very important for me. It's the most important thing. So I will always arrange my work around that.
You can work with intensity, but you can still do it in a way that is not crazy hours at crazy times, which is that you're optimizing to the optimal output that you can produce somehow. And I would say there's a huge difference between if you are the founder, or if you're very, very early engineer with a really good compensation system, where equity means that something's to you, from most of the people who try to come later on, or where the company has no realistic path of their equity being worth something. There's absolutely no point in putting a ton of effort into something where only one person benefits from. And there's a lot of subtlety to all of this.
What annoys me with the nine and six point in particular is that they pick that word, which if you go back to why that naming even exists is because of basically there's no subtlety to it. It's like you work 12,000 days, six days a week, and you give up what is otherwise in your life. And I don't think that's, I don't think that's a trade off that anyone should make it any point in time, because there's more to life than working in a company. And that is not the thing that you should be putting on your flag, which has such a negative connotation because of exactly what it did, where people literally kill themselves away.
And if you want to be a high intensity worker, then say that. But be more, because in part of the time, you cannot be a company that runs like that. It can only be a company where high energy people work and build themselves up, but there's a limit to which you can do it, and you have to be transparent about what the cost of this is. And I've been in the tree long enough that I've seen many, many, many bad outcomes. And in particular, through my community, a lot of people even went down, like psychosis and schizophrenia and a bunch of things, where you're likely heard of going down that also increases during certain years with unhealthy behavior.
Now, having worked at essentially, which is all about error handling or at core is there. You've probably seen tons of stats on most common errors that are coming up in different servers. What have you learned about error handling and how to build better software with fewer errors from a developer's perspective? So the biggest thing that I learned, and ironically, hasn't really dramatically shifted, despite the existence of tools like Century Inter popularity, is that many of the ways in which errors are worked with just doesn't care enough information or only care is useful information for debugging in debug builds.
And that's problematic, because the most interesting errors don't have any debug, right? Now, maybe this is changing a little bit with AI, because I can cause the producing a reproducer from not perfect information might go down. So that maybe there's a counter move to that, but I really felt that as a language designer, as a VM creator, you should put a lot more emphasis on making sure that the errors can carry really useful information rather cheaply, even in release and in production runs. And so not a lot of ecosystems don't do that, which is very sad.
And I think the fact that Python had such great introspectability without further, like, Python's low language. So if you already have all your debugging tools and it doesn't get significantly slower, that actually was the reason Century existed. Because essentially it was able to show local variables for Python, it had all this rich, powerful data, that for many languages even today, we're not able to do it because the runtime doesn't support it. Or the runtime effect of doing that is too high. And so that's the thing I learned the most, is like your experience of debugging issues is so much better if you have rich information errors.
And unfortunately, both languages, language creators, runtimes often neglect errors, so they don't carry the right information. And the application and library developers often don't think about errors at all or they capture them down in the wrong places and then the useful sector is gone and all that sort of stuff. Because you think they're exceptional, they're not happening all the time, but unfortunately every time they did happen, you didn't have enough data. So just in general, the design of errors is completely, it's not why it should be given how important they are. So that's one thing, but the Century works across a bunch of different languages, almost all languages, right?
These are the ones that are widely used. Have you seen interesting patterns between the types of errors or the frequency of errors of using language? And then you're trying to get to how important is it to choose your language in terms of having more correct programs? Well, different languages crash in different ways, not just because of the language, but also what you build with it. And so, for instance, JavaScript at scale, if you look at a lot of websites, errors all the time.
The percentage of errors in JavaScript that actually are meaningful is very, very low. Whenever I open up my deep developer tools and it then it shows you the errors and warnings, and everything goes website or almost every... And that makes sense because you very few errors that you can actually cause in JavaScript and crash your browser type, for instance. So it's like on errors you're next, you're hobbling along, something is broken, but doesn't really... But the existence of an error in a console lock doesn't imply that the website is broken, but for instance, it might now eventually start by don't fire anymore, so the click is a dead click, which is something that essentially needed a session replay product to find.
Because the actual error that you would find essentially was insufficiently linked to using or being advanced on a page. On the other hand, if you have a computer game, it's written in C++ and it crashes, your session is over. And so the comparative fewer crashes in career games compared to all the nonsense going in JavaScript, but when it do happen, they're much more meaningful. And so it's very hard to say the error rates in different languages, the four of the impact that these errors have is very, very different. So C++ code crashes in computer games, shockingly little.
The amount of traffic that essentially gets from these is very, very low, but the usefulness of each of the crash reports is so much higher. So it's a very complex topic at scale to say, how does something error because it really depends on what does it take down. Obviously, there are certain types of errors that if you see them long enough, you feel like they really shouldn't happen. To some degree, there was a large-scale realization in JavaScript because I said that type checkers could get rid of a whole bunch of clouds of errors because they're very least you have to explicitly check if this thing is nullable or not. But I also didn't ever get the feeling that the adoption of TypeScript would dramatically change anything about, like, essentially JavaScript error rates.
If anything, none of that adoption had any meaningful impact on how crashy. Well, because what I would have expected, we know and I think it's pretty commonly assumed. I'm not sure if it's proven that type safe languages will reduce certain kind of more obvious errors. TypeScript does this with JavaScript. I mean, it has a compiler, but in the end, you do get a check before it all gets compiled to JavaScript.
So we should have fewer. That's what I think. So you're saying that you didn't really see too much change? No, I think if there was an impact, it's unmeasurable. And of course, you have other sort of frequency functions that might happen that offset.
Like maybe whatever improvement that you have on like catching, like some of those, maybe that sort of makes it just more adventurous to build more complex code in comparison. Right. A lot of the time of century was the serve era of crazy complexity. And so then, like many of the errors were related to not like, did I was this nullable or not? But now the sudden is a microservice that I'm talking to and they have misaligned versions and my touch actually didn't help me at all because someone decided that on an ad or clear it's now null anyways.
Right. So the increase complexity of many of the software that sent me the help with over the years, I think you could have probably measured that. Especially I remember the adoption of more and more complex things in the real ecosystem, just dramatically increased the types of errors. Like hydration errors, one other thing for many years and then all of a sudden there's a whole class of new errors coming in because now all of a sudden the view stability between initial server render and the JavaScript dynamic load on time does. It's like that was a whole class of errors that didn't exist before and all of a sudden does exist.
Right. So it's very hard to measure these things just because of how we change and how much more code resources are. Yeah. So, so you're saying that's true before react and like hydration errors are specific to react, but those that whole error categories didn't exist and then as react spread, they're kind of pretty common and react. So now you get technically you get more errors.
It's a turn out to be very safe business to be an error because I felt really going down. Yeah. Well, and then I think we can extrapolate it obviously with the AI tools using typically using the most popular frameworks or the ones that has the most training data, which is the most popular ones. So we're probably and will likely see an explosion of code and deployments. So yeah, it's probably good business. But having been in the errors business, how did you change your, your or at the teams, the team at Century?
How did you change your approach to building software with errors in mind? Were you more aware of it? Anything changed at all? Because it's interesting. You know, you've had such good insight into like all the, I'm going to say mistakes.
They might not be mistakes, but we can say, you know, errors, generally not a positive thing, but you've seen all these things come through. So did you change how we develop software? Yeah, you were working at an observability company makes it create a building observable of products. And the reality is that there's a reason errors are not the fault. Right? It's like you almost have to force yourself to take care of this 5% case or 1% case. Right?
And that's a good, that's a continued problem. Like every poll request in a way you are not like, now it passes. So we have dealt with this. Like, are you going to put the extra time in to also make sure that even if it like now fails that it reports the error correctly? I don't think that sentries code is more correct for error reporting than any random other code out there is because the act of taking care of good error reporting is a deliberate act.
The act of like good logging is a deliberate act. The act of good magic supporting is a deliberate act. And you will train that muscle a little bit over time. But I think like you maybe get 50% better, 100% better at it, which is still very, very low. We should get like 1000% better.
Like it's like that's what we would see the improvements. Like if everything, like if 90% of errors are really, like, error cases are really well reported. Like that would be really good. But like that's a really massive lift. And you would only really get this lift if you stop programming like we are and maybe the languages themselves have like pulling this into every stack frame into every sort of corner case.
So I think that the real lift would come if a bunch of people that now build these observability companies say like, okay, now that we know what our problem is, which is data collection in the first place. How do we build a programming environment that makes this native, right? For many, many years, the biggest challenge for just bringing awareness of what we're doing was context local. What is context local? So there's an excellent talk by Ron Pressler who wrote the, I think the original implementation of virtual threats for Java, who later worked on the Loom project to bring virtual threats straight into Java, basically made a strong argument for a stack frame.
Like what's so great about stack frames? Like stack frames are amazing because they carry information basically with it. And he should have demonstrated what you give up if you move to a sync of weight where you basically chain together a bunch of promises to each other. The immediate problem that we have, if you start moving towards promises, is that now it's very hard to carry through information through all of the potential paths that this promise chain would take you. So for instance, if you want to say like a correlation ID, which would be attached to every single log event, it should be attached to every single error event that might happen as a result of this original thing I'm doing with stack frames, super trivial.
It's sitting somewhere in a stack. I will not lose it. I can walk up the stack and find it again. But with promises now I need to have this chain together. So I think that the next local is what is called in some languages. In the net it's called the execution context.
It's basically a hidden piece of almost like a fret local, but in much more narrow scoped one, which flows with the logical flow of execution. And why is this necessary? Because if you do something like open telemetry, if you do tracing, if you do things like you want to have a correlation ID, you want to have it show up everywhere. And for many years, essentially, it was like just talking to people, like, hey, you know, it would be really great to have context locals everywhere. And JavaScript, I think it still doesn't have them. In the back end, it eventually got domains initially, then it got async hooks and now it is called async local storage.
And you said, as an engineering team, even at Century, your focus is to get the thing done. You test that it works correctly. And when it comes to errors, as you said, it's usually after thought, either when it blows up, or if you've got a lot of time, or you really need to make sure that it's going to work correctly. But with languages, programming languages, it almost sounds ironic that in many languages it's an afterthought. Because as you said, if you thought it through better, saying, hey, at some point the program will crash or there will be an error, what can I do?
And there's a context local thing that you talked about? You don't think it's an afterthought? I think it's deliberately not done. Because you have to imagine that there are different kinds of forces in a program language. They say, what should the language do? And some of them are very clearly the odds with each other.
So what's the problem with context locals? Why? They make every call slower. So now it's like all the people that want to fast the language. They're like, well, now you've got to make a really strong argument about what you should be doing this.
I remember one of the biggest fights over the years that was hidden behind the scenes was on native platforms. And one point made the decision that we can get one extra register by basically using the stack register. You would give up the last register to recover the stack frame for one extra register for other users. And then you would have to use a very complex dwarf unwinding system to recover this. So you're basically like, we're moving some of the complexity of being able to just at runtime work for the stack to doing a delay through a very complicated binary program, which is embedded in the debug information file.
But what do you lose for this? Well, you lose runtime profiling capabilities because that's too slow to do at scale. So I can't do an in-process profiler, which turns out to be incredibly useful because you will find information you wouldn't find through tracing, right? You can do like, basically, you can run a sampling profiler. It also made it incredibly hard for essentially to do proper stack reports for native codes because I might not be able to recover the debug symbol because it's a binary driver from someone and nobody ever gave me the DLLs.
You don't have a source code or the mappings. I know like Facebook, for instance, Facebook's app secretly uploaded Android system symbols all the time. Like your device will randomly assign if it should upload it or not. And they were harvesting all the system symbols to increase the quality of the error reporting. Like if you have Facebook scale, you can do that.
Like, essentially you couldn't do that. You can't just magically have every century as it keeps you uploaded a bunch of files. It's just that would destroy user trust. But eventually, I think that only took place two years ago. Someone at, I think it was Debian or Redhead was like, well, this is nonsense.
We're going to change this now. We're going to bring the stack point back. And it was a fight. It was a fight to do it. And it was like, well, we benchmarked all of it, which is using 5%.
Except for Python. We're the Python interpreter for whatever reason got like 20% slower, so they didn't do it for Python. But it was one flag. It's one flag. And what matters is that flag is set by default to everything.
So it should be on by default. But this 5% of performance difference, which would assume to be more than that, there was a year-long pressuring. So I think it's hard to do because you have this different interest in it. And some people want the performance and some people want the debugability. And they might live in completely different worlds.
Like maybe this one person really cares about performance just never has to look at any crashes because that's not the area of responsibility. And then you have someone who maintains a fleet of complex services. And every one of them has a small percentage of crashing. And often doesn't run the code that they have. And then once they have the crash, they don't have the data that they need.
This is so interesting because it just reminds you of how difficult it must be to design the language. Because again, you have so many users and as you say, the person who just had a crash, they actually want ideally the language to support to get that back in a very easy way. But now it will by default slow it down either either through performance or through high or memory usage. Like you cannot have a free lunch, right? Yeah, it looks like the lunch comes with some price.
But look, I have a lot more respect now, I think, for language designers, just because of, especially the startup program, you have this naive idea of like it has to work this way, right? And then you, and then over time, you realize, oh, that all these trade-offs you have to make. And some of them are really hard to quantify. And you might even have to make some very unpopular decisions. And there's no real right or wrong that just a lot of trade-offs.
And maybe this is also why we have so many languages to some degree, but it is very fascinating to think about what some of these seemingly little defaults have in terms of what you can do with it. And then maybe what kind of people are going to pick your language. I thought Python was the most amazing language ever for building web services because I could inspect every process and it didn't make it any slower. But now I know that's also why Python was low to begin with, right? What are some things that you've learned being an early engineer, almost like a founding engineer at a startup?
And what is advice that you would give to an engineer joining a startup, a fast growing startup right now, early on? Well, I can give the advice from someone who would have joined the company 10 years ago, right? Look, the situation changes all the time, I think. But my life in many ways is a very linear path. There's an opportunity, I make a decision if I take it or not.
It's like the secretary problem, but I'm kind of taking not too many attempts of it, right? Which is like, I just want to, the passing bar for me to do it, I think that this is great, to want to work on it. And then maybe I take the opportunity to work on it. And for me in particular, I'm shaped like a person that is actually not a great employee, because I don't necessarily go and fit a particular mold. My titles at century, in many ways, over the years were, I didn't even associate with them, you know, right?
It's like, at one point it said, I don't know, software engineer on it, but I was like responsible for an office here with people on any, where I sometimes felt like I'm a payroll provider, right? There were so many other things that because like a small startup has this many, like now someone needs to deal with this stuff too, right? Like you need to hire someone to even just bring down things like this furniture into the house. If you're trying to company early, everything is in flux, nothing is well defined. And some people like that, some people don't like that.
And I think you have to be just willing to experience new things if you start at a scrappy startup that particularly maybe comes from someone who hasn't found the company before, hasn't been there when the company sort of grew from small to big, because even now for me I just realize, I can't have got to need to do all of this and this again. But that's, that people that like them, people don't like that. And you just have to be aware of the consequence of this. You have to have to wait for yourself somehow, either by being okay with just doing whatever comes up or being incredibly ambitious and deliberately taking certain paths towards what you want to go, even if it might temporarily set you back in one form or another.
And now you're the one who started a startup as a software engineer. You founded your startup, which your co-founder so far, how's it going and how is it different to what you've expected, especially that you were on the other side, like you were an early employee inside a startup, you've seen a lot of things. Is it kind of like, you know, exactly as you expected or is it just a different feeling? In some ways I postpone the founding of the company many times, right? In my mind, at least my recollection of early century was like, well, there could have been a path where we didn't do century, but it's something else, right?
And then after almost like four or five years already, I remember like on my first, like when all my shares were, I was like, is there a path where, because I was also a sale, was coming out at one point, but it took next year's and built and had business around, like, hey, is there a path where you could take actually something like Flask and build a thing around it. So in some ways that was like a multi-year preparation for me, so now it doesn't feel like, oh, it's actually different, it's just like, okay, that's an ecological step. Kind of, I wouldn't call them steps, but knowing some decisions made of century, I can now look them from a different perspective. I have different opinions now about equity, about the consequences of equity, how to structure certain things.
Like this time around, basically, I didn't start with here's an idea for a product I want to build. The reason I ended up starting this company with GoFund is like, we actually sat down and said, hey, what do we want a company to be like? Why are we even in here for it? We already know that we're the kind of people that want to start a company, but it's just like, it's not an end to itself, like that something should come out of it, right? And so I didn't do that last time, just rolled into it.
Now you can overthink it, obviously, right? And also, there were many moments over the years of century where I felt like, why I actually would have been great for us to think about some of those things. So now I'm thinking about them in the beginning. The experience primarily puts you there. I don't think you can sort of start out, so I'm going to do this.
Obviously, you can read a bunch of stories of people that started startups and then you listen to the podcast and everything and hopefully get a better sense of it, maybe to some degree overprepared, but having gone through it yourself versus just hearing from someone. I read a lot of stuff about startups even 2015, right? I was addicted to that thing. And still, I feel very different than doing it versus if I would have done it five years ago, just because of my own inner experience of how I feel about all of this, which when I have a level of urgency versus where I just sit it out, the experience puts you in a different position I would have done otherwise. I don't know if it's helpful, but that's mostly how I feel.
Well, I mean, it sounds like you can get all the opinions, read about it, listen to stories, but it'll be different when you do it in the end. It's hard to tell what ways until you do it. Yeah, it works for some people. It wouldn't have worked for me. No amount of reading of anything would have sufficiently prepared me.
Some people might, right? Particularly if you're well educated, like a person grew up with the right values to have this intrinsically put onto you. But that was not my education. My education was just standard schooling, bunch of university. And then there's a whole world that I haven't been exposed to that sort of had to learn in one form or another.
And then just goes with some private questions. So I'll just ask and then you tell me what comes up of the programming languages. Which one is your favorite? And I'm really interested to hear. It's Python and two answers for why.
One, because it gave me a career that I had. And so there's obviously a lot of emotional attachment to it. And also it is a bad programming language for many, many aspects of like, misdesigned and whatever. But it's incredibly pragmatic. And I just like that.
And I kind of want to point towards many of the things that Cal handles and does over the years. He was a CTO at Flickr originally and then Slack. P.H.B.I. Right. But the pragmatism in which he used P.H.B.
was in many ways a pragmatism which I always like building part of Python. And it's like you don't really care if it's good or bad. In that sense, like what you can do with it. And I could do a lot of Python and I appreciate it for this. And then what does it all that you love using and what does it do?
And the answer is not a programmer. A tool I love using is a screwdriver. It's screws. But the reason why I just love it so much, I think it's one of the things that I learned over the years. Like I never really had a good electric screwdriver.
And then when we bought an apartment, I just bought really good tools, including a screwdriver. And it has increased my willingness to drill holes and semi-furniture and everything. And that by far is probably the most favorite thing that I have now. It's just a really, really good, well manufactured screwdriver. I wonder if there's a metaphor there that will apply to developing this wealth.
Like when you have good tools, you're actually a lot more motivated and willing and you're more adventurous as well. Well, thank you for this chat. This was really fun. It was really nice talking about it. One of the most interesting parts about talking with Armin was how he went from being very negative about AI six months ago.
And now he's building a started with AI agents like Cloud Code and OpenAI Code X. I see Armin as a very pragmatic engineer. And if he went through this much of a change after pushing himself to use these tools more, it tells me that it's worth giving AI coding tools some time and see how they work for you. For more observations on AI tooling trends, check out DeepDies in the pragmatic engineer, which are linked in the show notes. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.
Special thank you if you also leave a rating for the show. Thanks and see you in the next one.