Why You Should Consider Getting a Python Pet Project
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 115 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/58754 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
EuroPython 202186 / 115
1
3
19
25
31
34
36
38
41
42
44
46
48
52
60
61
62
65
69
73
76
82
83
84
92
94
96
103
110
113
00:00
Patch <Software>KomponententestCASE <Informatik>Güte der AnpassungNegative ZahlProgrammierspracheModallogikOrtsoperatorMereologieRechenschieberProtokoll <Datenverarbeitungssystem>SchlussregelDifferenteProgrammiergerätMIDI <Musikelektronik>DatenverwaltungProzess <Informatik>Ordnung <Mathematik>Physikalisches SystemDatenfeldErwartungswertEDV-BeratungFunktionalTelekommunikationStichprobenumfangFokalpunktSchreib-Lese-KopfService providerHilfesystemMultiplikationsoperatorComputerunterstützte ÜbersetzungProgrammbibliothekNebenbedingungStandardabweichungTaskEnergiedichteEinfügungsdämpfungSoftwaretestMAPWellenpaketBefehl <Informatik>Produkt <Mathematik>AdditionQuick-SortEndliche ModelltheorieEntscheidungstheorieGroße VereinheitlichungCodierungZahlenbereichMessage-PassingOffice-PaketProzessautomationEinsCodeIntegralUniversal product codeDatensatzVollständiger VerbandRechter WinkelSoundverarbeitungSchnittmengeServerKartesische KoordinatenStrömungsrichtungCodecTouchscreenPauli-PrinzipRechenwerkImplementierungBitDruckspannungBenutzerschnittstellenverwaltungssystemÄhnlichkeitsgeometrieInverser LimesAppletGeradeBesprechung/Interview
00:26
SoftwareentwicklerBefehl <Informatik>Produkt <Mathematik>CodeDruckspannungSoftwaretestOrtsoperatorDatenverwaltungBitDifferenteCASE <Informatik>Negative ZahlProzess <Informatik>MAPSchlussregelProdukt <Mathematik>Schreib-Lese-KopfFokalpunktDruckspannungMereologieDatensatzProgrammiergerätSoftwaretestStichprobenumfangTelekommunikationWellenpaketService providerSchnittmengeMultiplikationsoperatorOrdnung <Mathematik>Güte der AnpassungComputeranimationVorlesung/Konferenz
06:33
CodeProdukt <Mathematik>DruckspannungSoftwaretestIdeal <Mathematik>DatenmodellProzess <Informatik>Ordnung <Mathematik>MultiplikationsoperatorEntscheidungstheorieTaskOrtsoperatorSoftwaretestÄhnlichkeitsgeometrieFokalpunktComputerunterstützte ÜbersetzungEinsDatenfeldCASE <Informatik>DatenverwaltungEinfügungsdämpfungProdukt <Mathematik>Endliche ModelltheorieProgrammierungMAPQuick-SortAdditionRechter WinkelComputeranimation
12:40
Physikalisches SystemTaskEnergiedichteKontextbezogenes SystemNebenbedingungDesintegration <Mathematik>FunktionalErwartungswertSoftwaretestEDV-BeratungProdukt <Mathematik>NebenbedingungOrtsoperatorEndliche ModelltheorieTaskGeradeSchreib-Lese-KopfServerKartesische KoordinatenMAPDatenverwaltungPhysikalisches SystemStereometrieBitProzessautomationTestbedMultiplikationsoperatorProzess <Informatik>KomponententestEntscheidungstheorieIntegralEnergiedichteProgrammbibliothekImplementierungRechenwerkComputeranimation
19:10
Fahne <Mathematik>CodeCodierungProzess <Informatik>Office-PaketHidden-Markov-ModellNebenbedingungModallogikMultiplikationsoperatorRichtungMessage-PassingVorlesung/KonferenzComputeranimationBesprechung/Interview
Transkript: Englisch(automatisch erzeugt)
00:07
Okay, now we have Christian who is going to talk about Python patches. You there, Christian? Yeah, I'm here. Can you hear me? Yes, yes, I can. Loud and clear.
00:21
Go to full screen. Awesome. Just to be clear, this is not about snakes, right? No, not this time. Something completely different. So I'm not presenting any cool library or like the great talk now on Kubernetes on a very technical level. It's more on an overview, a managerial level. It's a different
00:45
talk. I'll leave it to you then, Christian. Thank you. Be with me. Hope it's interesting. So first off, I want to say that Tradepot, again, is very proud to be a sponsor three times in a row now of your Python. We feel this is very important to be part of
01:01
the Python community to contribute and also use the Python community, of course, yeah? So to the title of my talk, why should you consider, or why 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 one. However, I would like to share some of my experiences
01:25
here. So of course, our legal department also wanted to have a slide, so maybe skipping over this. Yeah. Who am I? Who is giving you the talk? My name is Christian Bueger. I'm heading the development department in Austria for Tradepot. And I also have
01:46
a developer background. However, I started probably in the dark ages in 1997 as a CC plus plus programmer in a telecom company, a telecom provider company. And yeah, worked
02:01
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
02:24
my career, everything was waterfall, and these are companies I was working on, so waterfall 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
02:44
at best self empowered, of course. Yeah, maybe to the title again. At the end, but let's focus on the title at hand. So initially, with a pet project, there's some negative connotations, obviously. If you look at the, at least that's the
03:03
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
03:20
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.
03:44
Um, so the problem statement, at least for me was being promoted to a leadership position, or and in our case, entered the company in the development manager position. So managing several teams, but also having a different tech background. So we
04:03
am really excited about new technologies playing around with him, 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,
04:25
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
04:40
side effects. I'm not saying it's generally 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 product code, there will be 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
05:05
around, 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 major position, you might have the possibility to work around it. And that's not
05:26
very good, of course. So this will set a very bad precedent because then the rules should apply to everybody, not that there are different set of rules applying, different set of people. That's not a good precedent, basically, that you would set here. Also, because you're probably not paid
05:45
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, serve two masters, then which would lead to high amount of stress on your end and stress level on our development, managerial level is quite high from the
06:03
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
06:22
very big ego or you are 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 focus is also quite likely because you're all caught up in technical discussions. You also might be the final decision maker in a lot of technical decisions.
06:46
And that's actually something that can be quite disenchanting or hurtful to your lead engineers or engineers because they are the ones that should be the ones that are in charge of
07:00
these decisions. Moving on, this is maybe, but you still want to have an outlet for 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
07:26
behavioral testing. Behavioral different testing, that is something that I was very curious about, but I didn't want to put this into the protocols right away, but I had
07:41
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, feel the processes yourself. It's all nice that you have to create the most
08:01
ingenious review process. However, it's really taking up a necessary amount of time 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, it's experiencing it yourself. And not the least, for purely selfish reason, you want to remain technically savvy, at least maybe not on the level
08:25
that your team can be, but at least that you can know 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
08:45
knowledge because Python was very new to me when I started in my current position.
09:01
However, as I 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, these projects should have some sort of
09:22
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,
09:41
you should also do so. Otherwise, it 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 might be drawn in a meeting. You will have, of course, the main focus is
10:01
giving the right tools and resources to your 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,
10:29
this is something you have to continuously watch yourself that this is not the case. Also, what's not quite an anti-pattern is you might have a great idea for a side project and
10:41
then you lose interest and you dump it on an engineer's desk. That's also not going to 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 about the benefit of your side project,
11:01
this is something over time you can add other people to it so at least they know what it's doing. Of course, cat pictures. How did I end up with a pet project? How did I come across it?
11:22
I mean, there were some of the ideas that I already outlined. Most struck me the similarity to how I ended up with two cats or pets. So first, our kids, they wanted to have one cat to play and cuddle. If you have kids, then you know how
11:41
insistent they can be. They did one year of badgering, bickering, my wife and me. Then finally, after one year, we gave in and said, okay, we give up. We buy your cat. We got to buy promises. They will always be cleaned. They will always be fed. We will
12:01
do everything. We go to the vet and whatnot. Going to the vet, he told us, okay, one cat is really good but we should rather have two cats so they have company. Then we buy two cats. If you can imagine, after what I have here, the cats are taken care of
12:22
almost exclusively by my wife and me. The kids can focus on cuddling and making cute pictures like the one on this slide. Nonetheless, I'm very happy to have the pets, of course. So it's kind of reminded me on how I ended up with a pet project. So in the company before
12:47
we were bought by tripod, 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 measure. In this case, I had to do it with the other departments to, okay,
13:06
we really need this and we need this and that functionality. People were sold. Then we found that, of course, just using the ticketing system itself will not solve
13:20
everything. So we talked with our consultants. They told us, no, you need this and that plugin and integrations. Since I wanted really this approach to succeed and it was my first project here, I started writing one integration, two integrations and this basically continues on
13:41
its own. For me, it was really a good introduction to using Python and I really appreciate having done that. So again, the situation when I started, I was feeling completely used to energy trading. I was fairly new to Python at one very small project before I joined.
14:02
I knew the ticket systems in question, at least on 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 bigger teams. That's usually not something you want to do. You
14:25
want to have to automate as much as possible so that people can focus on what they're here to do, to create cool new products and not spend time on menial tasks. There are some constraints
14:41
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. I wanted to use the same tools
15:03
and very similar tech stack from what our product implementation is doing, just because I want to be able to experience firsthand what it means to use this or that product that is in that library. I also wanted to run the same processes. That means merge requests, reviews,
15:27
tests, unit tests, and so on, not exemplified 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
15:41
ticket to introduction successful. Of course, I'm not writing this on my own. There's also other people, things that helped us getting this off the ground. I still wanted to make a contribution and create automations that make our lives easier and not necessarily harder. That's
16:05
it. I think that almost concludes my talk. Some of the lessons I learned along the way, for me, it was really a deep appreciation of Python. Coming from background C, C++, a little bit of Java, and that being years ago, I really appreciated how easy it is actually to
16:27
set up and get a complex task done using Python. That's really awesome. I may be skipping head here to this line flask and request. That really helped me getting the application
16:43
out very fast and running an HTTP server with very little effort. Also, appreciation for what it means for unit testing and creation testing, especially in a management position. You've always been asked, why is this feature taking this long?
17:03
Why is this effort so high? One of the reasons is, of course, you want to guarantee a certain quality level. This is 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.
17:23
Those working on those can be a lot of work. It also needs upkeep. It needs improvements, so there is a lot of work for that, but the benefit, of course, always the cost, usually. For me, it was also using the project as a test bed for new tools and processes. Before,
17:44
basically, making other people suffer from my ideas, I wanted to see how do they look like, how do they feel like in one of these small tool projects. Also, this is quite obvious probably to most of you, but however, I really felt that spending some
18:04
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 and also make you more independent. You don't have to worry about deployment anymore
18:26
or environmental issues. It made me really appreciate good documentation. Good documentation takes its time. I think the best takeaway I got from that.
18:43
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 your questions.
19:15
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?
19:28
That's a difficult question. I think it depends. So it depends on what are the immediate things to do. And sometimes I would also take some, maybe in the evening, take some time
19:44
if things have quieted down to write some code. It's very hard to give a number, I must say, because it fluctuates. If you want to know more details, of course you can visit our booth and we can maybe direct message me. What kind of pet projects do you recommend
20:05
for someone without much time? 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
20:20
that usually has immediate benefits. So 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 constraint. You must be able to drop it and not having people wait for it.
20:40
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 that are being used. So yeah, for example,
21:03
what's not good, if there's, for example, your dev team waiting on something like that, or 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
21:22
automated them yet, right? Yes. Yeah. Something like that. Yeah. Cool. In your role, does a tech lead need to code to be a good tech lead? Hmm. I'm not sure. I think not really. I don't think so, but I think you should have an
21:46
understanding 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 dev role. It kind of meant that I wanted to feel this.
22:02
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
22:27
the talk. You're welcome.