 OK, and now we have Christian, who's going to talk about Python page pages. You there, Christian? Yeah, I'm here. Can you hear me? Yes, yes, I can. Loudly clear. Go ahead. Go to full screen. Awesome. Just to be clear, this is not about snakes, right? No, not this time. But something completely different. So I'm not presenting any cool library or the great talk now on Kubernetes on a very technical level. It's more on an ORFU, a managerial level. So it's a bit of a different talk. So here we go. I'll leave it to you then, Christian. Yeah, thank you. To be with me, I hope it's interesting. So first of all, I want to say that Treyport, again, is very proud to be a sponsor three times in a row now of EuroPython. We feel this is very important to be part of the Python community to contribute and also use the Python community, of course. So to the title of my talk, why should you consider, or why might you may consider getting a Python pet project? So this is basically something that came out of my own experience. So the sample size is n equals 1. However, I would like to share some of my experiences here. So of course, our legal department also wants to have a slide. So maybe skipping over this. Yeah, who am I? Who is giving you the talk? My name is Christian Burger. I'm heading the development department in Austria for Treyport. And I also have a developer background. However, I started probably in the middle, in the dark ages. In 1997, there's a CC++ program in a telecom company, a telecom provider company. And yeah, worked all kinds of positions nationally, internationally in China, in the US, in Germany, Switzerland, and of course, in my beloved Austria. Yeah, I've been working in team leadership, project leadership roles since 2006, becoming department head in 2017. While I started my career, everything was waterfall. At least in companies I was working on, so a lot of four projects. I was really excited to jump aboard the HR bandwagon in the mid-2000s. And ever since, I really like doing this and also like to have my teams at best, self-empowered, of course. Yeah, maybe to the title again. Oh, nice and dandy. But let's focus on the title at hand. So initially, with a pet project, there are some negative connotations, obviously. If you look at the, at least that's the definition I found. It's not very positive. A project activity or goal pursued as a personal favorite rather than because it's generally accepted as necessary or important. And this is a stock picture. It's not a picture from our company. In the past, probably everybody has run across something like that when your boss, your department head, your whatever is really excited about a project, but you really think it's actually not really necessary and only distracts you from your work. So I don't want to talk about these pet projects, but maybe give you a little bit insight on how I came across this. So the problem statement, at least for me, was being promoted to a leadership position or in our case, entered the company in the development managerial position to managing several teams, but also having a deaf and tech background. So I'm really excited about new technologies playing around with them, toying around with them and also be conscious of that we do have, of course, any company tight deadlines have to be really quality conscious and as a manager coming from a tech background, the urge is really strong to be actively involved and then go into the code and help your team. While this is all fine, this might lead to problems. There might be some negative side effects. I'm not saying it's generally a bad practice, but it might have some negative side effects, at least some that I encountered over the course of my career. When you do get involved into the protocol, there will be a set of tight deadlines. There might be an urgent support case or why you think it's an urgent support case. There will be a strong urge to work basically around the rules. So because you set up with your agent, with your teams, with your agent coaches, you will have set up some rules, ground rules, processes for review and whatnot. However, in a managerial position, you might have the possibility to work around that and that's not very good, of course. So this will set a very bad precedent because then the rules should apply to everybody, not that there are a set of rules applying to different set of people. That's not a good precedent basically that you would set here. Also because you're probably not paid to work in a managerial position in order to code, but more to work on a strategic level. So we will have to, in essence, have two masters then which would lead to a high amount of stress on your end and stress level or not development managerial level is quite high from the beginning. So that would really add up to it. So that's also something maybe to avoid and pitfall to avoid. Also, I mean, in the end, you hired developers and testers to develop and test and usually they should be better than you in doing so. If not, then you might have a very big ego or you're actually better than you should invest into recruitment and training of your developers and testers, of course. UX engineers and so on are also included in this. The loss of vocals is also quite likely because you're all caught up in technical discussions. You also might be the final decision maker in all these, in a lot of technical decisions. And that's actually something that can be quite disenchanting or hurtful to your lead engineers or your engineers because they are the ones that should be the ones that are in charge of these decisions. Moving on, this is maybe, but you still want to have an outlet for all your ideas and creativity and also want to contribute maybe. So maybe a pet project could be for you in order to, for example, experiment with new ideas. So for example, in my case, it was behavioral testing. Behavioral testing, that is something that I was very curious about. But I didn't want to put this into the product code right away, but I had basically my playing field where I did this just to get a feel on how this would work and how it would work in practice. Also, in order to feel the processes yourself. Mindful of the daily. Feel the processes yourself. I mean, it's all nice that you have to create the most ingenious review process. However, it's really taking up a necessary amount of times maybe, or it's really great and then you should also feel it basically. That means writing something on paper is one thing. On the other hand, just experiencing it yourself. And not the least, for purely selfish reason, you want to remain technically savvy at least on the, maybe not on the level that your team can be, but at least that you can know what's, what are the latest and greatest packages. Know the programming languages, know the problems of your team and also retain your own knowledge and maybe even expand it. In my case, using a Python project, it really expanded my knowledge because Python was very new to me when I started in my current position. Yeah, moving on, not too much. No, that's the right one. So anyway, so, however, as is already outlined before, you have to be very careful with something like this because this can really draw you in and basically suck you into a big black hole of additional work. So what would be a good idea to consider is of course this project should have some sort of benefit not only to you, but maybe also to others, maybe even ideally offload your developers from menial tasks and automation could be, tools could be a good venue for that. You should be a role model. So I mean, if you expect your team to live up to certain standards, you should also do so. Otherwise, it will be kind of, yeah, would be not setting a good precedent. You have to set the right priorities because you might be drawn away from it. At any time you may be drawn in a meeting, you will have, of course, you should, the main focus is giving the right tools and resources to a team. So this always takes precedent, of course, and also then you have to be, of course, as a manager also aware of what your product is doing, what is the business impact and so on. This, of course, has to be priorities because you might be pulled, you might want to over prioritize your side project. So actually, this is something you have to continuously watch yourself that this is not the case. Also, what's not, what's quite an anti-pattern is, you might have a graded year for a side project and then you lose interest and you dump it on an engineer's desk. That's also not gonna make you very popular. It will basically make you very unpopular and will not help you usually. You can, of course, if you're really convinced and about the benefit of your side project, this is something you, over time, you can add other people to it so at least they know what it's doing. Yeah, of course, cat pictures. How did I end up with a pet project? How did I come across it? So, I mean, there were some of the ideas that are already outlined. Most struck me the similarity to how I ended up with two cats or our pets. So first, our kids, they wanted to have one cat to play and cuddle and they were really, if you have kids and you know how insistive they can be. They did one year of a bedroom, bickering my wife and me and then finally, after one year we gave in, we say, okay, that's, we give up, we buy your cat. We got wild promises, they will always be cleaned, they will always be fed, we will do everything, we go to the vet and whatnot. So, going to the vet, he told us okay, one cat is maybe good, but it should have two, we should rather have two cats, so they have company. So then we buy two cats and yeah, if you can imagine, so after about a half year, the cats are taken care of almost exclusively by my wife and me and so the kids can focus on cuddling and making cute cat pictures like the one on this slide. Nonetheless, I'm very happy to have the pets, of course. So, it kind of reminded me on how I ended up with a pet project. So, in the company before we were bought by Traypod, we introduced back then a new ticketing systems and also the grand expectations and what we can achieve with it. Then of course, I had to batch, in this case, I had to do it with the other departments to okay, we really need this and we need this and that expectation, we need this and that functionality and people were sold and we found that of course, just using the ticketing system itself will not solve everything, so on top with our consultants, they told us now you need this and that plug-in and integrations, yeah, and then since I wanted really this approach to succeed and it was my first project here was to, I started writing one integration, two integrations and this basically continues on its own and for me it was really a good introduction to using Python and I really appreciate having done that. Yeah, so again, situation when I started, I was fairly new to, completely new to energy trading. I was fairly new to Python at one very small project before I joined, I knew the ticket systems in question, at least as a user level, but I was acutely aware of how much automation can help us, especially when you're a small team, I mean, the more you do manually, this also applies to the bigger teams, that's usually not something you want to do, you want to have to automate as much as possible so that people can focus on what they hear to do to create cool new products and not spend time on menial tasks. Yeah, some constraints that I set myself when picking this up of course, some of the same that I outlined before is that I want to use, if I'm doing something like that, first of course, I need to be aware that I have to always be able to drop it when the need comes. We, I wanted to use the same tools and very similar tech stack from what our products implementations doing just because I wanted to be able to basically experience firsthand what it means to use this or that product that is in that library. I also wanted to run the same processes, so that means MergeQuests, reviews, tests, unit tests and so on, not exemplify it and try to be a role model basically also to, for example, to our engineers on new hires. Of course, one of the ideas was to make this ticket to introduction successful. And of course, when I'm not writing this on my own, is there's also other people, some things that helped us getting this off the ground. So, but I still wanted to make a contribution and create automations that make our lives easier and not necessarily harder. That's very important and very easy to miss. Some, and I think that almost concludes my talk. Some of the lessons I learned along the way. For me, it was really deep appreciation of Python. Coming from background C, C++, a little bit of Java and that's being years ago. I really appreciated how fast this, how easy it is actually to set up and get a complex task done using Python. And that's really awesome. I may be skipping head here to this line flask and requests that really helped me getting the application out very fast and running an HTTP server with a little effort. Also appreciation for what it means for unit testing and the creation testing, especially in a management position you've always been asked here, why is this feature taking this so that long why is this effort so high? One of the reasons is of course you want to guarantee a certain quality level and this you can, it's not the only way but one of the ways to do it is of course to have good and solid unit tests and integration tests and other test stages as much as possible and those working and those can be a lot of work. It can also needs upkeep, it needs improvements. So there is a lot of work for that but the benefit of course, odd ways to cost usually. For me it was also using the project as a test bed for new tools and processes. So before basically other people suffer my ideas, I wanted to see how do they look like, how do they feel like in one of these small tool projects. Also, I mean this is quite obvious probably to most of you but however, I really felt that spending some time to create automatic deployments really, really pays off over time because you then basically essentially have only to worry about doing this once, investing time in Docker and Docker files and also can help here and also make you more independent so you don't have to worry about deployments anymore or environmental issues. It makes me, it made me really appreciate good documentation and I think it's a good documentation takes its time. That's I think the most, the best takeaway I got from that. And last but not least for me was staying humble myself and learn to trust my team and maybe it may also help you to trust your team with their decisions. And I think that's all I had. So looking forward to questions. Thank you so much, Christian. Would you have a few questions? So first of all, how long do you spend writing codes versus non-coding work as a tech lead? That's a difficult question. I think it depends. So it depends on what are the immediate thing to do. And sometimes I would also take, maybe in the evening take some time if the things have quieted down to write some code. It's very hard to give a number, I must say because it fluctuates. Sure. But if you want to know more details, of course you can visit our booth and we can maybe direct message me. Cool. What kind of pet projects do you recommend for someone without much time? Now, I found, it's also very hard to give a general answer. But I found automations, for example, of office processes quite handy because this is something that usually has immediate benefits so somebody, some repetitive work will be replaced with something that's good. And usually those are not big tasks. So it means you can drop it. This is basically the main constraints. You must be able to drop it and not having people wait for it. Yeah, again, it's hard to make a generalization but in my case it just landed itself because there was not somebody immediately waiting for it because anyway, the team working it but I made some add-ons basically and data being used. So, yeah, for example, and what's not good if there's, for example, your dev team waiting on something like that or you have, you're blocking somebody, I would definitely exclude, I would say, in a negative way. You talk about like usual things that you have to do but you can automate in the meantime so you can still do them manually even though you haven't automated them yet, right? Yes, yeah, something like that, yeah, something like that. Cool. In your role, does a tech lead need two codes to be a good tech lead? I'm not sure, I think not really. I don't think so but I think you should have an understanding so of what your people are doing and basically have a respect for what your people are doing and for me, it's coming from a deaf role. It kind of meant that, okay, I wanted to feel this, I wanted to feel I contribute but I don't think it's a necessity. So if you think it's, the necessity is basically that you are able to trust the teams with their decisions and appreciate what they're doing. Cool. Thank you. That's all the questions we have. So thank you so much for the talking and question. You're welcome.