I feel like the trick on hard problems is generally to find out how to talk about them. I mostly. I don't think that I'm a particularly good programmer, but I think what I mostly sort of managed to do is sort of find a way to look at the problem on the right level that I don't get stuck in the specifics of it. Hello and welcome to the Pibytes podcast, where we talk about Python Career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Valdebaus. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back everybody, to the Pibytes podcast. This is Bob, and I'm here with Robin and arming. Hey guys, welcome to the show. Hey. And moin. I guess I can say with Amin as well, right? Yeah, I guess it's like South German. It's always servus. Yes. Yeah. Nice to meet you again after the fast API meetup. Was great to see you in person. And now back to online, I guess. Back to online. Yeah, yeah. Nice to meet you as well, Armin, after so seeing so much of your stuff and hearing about you finally getting on a call. Yeah. So for people that might not know you, do you want to do a quick introduction to our audience of who you are and what you do and maybe a win of the week as well? Sure. So my name is amen Ronacha, primarily known, I guess, in the past at least, for building a bunch of python libraries. Probably the most well known once is the templating engine flask microframework, but there were a lot of other libraries along the way. And then a couple of years ago, actually nine years ago, I spent most of my time working on sentry, which is an open source crash reporting tool that now turns into application monitoring in general. And along the same time and also with work, I spent a lot of time actually transitioning over to the rust world. We have quite a bit of rust etcenary. And so then for a couple of years I mostly spent time with this. And then as of recent, I got more interest in Python again. And then maybe about, maybe eight months ago or something like this, I started a new project called RAi, which is sort of a meta package manager for Python. But in the rust ecosystem, I built a whole bunch of little small libraries. That's, I guess, mostly me. My day to day now is basically working on sentry there. I'm basically trying to make sure that all of the efforts that we're having translate somehow with the technology that we're having and just make sure that all of this works well. So, yeah, it's the area that I'm mostly spending time with at century is SDKs and the event processing system. But, yeah, that's, I guess, most of this and the win this week, I think most of my wins are somewhat related to the work that's going on at century. So I think that what made me most happy was just that we started doing the quarterly presentations again for what we're going to do next quarter. And I feel like for the first time in a while, most things are, like, really smooth. Usually there's, like, bumpy things, and now it seems like there's more of an alignment of. Of the different kinds of folks we had. I would say, like, after COVID, quite a bit of struggle getting the different office locations, pulling the same string. So now it's getting better. So that's, I guess, win of the week. Nice. Yeah. And I guess you're already a very big company, right. I don't even know how many employees or developers, let's say. But that's not always easy to align everyone or just have everyone, like, communicate in such a big enterprise. Yeah, we were like, I think, around 400 people when I started. We were free. So it's a pretty big growing thing. But really, all of this, I feel like, got much harder with having little bubbles performed in all the individual offices. I have, I think four of them, maybe five even. Yeah. Getting that part of a company right is tricky. Yeah. Yeah. I mean, I have seen some of these growing pains in my startup where I worked, so that's always challenging how to add, like, this orchestration layer, let's say, but at the same time, not create too much overhead. Right. So that everyone doesn't spend 50% of the time in meetings or so. I had another question, like, to you as a person, which was the GitHub handle Mitsuhiko, do you want to share what it stands for? I didn't find it anywhere. It's originally an IRC handle. Free note is long gone, but that's where it's from. And I picked it because my actual nickname that I used was already registered with Ghost Surf at the time, which, for whatever reason was blackbird, which I don't remember where that one was from, but at the time, and I really am not particularly into japanese culture or anything like that, but at this time, I was reading a manga, which was called Delective Conan, one of the characters was called, yeah, this on this very day. I picked that and it just stuck, I think, for, I don't know, 15 years or something. Nice. Well, it sounds also like manga still up to like, maybe even more now. Again, there are many manga fans, right? So maybe some of, some of the listeners already know it and celebrate it now. Cool. So you are the creator of Flask. Do you still maintain it? May some of our guests ask themselves, and if not, have you been able to successfully hand it over? And what do you envision for flask? I definitely don't maintain it. I haven't been maintaining it for many years. I think at this point, I don't know how many years, but it's a while. And it's mostly because I stepped out of the python ecosystem. And so even when I was still maintaining it, I was trying to throw it under this palettes organization together with all the libraries that sort of make it up, because at that, maybe going back even more time, maybe, I don't know, 2006 or seven, there was a meta organization called Puku, which also had a bunch of other libraries on it, like pygments and sphinx. And I worked together on these libraries with Georg Brandl. I let some of those libraries, he let others, but we kind of supported each other on, on many of those. But then eventually sort of the interest sort of diverged. He did other things than me and sort of, sort of trying to make my web libraries into a separate thing I can give over. So I don't really actively maintain it. And have I been able to successfully hand it over? I think it depends. It's a life, right? It's doing stuff, it's still there. So I think in that sense it's successful. And by the time where I was basically trying to give it a new home, I wasn't particularly engaged with it. This was in parts because I wasn't that interested in python at the time, or at least not to the degree where I felt like, ok, there's something amazing I can do. But on the other hand, it was also because I wasn't 100% convinced anymore myself that the kind of problems that flask is solving were particularly important for the problems that I wanted to solve. So in that sense, I think that it went pretty well overall, but it's a different thing now than what it would look like if I would still be working on it, probably, yeah. So I think it's, especially now these days with AI as well and so on, the advancement with llms, I always like to think sometimes how can we leverage the Internet to create thoughts, put some thoughts out there without necessarily having the responsibility to think them through, but just, okay, here's an idea, a thought, and you present it in the Internet somehow as a tweet or as a repository or so, and then we have this hive mind, right, other people can pick it up, and if several people think it's a good idea, then it may continue to live. And if people say, no, that's not a good idea, then maybe, okay, it was an idea shared or a repository or so, right? And in that sense, I really like your approach of just, you have an idea, you create something, you put it out there, as opposed to like, let's say, the very pessimistic way or the very negative way would be to complain all the time, but not actually create a proposal of how things could be better. Right? So I really like that. Thank you very much on the complaining part. I think the idea is good. I think the problem is like a lot of it, what we are doing as a software development industry is very hype driven, and this has got a lot worse, I think, over the last couple of years where open source turned from something that, I don't know was primarily there to help people build companies. That's sort of how I always saw it, to something where the open source projects themselves almost become into corporate enterprises. So I don't know, like this, there's a lot of time and effort now spent on promotion and marketing and everything around open source, and it's very short lived. So, yeah, I probably come from a time when it's a little bit different, where it's more sort of collaboration. So I don't know if that model kind of works still, but we'll see. Maybe, maybe something like this is a thing I've definitely noticed after the work that I've started on the right package manager, that there was a lot of interest from different people and quite useful conversations came out of it. So the problem is not solved yet. But like, I feel like there's some conversations that are going on now that would. That at least I wouldn't have been part of if I wouldn't have tried it this way. So recently there was some critique. There was an article from Miguel Grinberg shared in PI coders need to talk about flask and this question, I'm not sure how much you can say about it as you're not too active, maybe involved, but I still want to bring it up. So basically there were some complaints that stuff broke with Flask 3.0 I think it started all with a flask login module, but it brings up an interesting point about backward compatibility. Do you have? Yeah, any ideas how, especially with a framework like flask and all these plugins around and how to manage that? I think the problem here is that actually I strongly agree with Miguel here, and in fact, even after I gave over maintenance, I was very vocal about a specific release of Ginger two, which they wanted to rename to just Ginger because they made Ginger two, version three, and I didn't like the three, and I wanted to rename the package and a bunch of stuff. And I basically made the argument that it's just a name and you're just going to break compatibility for no reason. And I think the problem with this is that I am very much, and even at the time when I was maintaining those libraries very much for backwards compatibility, in fact this is, I think, to a large degree why those libraries became popular in the first place is because I spent a lot of time and effort trying to make sure that they don't ever break anything. So I was willing to not do new things just to keep this thing running so that people can build stable and reliable things on top of it. I think that that kind of view is less popular now. It's definitely very unpopular in the Python ecosystem now. I think at this point people are just willing to, I don't know, churn a lot. This is even visible in the core Python interpreter. Like you cannot upgrade even within Python three without stuff breaking, because like imports move around. So there's a lot of this now going on, but I think it's even like, even, I wouldn't say worse. It's different and even faster in the JavaScript ecosystem. What helps in the JavaScript ecosystem is that the input system is better, so you can have incompatible version coexisting and python that just doesn't work. And so you have to reify to like a singular solution in the dependency resolver of one version of the library. And so that means, for instance, that if you've code that cries flask three, and then you've got flask two, it can't coexist, right? They have to sort of move up everything at once, and that's a lot of friction, that's a lot of complexity, and it requires coordination across an ecosystem that requires a really strong community, which flask never really had, and I think it still doesn't have. So I feel like that doesn't really represent how I used to run it, but I also can't really complain because it's not my project anymore. I also never really gave them any sort of suggestions of how I did things in that sense. But I know that there is a lot more interest in making changes rather than making changes in a way where it's Becca's compatible, not how I would do things, not how I wish things would be. But the reality is that that's just how this stuff works now there. Yeah, yeah. And I think it's also interesting, like, if you are not so close to the core development and so on, you may sometimes think that, okay, the core developers and all the creators, they are these gods, like somewhere up there, right? And they know. They have the overview, and there's a clear plan on how things will proceed in the next ten years or something like this. And it's always humbling to me when, for example, you or Sebastian also say, hey, no, actually we just started this project, created something useful based on top of other libraries just to make it more easy to use and so on. And it's kind of like the human condition almost, right? That at some point you notice that, oh, no, the adults, they don't have it figured out. They just have some ideas and some principles guide you through life. And in the same way, maybe that's really important, I think, is that I think there are two approaches which can take one of his sort of this God approach. You know exactly what you want to do. You have everything figured out. And even if we haven't figured it out, you sort of present the lucky half, and it's like you. You go down this entire thing. And I, like, some people are like this every once in a while, maybe even all the time, maybe never. But it's like, it's some sort of sliding scale of this. But then there's also the approach, and that's sort of what, I had the flask for a really long time. Was that, okay, I have a particular problem I want to solve. I was working for companies. I was doing things. I saw their problems. I was hanging out in IRC. I was helping other people. I was trying to figure out, like, what are they doing? And I always took the view of like, okay, let me figure out what they're doing. Let me figure out what I need to do. How do I solve this in a way where I don't break anyone else who already did something before? And that was sort of how flask developed over time, how vexed. I mean, I was like, the goal was like, get more people to use it, solve their problems, and just solve it in a way where rather than solving a particular problem, I'm trying to figure out why do they have this problem in the first place and then sort of solve it with some sort of approach around it, not this particular problem. How do I generalize this problem so that it solves more people? That was basically how I approached this. But I think that the reason I stopped working on flask was also that my problems all of a sudden turned into problems that flask didn't have or didn't want to solve. Like century scale problems are like 5% is web framework, 95% of it is really complicated system architecture. And flask is not there to solve this. It's like the tiny level thing between an HTTP server and the client. That's what it sits there. And so we're not even between the two. It's like it's sitting underneath, but it's just somewhere there to help with routing, HTTP request parsing, shit like this. And so I almost felt like it's done. Like all of a sudden there was this pressure to add like async things. But I already knew from my experience that these async things are really hard. And to run them at scale you need like way more complicated things than I could ever put into flask because they need also castration. You need like routing things, you need like quality of service, back pressure management, all this sort of stuff that just didn't feel like it belongs there. But then there's a world where you say like, okay, all I want to do is maintain some sort of fun open source project. And every once in a while I have this, I have open source project that basically just like, okay, I want to try this. Like what does it do? And the problem is like when you do that in isolation and you don't do it with like an actual real problem to solve, it sort of takes on a life on its own, and that life on its own then eventually actually results in like, well, this is a nice little thing, but doesn't actually solve anyone's real world problem. It's like art almost, right? To some degree. What happens every once in a while with projects, it's almost like art, right? It's something creative, something, something that is nice, that has some beauty to it and some form, elegant or so let's say because it's doing something, but then maybe doesn't have a use case yet, right? We don't know, maybe later on when things change, it could be reusable again or so. Yeah. So basically coming to the century maybe also, we heard it also in one of the last podcast episodes where David said that sentry is heavily investing in open source developers, contributing. And it would be great if more companies would do that because then I guess at least the value or the variable, that there's not enough funding or so that you can create the space that the open source developers really work on what they would like to work on. But even then you mentioned that just your problems, the things that you wanted to work on, changed so the same thing could happen with current developers, I guess, lead developers of current important open source projects, be they small or big. Right? We always, we all know this graph where like the whole tech stack depends on this one small dependency that only one person knows how it works, actually. Yeah. So basically. So two things, I guess. On the one side, the funding that the people can just work on what they want to work on, but even then the things they want to work on may change. So setting up some form of principles or. So what were the ideas, how the package was developed that guided the development so that people that pick it up can, can take up on it. So like Sanjay does a bunch on the funding side now, and I'm super happy that we do this. I think, like independently of that, nobody has really figured out how to make open source sustainable. Like, even if you put money into it because of the second problem, which is like maybe someone just no longer cares about it, maybe the package sort of transitions to someone else. So I might actually use this year, maybe next year to write down some of my learnings from open source maintenance and maybe failures. So maybe something comes out of it. But you're right, it's really hard to address this as a whole. And I think the biggest, I wouldn't say my biggest disappointment, but what I don't like about where the open source ecosystem has been going, at least for some time, has been that open source project turned from something where people collaborated on specific problems to it's almost like a stepping stone into a commercial thing on the project itself, which is not necessarily bad. It's one way to fund it, but it also means that you very quickly end up with incentives that are against your users. You might build this one library, which is really great, but it's actually just like the advertisement vehicle for your cloud service. So, yeah, that's tricky. And one of the reasons why I actually didn't want to make flask in something more than just the framework was actually this like, century is an open source project. It's very easy to commercialize it's a SaaS business, like the incentives are with the user. We can provide it as an open source library. Every service, everybody can host it, every can do what they want, but they can also probably run it cheaper through our infrastructure. It's like that. We don't have to do anything that's not in the interest of the customer. The library is a trickier. As an example, I think that Vercel does a really good job at maintaining next JS as an example. But I think Vercel also sometimes prioritizes the Vercel deployment over someone else's deployment. Right. So there are things next that probably would look like next book look very different if a cell didn't exist as a hosting platform. And it's just one of many examples. So I think it's really hard to do this, and maybe we need to figure this out as a community as a whole, how to improve this other. Maybe just one last question before Bob jumps to the next one. Are there other open source, yeah, startups, let's say, or packages where you think currently is still working great. As an example of combining both open source and the business, where the incentives are aligned, I must say that I'm not paying that much attention to a lot of things. I'm not out there browsing the Internet trying to figure out what are the greatest open source startups. I'm generally quite interested in some technologies where they're going, and obviously some of them is click house. Like we use this thing. They have commercial offering now. It's also an open source database engine. Historically, commercializing open source database engines has been pretty complicated. So I'm curious where this will land. So far they didn't screw it up, but I was on high alert. Maybe they will. It's just really hard. And I think it doesn't matter if you like, even if I say I have this perfect example right now, it could still be that they changed direction and it wasn't actually successful, and then all of a sudden it ends up not being a viable project. Yes. Other examples that come to my mind would be, I mean, pydentic, right. We don't know yet exactly what the commercial offering will look like and how it's aligned with open source, but that's of course one to observe and the other one is prefect. We recently worked on. So for workflow orchestration. And they have at least the open source part, right. I didn't actually use it yet because for my project it was always nice to just have the prefect class out. And I don't need to take care of that. So I cannot evaluate how much that really also fulfills the open source idea, let's say. But, yeah, otherwise, definitely. Either way, interesting to watch the space and also talk about it as a community. And I always have to preface century technically, a lot of the code is technically not open source because we have this, whatever you want to call it, like a license with an exclusivity period where, like, you cannot be in direct competition with Sentry to use the latest code. But we do roll everything over into Apigee two. Like, 95% of sentry is fully open source, and Apache two with patent runs, so it's not insignificant. Nice. Cool. I want to talk a bit about your use of rust. So coming from Python and, yeah, people as well, the audience probably new to rust. I mean, we had one episode where we had Jim Hodap on and we talked a bit, a little bit about rust. But in your experience using rust in your projects, how's that going? How's it different from Python? What do you like about it? You also mentioned at the start that you did go back a little bit to Python. So, yeah. How do those two languages compare for you? And also, I'm curious at your level, how do you learn new technologies and how do you get unstuck? For example, you mentioned Rai, right, the package manager. That must have been a pretty, well, a very complex effort. So I'm also interested, how do you tackle that, like, the challenges there? Maybe I'm on the rust part first. Many questions, sorry. Yeah, so it's very different than Python, and that's very obvious for many different ways, but it also is surprisingly popular in the Python ecosystem. And I don't want, like, overstate my position here, like, as being so influenced on this, but I know that a lot of people reached out over the years and said, like, hey, like, your success of using rust sentry sort of got me interested in it. So I think that to some degree, at least, some of the early adopters in the Python community for rust probably played a role. Why it had some success in that space. For me, I think there's a, there's an interesting parallel between Python and rust. Python has a very specific kind of behavior at runtime that many other languages don't have, which is it relies most in the reference counting system. So the garbage collector really plays a subordinate role. There are some companies that even run Python exclusively without the garbage collector, which means that memory consumption is kind of fairly predictable. Like, you don't have this massive, like, all of a sudden the garbage collector gets rid of everything. And you also don't have a chit, at least at the moment, you don't have a chit, which also means that the performance of Python is sort of stable over time, most of the time, and they're not this crazy pattern set destroy your performance overall. And rust is kind of the same, which is that if you write rust code, operating rust code is a little bit like operating Python code, like there's no JVM parameters to tweak or stuff like this, because both of those systems independently use reference counting. It's very trivial to have extensions, modules written for Python from Rust. And that's, I think, how a lot of this happened. We of course did it. There's now a library called PI zero three. There's a system called Maturin that helps you building it. And I think that PI zero three in particular is just a brilliant library that makes it shockingly easy to actually build mostly safe, I would say, extension modules for Python. And it has some success to show. And so I think that's sort of a reason why for Python programmer rust is interesting, because it can build high performance code in rust and then sort of expose it to Python, but they also bridgeable on a very nice level. You can change objects between the tool, exchange objects within the tool, and you can sort of do a lot of concurrency on either one of those sites if you want to, because you are in full control of the chill from a developer experience, it's really hard comparison to Python because compile times, the border checker really is a thing that you have to get used to. It's, I would say, not overall the most productive language. It has a learning curve, but it feels very rewarding. I think once you're past this onboarding experience, which is really weird, and this rethinking of how to program with it is actually really enjoyable. And this is because it does some things really well, like the package manager, like the trade system, just generally the helpfulness of the autocomplete, of the IDE integrations. The documentation is just amazing. And I mean this in not just the sense of like the Rust developers wrote a lot of documentation, it means also that the entire ecosystem writes a lot of documentation, because the documentation tool is built in and sort of normalizes writing documentation. I gave this example recently in a talk that the same programmer at Sentry will write documentation for rust code, and if they write Python code, they will not. And it's mostly because the Python code never really shows the documentation anyway, it just sort of goes into the abyss. It's not entirely true because it's a little bit of ide autocomplete that sort of maybe resurfaces every once in a while, but you never have this nice pages to look at and see what documentation wrote. So there's a lot to the developer experience in rust that's really good. That sort of makes up its hard learning curve and everything. Yeah. And so I think that's how we picked it up. I gave a bunch of talks of how it actually happened at the end of the day, but it works really well. I don't think we regret it. I also think that maybe if we would have picked a different language, we would have been fine too. Right. But it worked for us. And now that I know how to. I don't train developers and hire developers that like programming in rust. It seems like a pretty good choice for a lot of companies. And obviously if you're working in Python, it's a natural second language because of the extension system and for getting unstuck. Rally is not that complicated. So I think that's not a very good example because Rai doesn't actually really implement the package manager, it just implements a shim around other people's tools. I think that the, I feel like the trick on hard problems is generally to find out how to talk about them. Mostly I don't think that I'm a particularly good programmer, but I think what I mostly sort of managed to do is sort of find a way to look at the problem on the right level, that I don't get stuck in the specifics of it. And so I think a good way, like if you have a hard problem is like trying to figure out how to explain this problem to someone else. Maybe you're solving the wrong problem to begin with. And really the main way in which people get stuck is actually just lack of motivation. And so most of the projects that I started over the years, they didn't actually make it even to being a public GitHub profile because I just started, did a bunch of stuff and I felt like now I don't care anymore. And it's just, rather than like leaving it as a public repository, I just, it's just in my growing list of stuff I don't want to even show anyone. But yeah, there's a lot of this. If you don't have the motivation to do something, then it's really hard. Ever bought a course and saw zero results? I've definitely been there. There are very great courses and materials out there. But if you don't implement, nothing will change. But with Pyrites developer mindset coaching, it's a whole new game. In just twelve weeks, you transform from a Python intermediate to a pro. How? Through one on one coaching, building real applications and mastering advanced python techniques. Our hands on approach isn't just about learning, it's about doing and achieving. Get certified, push your career and join an empowering community. Apply for the Pibytes PDM program now. Check out the link in the description below. Yeah, that perfectly also fits to our coaching program. Right. So in our coaching program we basically ask our clients or prospectors at that stage, which projects do you want to realize, like do you want to build an app? Maybe you even have a business idea or so, which you want to just create. And then we will help you find the different solutions. Because I mean, there's so much stuff you need to learn, right? Or you maybe need to learn going all the way from infrastructure as code. Also, if you want to host some cloud infrastructure to run the stuff on at the first point over python development, the different packages that maybe make it easier to start and then yeah, just also creating the front end with it, maybe either in Python also, or even taking another language on top of it. So coming to that, of course on the one side you can get a coach with piboids to help you guide on that track, let's say. But how did you manage to create these bigger open source projects, like Flask for example, or what would be things that you would recommend new developers or developers in general? Is it really just okay, have a good vision and then focus on it? Or are there some things that you could add on top of it? Always need to have a purpose. As an example, for most of my open source projects, they didn't actually become open source projects because I felt like I want to create an open source project that was actually like, that was never really the idea, never did I start, I want to write an open source project because I want that open source project. It was like, I want to know how to write an interpreter. So I wrote a template engine because that was a pretty good start. I wanted to know how HTTP worked. So I wrote backstage. It wasn't really a thing of like, hey, I want to build this entry. So I want to understand how it works. And the reason I want to understand how it works is because I was generally, I felt like I enjoyed the feedback loop of creating a small application or something and being able to get other people to use it. That was for me was the motivation. And so I knew that in order to get better at this, I need to learn this. And so open source was my way to do it. It was my way to connect to people, trying to figure out how this works. And the end result was always clear. I want to get into a way of doing this professionally. So I think that this, to some degree, is like, it's very hard for me to answer, like, how do you make a successful open source project? Because it was never really the goal, and to some degree it was sort of accidental that it happened, and it was in some ways also annoying that it happened because all of a sudden I needed to keep it alive even beyond my motivation of working with it. Right. So, like, for this reason, like, I actually think that open source makes it even harder because most of the time the end goal is actually make money. Right? That's. I mean, I'm very capitalistic in nature despite me making open source projects. I like making money, and so I want to have a way where I wake up in the morning and I know how to make money and I know how to invest my time into making money. Right. And so for that reason, I find it conceptually easier to work on a commercial thing than to work in open source libraries, where it's always so weird. So, yeah, I don't know. It's, I think the mindset, I can explain you for how to, like, build a commercial thing, it's much harder for me to argue, like, how do you do open source stuff? Because to some degree, I don't actually know. Yeah, that's very honest. And maybe also going into the emotional part, because you just mentioned that sometimes it could be frustration or we even may feel like, ashamed that we don't think the project is good enough yet to really show it to other people. That's something we hear all the time from our clients. Like, it's not good enough yet to bring it out. And so that's maybe something we could also appreciate more as a community, right? Just celebrate that an idea was put out there and not like, look at the code and be like, oh, that's so ugly, and whatever. I think it's already, I mean, sometimes it's already good in open source space, but sometimes I also, there are still prs maybe where the feedback is not so nice. When you're a beginner and just trying to contribute for the first time, there are many spaces where the feedback is really fine. As a beginner, you're fine. Nobody cares. I think that at one point, this is maybe a little bit of problem of some sort of weirdest popularity in certain spaces is that people start judging you as a person overall. Right. And so that all of a sudden means that, like, okay, people subscribe to get a page and they look at stuff, and maybe they don't look, but, like, whenever I make a new roster, like, within, like, a couple of minutes, like, there are a bunch of stars on it and people that sort of marked it. And so I think at one point. Yeah. Also, like, I feel a lot less free now in tweeting things than I did, like, I don't know, ten years ago. Right. So I think that is sort of a little bit of the problem. Like, if you're, like, that should not be something that you think about when you are, I don't know, just starting out. Like, if anything, you want harsh feedback, and this is. This is really important. Right. So that's something that our clients often ask, okay, when do I come to the point where I don't have imposter syndrome anymore? When do I come to the point that I am confident? Right. When do I like what Sebastian said? Now in the fast ipa follow up meeting. Yeah. This next level, there's always the next level, kind of. So the more you learn, the more you know what you don't know. So I guess it's somehow just to learn how to feel, be comfortable with these kind of feelings. And then as a community, we can maybe help to reduce, like, this shaming that is maybe going on or that we just imagine that is going on. That is actually not really going on. Yeah, sorry, go ahead. Does imposter syndrome ever go away? I think the goal has to be that it doesn't. And I was actually. I was listening to a podcast with Jimmy Kimmel recently where he brought us up where he felt like he wants to feel this again because he feels too comfortable in what he's doing. And I think that feeling confident about the things that you're doing is good on, like, the base level part, but, like, it doesn't really. Like, in some sense, it means, like, now you're not trying to do any new things anymore. Right. I guess, like, the way you would describe impostor syndrome is that, well, you feel like you're. You're doing something that you're not qualified to do, and I feel like that should always be the goal, in a way. Right. Because it means that you're now doing something they haven't done before. Right. So ideally, it never goes away. Yeah, that's a. Right mindset shift. Yeah, mic drop. I love that because a lot of people avoid it. Right? And if you keep it like, it's actually a good thing because it means I'm growing, I'm moving outside of my comfort zone. That's what you want, right? And I stopped doing that. Maybe I should do it again. But I started reading my own blog posts from many years before. It's even worse than hearing your talks because, like, to some degree, when you write an article, you write with confidence, and then you read about it years later. And, like, I'm thinking different about this now. Right. But if you write stuff down or, like, leave evidence of the things that you, before, you can sort of reevaluate. And ideally you actually turn out that you have grown as a person a little bit, at least, and you see things in a different light now, or, like, in a more nuanced version. That's a perfect introduction, because I listened to two of your podcasts, like one from 20 21 from earlier this year as a preparation. And two years ago you said, yeah, Python is in a bit of a difficult space, and data science is totally fine, but for different other things, maybe Python should be reinventing itself. And you said typing is way too slow. I guess with rough. Now that's better. Finally, the typing goes very fast, and in general, the typing is maybe in Python not yet at a good space because we could have just inspired ourselves more from typescript. And. Yeah, so that was some frustration or disappointment. So how do you think about those things now, as you just mentioned? So a meta point on this is that there was a time where I was very critical and python free, and people kept referencing blog posts that I made on Python three, even after they fixed all of those things. So this, I think, is an important part. The world changes. Right? And so some criticism that I might have had on certain things are now different than what they were originally. I still feel like typing in Python doesn't really work for me, and it's now it's for different. I think, like, in the year 2023, it's different than, like, maybe in 2020, but different. I think it got better, but I still don't really feel like I get value out of it. And it's because of the way I write it. The way I write rust is I write this thing and types come naturally and type give me types. Types give me value immediately. Typescript is similar, although on typescript I also feel like, well, because the transpilation step is really slow, it doesn't quite give me the same value. But I do feel like I still get value out of it because autocomplete works all of this perfect id integration. The type checker seems fine. The type system is generally really, really powerful. I usually don't have to import anything to get types. It works in Python the way I actually write it, which is not how you should be writing it, is I write the code first and I type it later. Why do I do it? Because my id integration doesn't work. If I start typing it right away, it probably doesn't work. I don't use whatever the jetbrains thing is. I use versus code, which has highlights, which is just close to useless. So that's problem number one. I think the ide integration is not good enough for me to enjoy this. The second one is python as an ecosystem doesn't have adopted standards for typing. And so in century, for instance, I run into this every once in a while where code style in library a is different, code style in library b. It's very hard to transpand code from one place to another place, because all of a sudden the typing usage is different. What you use from typing extensions, import whatever the hell. And then in the other one it's like union, and then it again uses like optional, like the. There are too many different styles, there are different ways in which you can annotate things. A lot of it feels completely non natural. So it hasn't fully reached a point yet. I think it could, but it would probably. I think what the problem is for Python to some degree, is that a lot of those things are not fully embraced by the core. I feel this is the same with packaging. It's like there is, there's some stuff that happens in the core language, but a lot of it comes from the community. So my PI is an add on the pylens thing that actually only works for versus code because technically closed source is again only an external thing right there. It's not the Python language server, like it is for rust, or there is for whatever ban or whatever language there is. Python doesn't have this. It has like the core language. There's a bunch of stuff can install pip, which is a third party library, which technically is part of PSF somehow. But I'm really not of the core team, and so typing is in the same spot. Yeah, I feel like if this would all come together as one thing, it would be a much better experience. But today it feels, it just like, doesn't make me happy. I think this is the problem, and because I've just been programming Python for so many years, I feel like it's standing in my way. Maybe if I would start out Python now, I would feel different about it. It just comes down to it doesn't make me happy still, and I hope it will eventually. I hope it will get to the point where it's really good and it's much better now than it was three years ago, but still. Still not quite there. Nice typing question check. I was actually curious about that, so I'm glad that you elaborated on that one. So, yeah, I think we're coming up time. So, Robin, did you have any other question, or shall we move into the books, or maybe ask about a final CTA for our audience, aspiring developers? Yeah, I guess the legacy part, maybe what you had also on the list. Yeah. And if you think about Python, or just in development in general, or your life also in general, I would say, already having contributed so much with flask, you could already say, oh, I'm already good. You know, I've done a lot for the world, let's say retire. But is there something that you have, like, now as a target or. Yeah, in terms of legacy, I don't think I've ever thought about, like, what should my legacy be in life? Because feel like that's not why I'm here. I can tell you what it shouldn't be. It probably shouldn't be like any of my open source libraries. I think I would love to have created something at one point that sort of survives me for a little bit longer. I don't know if that's going to be an open source project. Hard to say. I mean, obviously I have kids, so that's, I think a legacy that should outlast me, hopefully. But I think that the honest answer is that I spent so much time and effort on sentry the last couple of years, I probably want that to be more of my legacy than my open source types are, because the kind of engagement that you have on a company that you work with, with customers, is a very different one than open source. It's a very transactional relationship, but it's also a very nice one, and I feel quite a lot of pride in having brought it where it is today. So I feel like that's probably more than my open source contributions. Nice. And I think the fact that you, who probably have all the opportunities and options and so on, stays, along with sentry, also speak for century, that they create a good environment to do exactly the things that you talked about in the podcast. I mean, I'm probably a little bit in a privileged position here, but, yeah, no, I think we are, like, there are many versions of us that didn't make it to this point, and I'm quite happy that we have generally assembled a pretty good environment here. Cool. So our last question, as always. What are you reading? Do you have any book recommendations? I don't know book recommendations, but I started rereading the coddling of the american mind recently, which is a book which it's hard to explain, and I'm not american, but I think it still relates quite a bit to contemporary way in which we are dealing with human society. I guess it's from Jonathan Haidt. It's a very interesting book. I don't know if you subscribe fully to the things that are shared in it, but definitely worth reading, I think. Nice. Awesome. Maybe one last question would be how it relates to the current humanity, let's say, if you want to share. Yeah, I mean, I think so. One of the observations that I made is that when you have a community, let's say rust community, python community, something, it doesn't matter. The sign of success of such a community is that it grows. Right? It becomes bigger than it was ever. And the challenge of this is that all of a sudden means that you have people in there that don't actually share everything. Right? They might have fundamentally different opinions about political topics. They might have fundamentally different opinions about, I don't know, like, the basics in life. Maybe they just live in different countries, speak different languages, they grow up with different things. And communities tend to over assimilate in a certain way. But the way this sort of goes is by not talking about the contentious things, right? So because the act of discussion, in a sense, by some communities is then harmful in itself. Right. It becomes triggering to discuss these sort of topics where actually disagreement happens because it might offend someone or something of that. And I think this is like, particularly like, the reason I'm rereading this actually has to do with. With what's happening with Israel and Gaza at the moment, because a lot of. A lot of. A lot of communities all of a sudden pick one of those two sides, which is weird because they shouldn't have a consistent opinion in the first place. And I wanted to reread about some of the things that I remember from the book, particularly about some of the committees performing on us universities, because some of them are not showing up again as picking one of those sites. And I don't actually. I'm impressed that they managed to have such a consistent view on which site to pick, but it's like, it's a very fascinating book to read. Quick question. I mean, do you have a follow up? Do you have a hard cut? Because otherwise we are already wrapping up, kind of, but just wanted to check in. No. Okay. Yeah. Because I also totally agree with that. It's tough. And it's also tough, like wondering, okay, should I openly discussed about it, right. Take part in this discussion so that it becomes a bit more empathic and so on? Or should I just not say much because I don't know a lot much about the topic. Right. This is always the question. And I think at least with the python code is something that, and the open source community in general and code programming in general, it's not so political, right. So you can have these kind of discussions, and maybe we can also have, like, maybe we can create some models, right. With the way that code is written, ideas are exchanged, requests are made. I think the problem to a large degree is that there's right and wrong, in a sense, about certain things, and there's some sort of like the way in which you should be doing it, because if you don't do it, sort of, you're doing something that's against something that someone else is doing. Right. And I think that this is, the trickiness of human interaction is not solved just because you're talking about good. Because there are things that you can be doing that harms another person in a real way. And maybe, you know, maybe you don't. Right. And I think it's actually incredibly easy on an issue tracker to upset another person and you don't even know it. Right? Or you say like a remark that one other person feels in a certain way, but you don't actually realize it this way. Humans are complicated, and I think they are much more complicated than computers are. If anything, we probably should spend more time figuring out how to make that work, like how to de escalate, how to solve conflicts, but in a way where we can actually discuss our disagreements and not just they don't exist or pretend that we have solved, we have some sort of agreement and one side is more correct than the other. It's really hard and it's hard and. Open source tool. Yeah. That's what we often find right. In pivot, it's. The tech has challenges, but the biggest challenges is the soft skills, the people interaction, written communication. When you're not face to face, as you say on an issue tracker, it's easy to not convey the real opinion or to say something wrong? I had this discussion recently in a conference where a friend of mine said, like, a more nuanced in person, but I think that this is true for everybody. Like, they on Twitter, like, you have now, you have 280 characters to, like, vent your frustration. But when you talk in person to another human being, it's very rare that I upset someone because, like, I can, I can judge what the other person says. Like, oh, like what I just said, like, you made a reaction here that made me realize that this is probably wrong or something like this, and they can sort of engage with this. But if you just write a tweet, then it's like, okay, someone's going to read this and then interpret in a certain way and you don't have no idea what happened. And issue track is even worse because very often the engagement that you have in issue track is already starting on a level of disappointment. Shit doesn't work. So it's already elevated emotions, and then maybe you didn't respond in time or something like this. So it's like the, the stakes are higher on initiatives, the emotions are higher on issues record. And, and so I feel like the, with sort of GitHub turn into some sort of social network. The, the quality of the discourse is also, has changed. It's not worse. I think it's actually quite impressive that didn't get worse, but it's, it has many more people on it with different levels of skill and of like tenure or whatever you want to call it. It's very, very hard now, I think. Interesting. This could be a whole another podcast episode complexity of this all. But yeah, Armin, thanks for sharing. This has been fascinating. Thanks for hopping on. I forgot to say at the start that Julian was really bummed that he couldn't make it. The other co founder of Pibatch, because he's a big flask fan, like forever. He even did a course on it, so, you know, he's in Australia, so. And the clock just changed, so that wasn't going to happen. Thanks so much. Yeah, Robin, anything else from you? No? Good. Thanks so much, Amin, for being here. And also, yeah. For having the courage to sometimes give an opinion that maybe Harden and maybe hard feedback, let's say. But I think, like you mentioned, we really need this thoughtful disagreement and in an empathic way, ideally. And, yeah, so thanks for doing that and thanks for all you do, I would say, indeed, thanks for all you do. Cool. Bye bye. Cheers. We hope you enjoyed this episode. To hear more from us, go to Pibyte friends. That is Pibit es friends and receive a free gift just for being a friend of the show. And to join our thriving community of python programmers, go to Pibytes community. That's pibit es forward slash community. We hope to see you there and catch you in the next episode.