I think the learning process of getting the issue, reading, and the simple thing of doing that every day, every time, I think that was the most helpful thing. After those years, the thing that I still do more than coding is actually on open source, is actually going through this reading process, taking a decision, answering. Hello, and welcome to the PY Bytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. 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. Hello and welcome back, everybody, to the Pywytes podcast. This is Bob Baldwell. I'm here with Robin Beer and Marcelo Trelisinski. Marcelo, welcome. How are you doing? Thank you, man. Hey, I'm doing good. How about you? Yeah, good. We're excited to talk this week with you. Well, this week when we record it, so come out a little later, but, yeah, it's a bit of an intro. I know you're big in the open source space. You're an expert in fast API, maintaining uv corn and starlet working at pydentic these days as well. Of course, you can do the best intro. So, do you want to introduce yourself to the audience? And also, do you have a win of the week? The what of the week? A win of the week. Something you achieved this week, something you want to share? Ah. Yesterday was my birthday, so I achieved one more year. Happy birthday. Take it. That's a win. Yeah, yeah. So, I'm Marcelo. I'm from Brazil. I'm currently living in the Netherlands, in Utrecht. Yeah, I spent a lot of time on open source, fast API, starlet, youth corn, and, yeah, as I said, I'm currently working at pedantic. Yeah, I'm around all those new kind of technology stuff. That's pretty much what I do. Yeah. Maybe going to the next question, or should we also share our wins, Bob? Oh, you can share a win if you want. I would just say I survived. COVID, again, a good reminder that when you're healthy, you want a thousand things, right? And then when you're sick, you just want to get healthy again. So, yeah, make sure that you maybe take a mask or whatever in public spaces if you want to avoid it. It's going around again these days and. Yeah, but also good reminder to just sleep enough and so on, so you get a good immune system and stay productive. So, yeah, basically you're now official fast API expert. How have you become the fast API expert. And yeah, maybe tell us a little bit about the process of helping people in issues, becoming knowledgeable about the framework and what you want to share about it. Yeah, so actually, what do you mean by official? I would say in the fast API method, where we also met. Right, you honored to present, let's say, the part about how to maintain discussions and so on. And Sebastian said that you're the fast API expert, so that's easy. Yeah. So actually it started in right before the corona thing. So it was 2020, I had just arrived in France and so we were working on some services and I was in charge of creating the new one, because I was actually the first one in a team that would grow at the time, like the idea was to grow the team, but actually they put me alone and I did the whole setup, so. But the thing is, my boss at the time, he asked me which framework we should be using. So like do that for the, for the next one. And he said, choose between Flask and Django. And I had just left university, so I wanted to do everything right. You know, I was super excited. And then I created this table with pros and cons, and I put flask, Django and Fastapi. Then I remember that at the time we were having some problems with. So we are using flask on a previous service and we had to do the validation of the data all the time inside the body of the endpoint function. I remember that. That bothered me. So when I found out that Fastapi had that, I proposed that. And there were other stuff that also re nice, like the swagger and that stuff, auto completion on everything, very type, blah blah blah blah. But at the time, what really interested me, the most important feature it was the data validation part. Well, that's how I started. And then, so I introduced this to the team and then I felt kind of like I needed to know the framework because people were starting to complain and stuff. So I needed to, I felt that I had to have this role of understanding a bit more about the framework. And then I start just replying the GitHub issues and it was also corona, right. So I was every morning just checking the GitHub issues and trying to reply. So it was more a process of understanding what the question was, because I didn't get it. So understanding that and then trying to find an answer. I remember that at a time it was very common to just see, like instead of looking for fast API, I just looked for flask or something like usually it was flask, and then I found something similar that I could just do. Say like this is how you're doing Fastapi or something like that, because at the time it was 10,000 GitHub stars for Fastapi. Nowadays it's like 67 or something like that. So now it's far more. What else did you ask me? Yeah, that's great. Yeah, good. I think nicely listen to the other question we had. I guess at that time you were already doing Python for a while, but still your approach to. Because learning frameworks can be pretty challenging and fast. API was younger, but it was already built on pydentic and starlet, so there was already a fair bit of complexity. Then you also went on to maintain other libraries. So my question is, you already said you were doing issues and kind of a support going, working backwards from these, these issues that came up. And so did you really learn the framework like inside out, just by ad hoc issue solving and just, you know, seeing the framework from different angles? Or is there also a more structural approach, how you got up to speed with that? There was no structured approach. It was more about. So what I did was not, for me it was never about, you know, when people come and ask how do you, or how do you start on open source and stuff like that. For me, I was never planning to do anything like that. I just wanted to, like for me it was the challenge, kind of. I was learning a lot from the process that I just said, like reading, trying to find an answer and then coming to an answer. That that process all the time helped me a lot. And then sometimes I need to go to the code source to check something and then all the time checking, getting to the source code, but also the process of becoming a maintainer took a bit of time. It was not that fast. So I started with Fastapi in I think April or May 2020. And then at the end of that year I opened, I think, my first request on Youfcorn. I opened the first request on Fastapi in July, I think. So it took some three months, something like that, but I didn't open that many in Fastapi. It was more about replying the issues. And at the end of the year, in December I opened my first request on Youthcorn. And the next month what I did was I created an issue on youthcorn to fully type hint the package, because it was not to solve. To fully close that issue took two years. It was a slow process, but mainly because I did something and then we needed someone to review it. So that took a bit of time we did an approach that we could do it incrementally. So on this issue, I created the list of the files, and then we went through each of them and then took some time. I became a maintainer of youthcorn in I think may or some point in 2021. So almost a year after a bit less than a year, then I started helping on Fastapi. Nice. And yeah, basically that means that for the different frameworks that you are now also a maintainer of, just to conclude that you started by looking into the discussions, trying to answer the explanations, and then sometimes you would find something that isn't answerable or so, and therefore a new issue is created, like a new feature request or so, or maybe a bug, and then a bug issue is created. Right. And just starting to contribute at that point. Actually, I think when I started GitHub, discussions were not yet there. Ah, yeah, good point. Yeah. On fastapi there was a huge list of issues and. Yeah, well, at the beginning, I think when I started, there's just 100, and then over the years it went to, I think, 1000 or something like that, close to a thousand. And then what Sebastian, the creator of first API, what he did was to move most of them to discussions. Yeah. But it was a process of reading. It was doing the same thing every day. Most of people, I think might find boring. For me it became a habit because, well, it was again locked down. So I wake up, I checked the issues, and then I did that first time, you know, the notification of GitHub. Yeah, mine. Now you're going to see, I don't know, ten top, because I clean that up every time. So I'm always refreshing that page. Not sure if I'm addicted to that, but I do check that, quite frankly, people check WhatsApp, I check what's up and GitHub. So that's how nice, I mean, so for you it might also be have been overwhelming at the start, right. But just, it's almost like the issues get you that deliberate practice to go in and every day do that, do that, stretch and push. Right? Yeah. I mean, in the beginning took more time. Right, so you have nowadays. Yeah, in the beginning was like, I really didn't know the answer, I did. Well, it was honestly, I didn't know the question as well, so it took a bit of time. It was not that trivial. Also, the amount of issues like the amount of in and answer like the, it was not the same as nowadays. Nowadays you have far more that come in and, but the good thing about it is that nowadays I can just look at the first sentence and I already know if I can answer already. Can I close or if I need a bit more time? Because again, I continue doing this over the years. So I already know if the issue is repeated. I already know what's the answer and something like that. Nice. So basically, building on top of your open source work, how did it help you get to the current job you have at Pydentech or how was in general, this whole journey? Well, actually, I think what's more interesting than that? Well, I think people. I don't know. I think what's more interesting actually is. So I moved to the Netherlands, but with a job, and on that job, things already start to change. It was. I moved here in February last year. No, sorry, February 2022. So two years in the Netherlands already. And when I moved, it was already. So, you know, when you have this normal process of interview process that people have the lead code at that time, things kind of start to change, I guess, because of the open source. So it was more about. I think I felt that it was really more about finding a match for me than proving that I knew this stuff that I was supposed to know because I was already a maintainer of those packages. And. Well, what I'm saying is that after that job, I got another job, and then I got into pydentic. But the way I got into pedantic was just because I was already involved in the technologies, I guess. And then I saw the role. And then I talked to Sebastian first, and then. But I think I applied first, then I talked to Sebastian, and then I talked to Samuel. The theater of pedantic. Then we have another. I had another interview with David Montague, which is also in pedantic. Best developer I know. And then. Yeah, and then I got in. It was like that. Yeah. Really inspiring. And a good reminder for our audience as well. Right? Like audience are python developers and they want to grow and lending type of jobs. And your story is really inspiring that you didn't plan it, but just organically, by doing all these contributions and having a name on this project, it became much, relatively easy. Yeah, I think it was important on this whole thing is, I think the learning process of the. The getting the issue, reading and the simple thing of doing that every day, every time. I think that that was the most helpful thing. Because actually, after those years, the thing that I still do more than coding is actually on open source, is actually going through this reading process, taking a decision, answering. It's the thing that gets most of my time on open source. Interesting. Yeah. So not only the coding, but the whole process around it of reading, problem solving, understanding, communication, I guess. Yeah. Yeah. Cool. So, yeah, if you want me to talk a little bit about pydentic, what you're doing now there, and what's coming, as far as you can reveal. And what are you most excited about? Not sure how much I can talk. Yeah. Yeah. We're gonna travel. We're gonna have Samuel as a guest at some point in the future. So I guess we dropped the big bombs, but. Yeah. Okay. I'm just going to say the details, but it's also coming very soon. Not sure how soon I can say, but it's coming very soon. We're going to have the release of our product soon, and it's. I think I can say that it's an observability tool, but I'm not sure how much more I can say. I'm really excited about it. Yeah, I mean, I really not sure how much I can say about it. So, can you tell us something about what you're working on in this part? Like what you're working on? Yeah, well, if I'm being completely specific right now, I'm working on the documentation and improving the integration with different tools. Okay. Okay. Yeah. So maybe we do a second meeting, a follow up where you can go in more detail after the release. Okay, that's good. Next one would be. There should be one and only one obvious way. I guess you know this sentence from the Zen of Python. And the question, of course, is an open source, especially like, as an open source maintainer, also an important libraries, how do you ensure that there's only one way? And is there maybe a phase where there are not only one way, maybe several ways, but at some point, you need to consolidate. So how do you do this when you have a package like Fastapi or Uvicon and so on, which is used by so many users. So I think those packages, they also have different governance or something. Is that the word in English, like different. Governance. Governance. Governance, yeah. Governance, yes. Thank you. So, fast API has Sebastian, which has different ideas than what we have in encode, for example. Encode is the organization that has starlet and youth corn. So the creator, Thoron Christie, he set kind of a set of ideas around the organization. So what I always try to follow is his ideas, even if he's not that much active on you, of course, installed. He's still on HTPX, and his ideas are more like. So I'm saying this because his ideas were always more like, if does it need to be in the package? If it can be a third party package, then let's try that way first. If it gets popular, we include to the library itself. So I think this is important for your question, because it's always a question. Well, most of the time it was always the question of, should we get this pull request in, or is it too complicated, or should we try elsewhere first? So I think on starlet and you've coin was always the case that we tried. Well, sometimes we forget about this. Sometimes we just think a feature is nice and included. But usually, well, if simple, usually gets in. If not too complicated, people don't. But usually it was the case that we put to a third party because also starlet works in a way that you have blocks that you can interact together. So it doesn't need to be on stylus itself. Everything can be a third party package. With Youthcorn, you also have that case, but there are not many packages that interact with you of corn. But you have like, for example, you can create the HTTP protocol that you want and put it on Youthcoin if you want, like the implementation of the protocol. You can do that. You can do a lot of stuff. It's just that maybe my fault by now that you don't have that very well documented. But you can. But focus, for example, on pydentic, you will have a different approach. On V two, for example. It was a lot of stuff get in because, well, it was the change of version and it was an opportunity to just change the API of a lot of stuff and improve a lot of stuff. Yeah. So maybe to give one specific example, how should one implement an admin page with a fast API app? Because in Django it's on board. Right. So you could argue that there's like an obvious way to do it. I saw a couple of template repositories with fast API that introduced a way to do the admin page. Do you have an opinion on that or a guidance what, something that you found really elegant, how to do it? No, but actually I haven't seen that request that much. I think the one that I usually recommend is this one. Hold on, let me search. I mean, first API, how do you call it? Admin? I have. There is. Yeah, so there is this package called SQl admin. It's by Amin Ali. He lives here in Utrecht as well. Yeah, we had beer sometimes. He created this package some time ago. It's usually the one that I recommend when we talk about it. Also, he's a maintainer of starlets as well, so I think it makes sense to recommend whatever he does. But I haven't seen people asking that that much. I think when people ask, like, you are trying to see stuff that you have in Django that you don't have natively in fast API. One thing that I've seen people asking is the, like to generate the project out of nothing. Django admin, like create new products that we. I've created with like, I forgot the name. Something fast API manager or fast API manage or something like managed fast API some time ago, but it's been years since I released something. For some reason people keep adding stars on it, but I haven't released in two years, so. Yeah, but that's something that people really asked. But they had the meme page. I don't think maybe they are satisfied with what I mean, created. I don't know. Yeah, no, that's, I mean, that's a good point. It's something that we use, we are asked for sure at Py bytes quite a bit when we build two or three apps with our clients in our program, and then sometimes, okay, how do you do this with Django? How do you do this with fast API? And it's good if there's like a recommended way, even if maybe you would say, okay, if you need an admin page, then maybe you rather go with Django. But it's good to know the both ways that are possible with fast API, with Django and nice. Yeah, fast APIs. It's also more minimalistic approach. Right. Building APIs and then the Django, you have the full web framework thing. Also going back to the fact that fast API is based on Starlet and pydentic, you gave a talk as well. Right. What does Starlet really do for fast API? So that could be maybe interesting for us to link below for people to kind of distinguish, like what does first API, what does some examples of what the underlying libraries do. Right. Yeah, I have it here. Yeah, it was in Italy. Yes. Yeah, yeah, that token is nice. I had a lot of fun on that topic. I think that kind of is a nice reference for what you mentioned before. Yeah. Let's talk a bit of mindset. So, mindset as a developer, Julian, the other co founder of Pyrite's, not here. He's always big on the mindset, so you'll hit me in the face if I don't ask it. But of course, with this whole open source work and contribute work is significant. Right. A lot of eyeballs on it, a lot of impact. Yeah. How do you cope with the mindset of this? Difficult decisions, maybe imposition or what's up with that? How do you manage that and how important overall is mindset as a developer? Have you really embraced it or not too many questions, sorry. Yeah, I'm thinking. So that is one important thing. I guess it's always being nice, right? That's important. People forget that over time you get smarter and you get more knowledgeable and you forget that you still need to be nice. That's very important. And so, yeah, being nice, I think it's important on the whole process of this open source thing. I mean, I'm always helping. Right. That's, that's the kind of the idea of doing this as well. It's helpful if like they have issues and then you try to help anyway. Like the idea is always to help people. And about what you said about pressure, I don't think I feel that over the last years because I built a routine. So I do the same thing every day, which I don't think is boring. I think I have this thing of wake up, have my breakfast, same breakfast, my three eggs, my yogurt, and then I go to the coffee place. I don't work at home because it's quarantine times, you know, I don't like it. So I go to my coffee place and then after work I go to the gym and then I get to open source. So, and I also, during the day I read some issues just, just to market as read or something. And if I need more attention, I read in the end at night. So decreasing the load of things in a routine way, you know, I don't accumulate work. I think it's one thing that helps on the not having that pressure thing. So pretty much being able to organize yourselves on this huge amount of notifications because also it's not about, it's about filtering. Well, the notifications that you have, most of people that I know, they don't organize very well, their notifications, they can help stuff. Also email, you see other people with thousands and thousands of emails on my side, I don't have that. I have two emails on my mailbox right now. And it's not because I don't receive a lot, it's just because I either take action at the moment or. Yeah, if I don't take action, just I micro, if I'm not going to do anything, it's just I just don't need action. Same applies for GitHub. So I either do something or not. If I need to do something, I'm gonna unwrap that and I'm gonna read later that day. And then I think. So being organized, help, like always the routine thing helps and always be nice. I think those are keys. So building on top of that, how does the ideal open source contributor act? Like when you see these notifications and so on, what would be the one that you would wish for? Right, like where you say, oh, nice, that's a good one. I like to read it, it's clear and so on. And I can directly help. You mean on the side of a contributor? Like code contributor? Yes, I mean also on the GitHub discussions, right? Yeah, on the GitHub discussions. Usually if you have, if you just answered the discussion, it's already great, just answer it. Like post something like being nice, perfect. Be nice. Answering the question, be direct. Do not, do not this, like, no need to write 50 paragraphs. That helps. Just being precise on the answer, that usually helps on the side of the code contributor. Well, implementation, do not think that I'm like, do not assume that I'm gonna add the tests. If you implement and add the test, that's already great. If, if you link the issue, that motivated that. So linking the issue is very important. So I don't need to look for it. So it sounds a bit simpler, but people don't do it. So linking the issue, also explaining, like, if it was a normal pro request in a company, you just review your own code and sometimes you need to add some comment and you just review yourself and put here, I did this because of, I need, I need something like you can be professional on open source as well. It really helps. Yeah, that is, that's it. If you add documentation, even better. Yeah, those are great tips. I also like that tip, like, yeah, to maybe not put all the commands in the code, but you can actually review your own code and just add some commands. Yeah, I don't like comments in the code. I had a teacher in university that he said if he was a bit like philosophical and stuff, but he said if the code doesn't speak by himself itself, it's not good or something like that. But he always said you need to document just comments that he didn't like. So he was like, if you need to comment, it's because the granularity of the code is not as good as it should be, so you should, uh, improve it. That's what he always said. Awesome. Cool, nice. So lastly, always ask about books and what you're reading. Okay. I need to check that. I actually don't read much. I listen all the time, so I listen to audiobooks. That works, too. Yeah. So it's. I'm reading this. The medieval. Medieval. How do you say that in English? Medieval, yeah, medieval. Yeah, the medieval work. Sorry. The medieval world. What's it called? Hold on, let me check. Library. Yeah, the medieval world. That's. That's the name of the. It's by Dorsey Armstrong. It's. It's a bit of. It looks like a course. So they go through the beginning of the medieval to the. They go through the years of what happens. Yeah. Yeah. That's the one that I got here, but I got some more what the things people more like, the last one was called getting things done, and then before that, how to talk to anyone. But I'm enjoying this one more. Was there something like a spark of interest or. So why you chose that book? Something that you got inspired by or. I like history. Yeah, I like history. Yeah. I would study history if I didn't like computer science. Sounds good. Cool. Oh, yeah. Thanks for hopping on, Marcelo, sharing any. Any final thing you want to shout out or piece of advice you want to share on this podcast? I don't know if people want to help on open source. The. I think I would always recommend to go to. Well, you might have noticed, but I did this, and I think it worked for me. I'm not sure if the same path works for everybody, so. But you get a lot of knowledge on reading and trying to help. Usually if you just try a bit more than the brief that the person that asked, you usually get to somewhere, and that usually helps. But so what happens that usually when people come to me asking what I need to do to be an open source maintainer, they are thinking too far ahead. I think you need to think a bit on the steps and getting more knowledge, and then, because at some point, you're going to get there, but it's not. You shouldn't be thinking about the end goal, but what you need to do to just learn a bit more every day. So think about what you can do now and not. I really like the issue approach because it's going bit by bit. It's the issues that live on. The projects are probably things that people want to get resolved. But I did forget to ask you, though, apart from going by existing issues, at that point, you probably was also just playing with the library, checking it out, experimenting with the code. We also then at that point, hey, something is weird not working. Were you also opening your own issues and solving them? We are purely working on existing. Yeah. On first API specifically after two, three months I did start opening and trying to solve them. Yes. Because one thing what people might be held back by is like, yeah, should I really open an issue? It's so visible to everybody. The maintainer is busy but it's okay to open issues, right. Because it's also a form of documentation and this might happen. Can always close them, right? Yeah. I mean if you use the search bar and you don't find anything that's related, you can create. I think always creating is nice. If you do this previous step which many people don't do. Yeah, yeah. If you do this search, don't find anything. You really think it's important. Yeah. But for example, if you are going to open an issue about documentation, I personally that's a personal opinion, I don't think they are useful. I think you can just open a pull request and then we have a discussion there. Yeah, I don't think all documentation requests actually increase the understandability of the topic, but I think it's just better to just open the pro question if it's related to documentation. Nice fast UI is out now for a couple of weeks. I really like the idea and looking forward to where it will develop. And I can only recommend to everyone who is listening, look out to some of these repositories, just follow them in the GitHub settings. You can say that you want to be notified about all the different things that are going on and then you also really get a feeling, okay, what is actually happening, what are the different issues that are created, how are pull requests being merged and so on. And you can learn a lot along the process. And I think if you do this for one or two months, just reading those like you would read on Twitter, then you can get quite some insights and learn it. That's what I still do, but I usually put a big filter on stuff. Like when I started in France I learned that trick no one told me. I kind of learned by myself. Like it's a very simple trick, you just watch the stuff, right? But then at the time in France I just watched all the, all the dependencies of the package we had. So I knew. I think it was mainly the releases of most of them. On first API it was everything. But on the other packages, those releases. Awesome. Cool. Well this has been fun and very insightful. Thanks for sharing, making the time and yeah, we hope to see you back one day and thanks for all you do. Sure. Thank you. Thank you for inviting me. Yeah. All right. 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 slack community of python programmers, go to PI Bytes community. That's pybit es forward slash community. We hope to see you there and catch you in the next episode.