 And in this talk, I'll be giving you an overview of my journey into becoming a Python developer. I'm still on that journey. It's currently been going on for over 10 years. And I'm a bit smarter, but I still make same mistakes. And when I started working at my last company four years ago, this gave me an idea for a talk because I started working on a very complex system that's been going on for over 10 years before I joined. So, how did I start? When I was a junior developer some 10 years ago, I used resources like this. These are very small pictures, but they are, let's say, memes or really library. I'm sure you're sure of it. So, I did like any normal junior developer does. I started the project any way I could. That means I would get credentials to whatever software, version management software the company was using. And I would just run the code. So, first thing first, you probably use wrong interpreter. I started project with Python 2, but the project was still in Python 1 and 1.5. Yeah, I'm that old, yeah. So, that was my first mistake. Then I identified the error, corrected the error on my end and started again. Yeah, that's not something that you should be doing. So, then I said, okay, let's run tests. So, how did I run tests? I would just find the test file or folder and click run. That, of course, fails because you need to set up certain things before you start the project. I did none of that, yes. Then I skipped tests because they were failing. So, yeah, it's a logical step. Yes, if it fails, skip it. So, then since the application was not working, I couldn't run any tests. I tried to understand what was going on by just poking around. I would open a random file and read what was in it. That was what, 10 years ago. The project I was then working on was already in production for a couple of years. So, you can imagine it was a huge project. And it was written in Pylons web framework, if you remember. That's before the team decided to do Pyramid web framework. Yeah, the Pylons was phased out when it reached version one. We were on 0.7 at the time, something like that. So, it was a huge project with lots of code. And if you randomly open up a file, you will not get the picture of what it was doing because you don't do that. You don't randomly open files and start reading them. It's not a book, although it should be. So, I gave up and took my first task from the task management and started working on it. Can you imagine how that went since I had no running tests, no running code, and I had no idea what the application was actually doing? So, I coded. I committed my first task and waited for bug report. I forgot that we had no Q&A, so that was released to production. And nobody noticed. Anything. Because, of course, the code was unreachable, so there was no bug. Win, my first big win. I was so happy. I thought that I could do that way, repeated until I retire because it works so well, yeah? And, yeah, it turns out it's not so well because occasionally somebody asks where my feature is and since I committed the code, closed the task, they asked where the feature is and I said, yeah, it's on production. It works. It works on my machine. They said, show me. Big mistake. It didn't even work on my machine. So, yeah, me. Then I decided to be proactive. Yes. I was an early adopter and asked the people who I worked with who were paying me to code, not program code. I didn't know how to program back then, yeah. So, I asked them, okay, what this application does, what's it doing, what problem does it solve and how do I, you know, start to run it and stuff like that. Now, you might ask yourself, why wasn't I given an introductory tour and, you know, basic, you know, overview of the company, of the process, of the code, how it's working. Turns out I came a month earlier than expected because I finished college just and they hired me right out of the college. And they thought I would be working at February 1st, not 4th of January. So, they weren't prepared. And neither was I, yes. But that all aside, then we sat down and had our introductory course, yes. And it went very well. I managed to start the program. I managed to actually start working. And I started what I was thinking was the right way, yes. And I was trying to read user documentation and guidelines. And it turns out there weren't any. Okay. So, I got my mentor who finally was free. And to show me how the app works and what it does, what it's doing, how it does, what it does, what problems does it solve. And it turns out it was quite an impressive application and was working quite well. And I was proud to work on it. So, I decided that I should not blame the previous developers, me for the bugs in the code. So, I started doing the right way. I started the project the correct way by reading ReadMe and correcting that ReadMe as it was outdated. I ran tests this time successfully because I read the documentation on how to set up tests and test suites and databases and whatever was needed. And I made notes on what was missing in the ReadMe, in the change log, in the setups and in the configuration defaults. Because as the project drew, there were always deadlines and some things were not written where it should be. For example, if you come to a new project, you should have settings that have same defaults and are documented. So, you know what each setting does. So, I made notes and I thought that this was the right way, yes. And I contributed back. I fixed bugs, added features and it went well. And I thought that this was the right way, yes. But then I did this again. New project that we set up, I started it. Anyway, I could, I just copy pasted some boilerplate, ran it, ran tests, failed, skipped tests, failed, understood what the application was doing by poking around, gave up just coded. So, you see the pattern here. And I committed, repeat until retire. Again, yes, this is my motto. I want to retire early and I thought the programming was the best way. But this time I wasn't coding, I was programming. I was making progress. The only thing I forgot was the lessons learned from the previous year. So, I had to do it over again. And this time, from the point of view of the developer who inherited the code base, that was written by me, and I had to explain to the new guy what it was doing. So, he came and he did it the right way. He took me by the hand and asked me, show me how this app works. And I said, well, isn't it obvious from the code? And he said, well, not exactly. You don't have a read me. You don't have a set up pie. Back then, we used set up pies and built eggs, if you remember. Yeah, so I said, okay. So, we need, you don't blame the previous developer. That being me again. So, we started the project together. We ran tests. We made notes of what to improve. And he contributed. I was just the mentor this time. So, I thought that it was good. And it was working. And it was good. It was good for a long while, because I think that what we always forget is that this is a marathon, not a race. I forgot it two times. So, I decided to let my experience show what are the failures into dying into code base. So, first is you don't dive. You tip your toe. So, you start by opening up the project and read read me. And if you see that the read me is out of date, you update it and commit that as your first task. So, that's something that you should do. And you need to keep tests up to date. When I'm overwhelmed and the deadline approaches, I stop what I'm doing and actually write a couple of tests that can clear your mind. I am a late adopter of tests as in the last couple of years. And I've been programming for 12. So, yeah. Yes. I'm halfway into my career. Yeah, you'll learn while you live. So, that's my motto. So, you need to keep your tests up to date. You need to comment your code. Now, I've been on a couple of conferences and there were always these topics. Should you comment your code or should you not comment your code? You should comment your code in a specific manner using specific linters and style. And I said, well, first, yeah, you should comment your code, especially parts that you think you know now that just came to you in a sleep. And that actually happens. So, you write your code. It works. And then six months after, you need to fix something in it and you don't know how you need to put on break. And print statements. Yeah, I didn't use logging. Should have been on that talk earlier. But your comments are there as a testimony of what you thought you were doing or fixing at that point in time. Every time you write a code, it's a statement of your skill and pressure. Somebody put on you to finish that task at that point in time. So it reflects that point in time not only for the future developer, but for you. So that's what I meant by commenting code. You need to show the person who will maintain that code why it was written that way in that point of time. Maybe you were just young. You didn't know there were libraries around that could do it. So you did it manually. It happens later on. You come back and you see why was I using this when I have a library that does exactly that in a few lines of code. Well, you didn't know about it then, did you? Or maybe it wasn't written yet. So that's the don't blame the developer. You don't know in what situation was he at that point in time. And refactoring. Now, you might have heard in these past couple of days and today on the on every presentation here that there are something. There's always something new and shiny and better each and every month, if not here. And why not use it? Take time if you can to actually use the news things that go around in the community. Use the new library refactor your old code that you see that it's not optimized. Maybe it was working when you had a smaller data set. Now you have big data set and that it's, you know, still somewhere you can squeeze out a couple of milliseconds but refactor it now. And it will you will be grateful for yourself and make notes by notes. I mean, write changelog, write read me comment code and actually somebody mentioned using wiki. For example, if your company has a wiki where you can post snippets of code that are great or link it in your code to a blog post or a book or something. That's also very useful because that shows why is why is that piece of code written in that manner. That's that's great stuff. And of course contribute. That means giving talks like this at the conferences or at your local Python meetups or any other kind of meetup. Go to the conferences meet people. Actually, you can contribute just by being mentor to the developers that come into your company. And what I can say is you ask questions. If you remember at the start, I didn't ask questions for a couple of weeks. And I thought that was what what you were doing. You know, I was fresh out of college and you don't ask your professors many questions. You can ask them a couple of questions and that's it. You know, but they are they meant for you to be independent and proactive. So I said, OK, let's be independent and proactive. But that doesn't mean you don't ask questions. It just means that you need to find the right way to ask questions and to recap this in a very concise ways. You don't dive into a code base. You take shallow little steps and then you swim in it and then you can retire. And of course, rest is very, very important. Like the colleagues said, there are only 24 hours in a day. We all have family and friends. So if you are working yourself too much, you and everyone around you will suffer and eventually you will burn out. It happened to me because I was stupid and I urge you not to try. So don't work 20 hours a day. Don't lose your sleep. Don't eat unhealthy food. Exercise. I'm still working on that one. I started 15 times. I'm good at it. I'm starting every year. Every year something new. This year it's mountaineering. I climbed four and a half thousand meters just to get away from my code. So rest is very important because you charge your batteries. I'm sure that you all heard that expression, the greatest idea come when you're on the toilet. It's true. I can vouch for that. Just don't forget to flush before you go back to your department. The colleagues won't appreciate that even though your idea is brilliant. Yeah, so that's what I had in mind and that's what I throughout these 10 years learned the hard way. So I hope you won't. I hope you'll take something out of this talk that will make you easier into your work. And also for those who are jumping in, it's nothing to be afraid of. If you follow these simple rules, eight simple rules for those who are currently writing code, please remember that there is always a next guy who might not be as forgiving as I am. And you know, he might know where you live. And now I'm open for questions. And here. If someone wants to ask questions, please use the microphone so we can hear everyone. I will put this microphone there too so you can have two. We'll have a lot of time, almost 10 minutes. It was a short career, so the talk isn't long. Like I said, I'm still young. Hello, can you hear me? Thank you for an interesting take on diving or rather tipping your toes into the code base. I think one of the steps that kind of got, that kind of missed at the end was like how important for you personally is talking to someone about the project when you're tiptoeing to it. And what do you do if you don't have that possibility? For example, if you are trying to understand open source library or something like that. Great question. Yes. Biggest problem when you don't have somebody to ask is how to ask questions. If you don't have a person, then you need to search the documentation. What if there is no documentation? If somebody wrote a library that you use and wrote it like I did my first library without reading me without anything. Well, I suggest if you can, to skip that library and use another. If you cannot, that happened to me, you do this. Exactly. I did it a couple of times on the libraries. I had to use some JavaScript library back then. It was very popular to use libraries, not framework. I'm still on jQuery and I think it's the best. So I actually had to fork that because the last commit was like five years before I even was starting my journey as a developer. So I forked it, integrated it into my code and started poking around it in it to see what it does. And it's a hill of a journey. I don't recommend it. That's why I made this talk. But that's the only thing you can do. And it's going to be stressful. But thank you for the question. I hope you answered it. If not, come find me after the talk and we can talk more. Thank you. Thanks for your talk. There's a lot of wisdom in it and it's also very funny. I'm a teacher and we're learning our students' UML to make designs. Do you use drawings to make overviews of a code base and do they really help you? Yes. So in my current company, we actually started, they started it years ago, but we intensified that communication because communication is very important and there's nothing better than a picture to show you what you mean because if you put something in words, like I think there was a talk yesterday about behavior-driven design where you write your thoughts in a, so to speak, you communicate your wishes with the project owners by writing meaningful statements how your code should behave. That's good, but I think that picture, UML designs speak even better. The only negative side I see about it is that you need to maintain it. So if something changes, you need to remember that you have a picture that's not accurate right now. So if somebody comes and reads your UML diagram and you change the code, he will have certain expectations that you no longer meet. So that's the only negative side, but yes, pictures are great stuff. Thank you. All right, hello. Thank you for that entertaining talk. I found it very relatable. Okay, so in my case, I tend to be working with open source tools, which are fairly popular. I understand a lot of problems, which are fairly popular among the communities, but not necessarily around the world, let's say. So one of the problems I had was, like you mentioned, excessive independence and wanting to figure out everything before bothering anyone else about it. I do worry that there are times when I have gone to someone without knowing anything and I felt like I have actually been bothering them and they probably didn't have the time to explain the absolute basics. So one problem I'm facing at the moment is cold approaching the scientists who are developing the code I'm using. Do you have any reflections on that? Like how much should I learn before going and approaching people? I'm not necessarily directly... Excellent, excellent question. Thank you. I think I read that, I think a couple of years ago, there's an excellent article on, I think, on Stack Overflow, how to ask questions. Basically, what is, you try your best first and you record what you tried. First you record what problem are you solving, what you tried, how you tried it, what were the results and then you approach the person by not asking the question of can you fix this for me, but can you help me? I tried this, this and this, I got that, that and that, but I expected a wholly different result and now I'm stuck and I think that you might be the best person to help me unstuck and continue working on my problem. That way you show that you are not seeking just dump me the solution and I'll say thank you maybe. You are showing that you can actually actively listen and participate, that you have tried your best, which is very important because you don't know how busy they are. Maybe your interruption will cause them a couple of hours and they might be expensive, so you never know. So that is the approach I am using and I have, when you're on the other end, when you're mentoring somebody, I have this 15 minute rule. My mentor taught me that and it basically says if a junior who you are mentoring cannot solve a problem on his own using these steps, in 15 minutes he must come to you because he will lose an additional hour or two investigating something that you know and you can help him by pointing out not to the exact solution but maybe pointing out to the structure of how he came up to the wrong or how he got stuck, so you help him in the steps he took and then basically he will understand, oh, I took here the wrong turn and it led me sideways instead of right. So that's a process and you learn it all the time, I'm still learning. So that's not something that you will immediately adopt and now you'll be 10X developer than you were 15 minutes ago. It's always a process. And please be patient with those who you ask. Maybe they had a stressful day or they got 20 questions before you by somebody who was not respectful and so be patient. That's it. Thank you. So you say systematically lay out your efforts and then present it cleanly to them. Yes. Thank you. Thank you very much. Do you have any other questions? Okay, we'll have time if you have. If you don't, you can find Lukas in Codebase or in Discord. Thank you, Lukas. We really enjoyed your talk. Thank you.