 So the next speaker is Ivana and she's going to talk about how to avoid becoming a 10 times engineer. Ivana is a back-end developer building web services at Wegfinder. All right, so welcome everybody again to this talk. I hope you had a good lunch. I was too nervous to eat lunch, but at least you know, if you did, that's good. So, all right. So I would like to talk to you today about engineering and balsamic osos. And I guess it's a sentence that you've never heard in your life, and that's okay, we will get to it. But first, let's get, you know, the annoying boilerplate out of the way first. So if my slides work. Oh, yeah. So I wasn't sure how good the video quality would be. So this is a candid picture of me taking while coding. This is what they usually look like. Yeah, I like to paint mugs. It's just the thing I do. I have way too many plans and they kind of seem to multiply on their own. Not sure what that is all about. And I also speedrun sometimes. And don't worry, this is not a sport. This is basically trying to complete the game as fast as possible, either using glitches or not. And it's all the fun. And it's a very, very nice thing to do with your programmer because if, for example, there is a puzzle in the game, you can just write an algorithm that solves it for you in the most optimal way. So it's fun. You should try it sometime if you're into that kind of stuff. So with the important stuff out of the way. As Mark also said, I am, I am a web service developer, so I basically build web services and APIs, mostly with the HTTP. And, you know, I kind of like Python, like, it's okay. So, I have been doing this programming thing for a while now. And basically I started with some website stuff when I was in school. Then I moved on to work in InfoSec and data processing for a while. And then I basically landed back in what is basically web development. And, you know, sometime in between getting my first engineering job and bringing down my first production database, I basically came to realize that there is, there are two things that are kind of very common and they're very present in engineering circles wherever you go. So the first thing is that everything sucks. Like, like, whatever tool, software, library, process, you name it, there will be somebody who just doesn't like it and it's very vocal about the fact that they, in fact, don't like it. Except Postgres, Postgres for some reason is this unicorn that seems like very well liked across the board. And the second thing is that everyone has opinions. Okay, maybe it's not everyone, everyone, but the people with strong opinions tend to be very loud about them. So it seems like it's everybody. So, there is this thing called the internet, you might have heard about it. And really, it's an awesome place. Like, okay, maybe accept that. But otherwise it's great. Okay, okay, okay, fine. I mean, it has some hiccups, but what doesn't. Okay, how can you not like the place that brought us synonym rules? I mean, there's just no way, right? It's physically impossible. So, I mean, so there's a, there's a, just ignore it. Okay. So there's a lot of stuff, you know, beyond your linguistic foot endeavors that you can share on the internet. And the easiest thing to share on the internet is your opinion. And when it comes to opinions, the internet is basically dynamics in them, right. So on the internet have opinions about all sorts of things. So obviously, what it means to be a good or bright programmer or how to become one is really no exception. And you have no doubt come across some of these pieces of advice already, like maybe you even sold them out. And many of them make sense. Not all of them. Not all of them. So what I did for this talk was that I looked up what the internet has to say about being a good or bad programmer and basically how to recognize that you're a bad or a good programmer. And I looked as a lot so that I can share it with you now and we can grow together as programmers and human beings in these roughly 25 minutes. So let's let's just start. So the first opinion that I want to showcase is this. Unless it's a real research or publication conference where people discuss and propose solutions to challenging problems, you won't find top notch programmers in these meetups. Why, because more often than not these meetups tend to waste too much time rather than actually solving some problem. This is awkward. I mean, I guess we can all just go home, you know, being the mediocre programmers we are, I mean, I like going to conferences, you know, see what other people are doing, what other tech is out there, what other problems there are with other solutions. But I guess that correlates somehow with me being a mediocre programmer according to somebody on the internet. Okay, I hope you will understand if I skip the part where I actually try to debunk this like considering the circumstances. Okay. The internet also tells us that it is a good sign. It is a sign of a good programmer. If they glance over your shoulder and point at the bug in your code with their finger. But, you know, unless specifically asked, because you might be able to demonstrate your superior bug finding skills but it will probably not win you many friends. So next up. There are some marks of great bad programmers by phrases such as, I am so sad that my program doesn't work. I have tried to plead with it, and it still doesn't give work, or by. I feel that this code is right but I'm just not sure why it won't work, or even by, I read to my program every day and try to be a good friend, but it still doesn't like me. Whenever I try to attach to it, it gives me a core dome. So I mean to me, this kind of makes sense because you know reading to your program. I'm like reading to my little pony pillow will probably not too much good, especially considering that the program is already doing exactly what you told it so change this or that the problem might lie elsewhere. And also I have I have basically to, I think I have to come myself lucky because I have never come across anybody who talks like this. So I guess I have only met good programmers along the way. So that's good. I mean, okay, seriously though. Should you get to attach to your program, unless you're a debugger, it's probably not that good of an idea. But that's being said that your program doesn't work make you a bad programmer. I mean, your guess is as good as mine. The internet tells us that with the right tools, when the 10 times engineer can do the work of 10 engineers, because they are so much more efficient with their time and execution. While an average engineer might be fumbling their way through a process at 10 times or is already streamlined it and it's two steps ahead. So there is this tool that will streamline your productivity all for the low low price of 1000 euro per month. I mean, where do I sign up. Usually I like to have some sort of a need for a tool first. But, you know, I guess it's just the case here that this is the like the pizza scissors of software tooling right you you didn't basically even know it existed until you found out you needed it. Or is that the other way around. Another sign of a good programmer is that they can complete any sequence of dialogue from Lord of the Rings Star Wars, or it worth or Monty Python. Um, so does Gilmore girls count, or are those the only approved shows because. And is it fine if I know all but one season because the that one season was written by somebody else and is like really bad and like the, you know, like the characters don't act like themselves bad. Like, okay, listen, I like nerdy stuff as much as the other person okay but I think it's important to recognize that stereotypes like this can prevent us from recognizing the, the potential and the value of people who basically do not fall into a need bucket like this, because nerdy out is cool and all but gatekeeping a bit less so. I mean, there are many people who would never even consider programming, because misconceptions are like these are just so common like they feel like being in nerd is is a requirement. Like it's like this club but instead, instead of like showing them your ID you have to do a really good Jedi mind trick impression, like, and it's a shame because while being in nerd is cool. Let's be honest, it has no bearing on how good of a programmer you can be or you are like, and nobody should be telling you that you shall not pass I mean you cannot get into the club. You know your album name. Okay, and I'm saying this as somebody who actually owned a set of hand made album years in my teens. Okay, so there's a reason why I don't write that down on my CD, because nobody would be interested. No other reason. If you want to become a better crawler, according to the internet, you should type faster. The author continues, when I see someone who has been working with computers for a decade and can surpass 100 WPM words per minute by the way, for even a short burst. I'll admit, it makes me cringe a little bit. It's just lazy as just Jeff at would put it. This one is a bit less demanding on memory than the previous one because, you know, instead of like remembering all dialogue from a show you just need to remember this one magic constant. Although, I guess knowing all the dialogue from a show is kind of helpful because if you're all, if you're all run out of things to type you can just keep on typing and keep an average, a very respectable average WPM so that's a good thing. Yeah, listen, I don't know about you people but on my average day at work, I spend much more time actually thinking than typing. And the product of the thinking is often fairly proportional to the time spent thinking. So what is more important, the ability to dismantle a problem and find a solution or, you know, writing it down. And your guess is as good as mine. Next up. You probably guessed that this one was coming and for those lucky enough, who don't know what this is about. So this is a Twitter thread from about a year ago, where this person basically shared their observations about 10 times engineers and how to spot them. It's a longer thread and it would probably make for a whole talk on its own. So I'm only picking two things here. 10 times engineers laptop screen background color is typically black. They always change defaults their keyboard keys such as I have an X are usually worn out more than a SME email senders. I do prefer like, you know, black mode or dark mode. And I usually change the default so I guess that's good for me. But I have no idea what makes I FNX more special than a SME and probably in my case, W as D is the most worn out are the most worn out keys anyway. I guess if you if you kind of, you know, make the math that still makes me like a, like a 3.5 times engineer so that's pretty good. 10 times engineers rarely look at help documentation of classes or methods. They know it in memory and can recall it from memory. They write code at the same uses writing English, no breaks, no pause just type. I was with you I'm failing this one so hard, like there, there probably isn't a day where I wouldn't have to look up something I don't know either in Python docs or in the docs of whatever library I'm using. Like I can never remember the order of parameters that go into reduce, like I just can't I guess my memory is just to average for me to meet the standard of some random person on the internet. Thanks again. In case you started programming in your 20s or, you know, even later, and you're wondering how to become a great programmer not just a good programmer. The internet offers this great piece of advice. You should have started being interested in engineering when you were in your early teens. To relate all you can be is a normal engineer. So I guess it's not really about, you know, like willingness to learn more motivation like I thought I mean, it's too bad. Okay, listen, I started coding in my teens, but the most I learned came from basically when I moved from like individual tiny projects where I was experimenting on my own to actually coding with people. And then looking at other people's code and them looking at my code and pull request reviews, this sort of stuff. So it's not really about the pure time spent coding. You're really not missing out if you started up started out later so don't get discouraged. Next up. One guy, he just graduated a call himself a programmer. I asked him a couple of questions. So the tool tips of the application. Have you made a setup for your program. Have you set up tap stops according to the flow. His answers were simple. No, no, no. Yeah, I don't know either let's just move. So next up. To prove, believe it or not, I have written one million lines of code in under six months, resulting in a very functional, relatively back free commercial product on the scale of something like Microsoft Office, though totally unrelated. Further, the product was an innovative and fresh territory as in no competitive products no answers on Google, just completely on my own. I don't do it again because I was then on the hook to maintain one million lines of code. But I guarantee you that's at least 10 times a normal engineer. That's about six K LOC a day. The average engineer I've worked with puts out about 500 LOC a day, the best button or truck stores put out about 2k LOC a day. So it's not a clear 10 times mapping. That's 12 times normal engineer and three times a grade engineer screw in numbers all you want, but there's still a clear divide between rock star output and non rock star output. Yeah, so this person likes numbers. I mean, you know I made a joke about being a 3.5 times engineer, like a couple slides before. And I was kidding but apparently there are people who are actually capable of precisely quantifying the output of a normal engineer. And they do it presumably like down to the decimal point. That's impressive. And they measure how good of a programmer they are by lines of code read. So, but you know what the best, most maintainable most buck free code is like code that was never written in the first place right. It's the best thing in the world to just write code for the sake of writing code and bonus points if you're doing it consistently at 100 WPM or faster. But you know what's harder, like maintaining code right. And what do you, what do you do more often, right a new shiny thing or like maintain this existing spaghetti code code base. It doesn't make any sense to maximize the amount of code written or its maintainability. And finally enough, the author even kind of realizes this but you know, so close and yet so far. And just a sign note, optimizing for the least amount of code written is probably also not the best strategy ever unless you're cold golfing. All right, let me take a breather here. The thing about a lot of this kind of advice is that the author basically assumes that everyone works exactly like them. Like that unless you watch the same shows or you know you have a certificate on your desk, stating just how fast you can type, you can only be mediocre at best. And you can even get so detached from reality that your advice doesn't even make sense to anybody else but you like that all tips person. And, you know, the worst thing about this is though that the perpetuating basically the myth of a rock star or ninja or 10 times or real engineer can be really harmful because it can very easily alienate people who feel like they don't fit the stereotype for whatever reason. I mean you've got to give it to the stereotype it's a very smart way of perpetuating itself. And this myth has also often been used as an excuse to keep people around who make others feel unwelcome without realizing basically how much of an effect this has on the community as a whole. And how that it actually prevents others from contributing, you know, because that's the hidden price of worshipping rock star engineers with poor manners like you might be keeping this one person who can get away with anything because they can get things done. But at the cost of losing many others potentially people you don't even know. Yeah. So that was a bit too serious for this talk. Okay, so let's talk about something else for a bit. Let's let's talk about food. Okay. So let's talk about Balsamico sauce or BS for short. I think that we, you know, as developers, come in contact with Balsamico sauce every day. And you might think in being able to tell whether something is legitimate or Balsamico sauce is an essential skill. So basically it takes time to build up, but I think there's a handful of signs or like red flags that you can basically sport regardless of your experience. So imagine you have, you have an axis like this, where you have like the potentially harmless maybe even valuable advice on the left hand side, and strong Balsamico sauce vibes on the right hand side. So let's start with an easy one. Okay. So if an article suggests that you wire up your dusty time machine and travel back to your team so that you can start coding earlier. I think you should feel free to disregard this advice of this as it will not be very helpful or encouraging. If an article is condescending towards people do not need some arbitrary standard and this is a fairly large group of articles. In some cases, this might be legitimate. Okay, right. Like, I don't know, don't store plain things passwords. Okay, but the key here is the word arbitrary, because you have to think about if enough reasoning is given that supports for example the 100 WPM limit or is that just something is that just the magic number the author thought of in the shower. Your guess is as good as mine. Sometimes an article is just trying to sell you the one true solution to a problem you didn't even know you had exercise caution, even when they're not even trying to hide it. And finally, if an article tells you to dance around the campfire naked on the six full, six full moon of the year. I think we know where to put this one on the axis but still make sure to apply additional bosomical filters because I mean, it sounds reasonable but who knows what they're suggesting later on right. Yeah. So with that said, I haven't really thought this through that well because I mean, I have been making fun of, you know, random advice from the internet. So you might be like, okay, everybody can criticize but you know, what is your proposal. What do you suggest. But then if I give you any sort of advice then I'm just another random person on the internet but in opinion. So why should you take any advice from me and you know, you shouldn't, at least not until you apply your own bosomical filters to it beforehand. Like I said, if you want to become better at writing codes. I really don't have any glamorous piece of advice for you. You just need to practice. You need to write you need to rewrite you need to read code. The best thing you can do is have other people read your code as well and comment on it. Write down things that take you along to figure out, for example, make a make a get record with notes with solutions to problems that took you to key days to figure out because you will forget what the actual solution was and you will come up. But the problem with will come up again. And you know, don't be too hard on yourself. If you can stop comparing yourself to others. You just need to remember that for every amazing program or you see what you don't see is basically the days of mistakes and struggling. And you basically only see the end product. And you can also get there, you just unfortunately have to go through the struggling part first. Yeah, but there's another thing so when I think of a great programmer. It's not that much about code. I mean that matters to of course but it's more about the attitude. It's it's more about how the person approaches problems and how they approach other people. Like, are they willing to help you. Can you bounce your ideas off of them or can they say no to ridiculous demands and shield shield others from them. You know that sort of thing. And I think there is one thing that I think really gets underestimated sometimes and that is that, you know, whenever we write code with very few exceptions. We are part of a community, right. If be it's an open source project or your workplace. And regardless of your standing within the community, although the higher up you are formally or informally with the more of an influence you have of course you influence what is considered normal within the community. You know business like that one time that you were lazy and got some spaghetti cold into the cold base. It might continue to grow because others will be like, Why should I care if this other person doesn't you know, if they can get away with it, or, you know, I don't really like I don't really care about implementing this feature in a nice way because there's already hacks in the cold base so you know why bother. This extends to to social interactions to so your actions, so the precedent. So, what I'm saying is, it's good to be aware of the influence that you have on other people, even if it may be hidden, the first site. Because in the end you know it's much easier, like the easiest way to get a 10 times engineers to get a 10 times 10 times engineer is to simply have 10 completely average engineers working well together and helping each other out. And at the end of the day it's very much okay to be an okay engineer. If you if you took absolutely nothing from this talk, and you just want to know how much of an engineer you really are, you can just pick install this package and it will tell you bonus points if you can get the true ending. And with that, thank you everybody for listening. Thank you very much for this very, very nice talk. We have one question from from Jill. Any suggestions on understanding during interviews if the company you're joining has engineers like the ones you showed over 10 times engineers. So as a participant. That's that's a good question. Well, there are there are things that you can then you can maybe already already spot, like at the interview right you can see what kind of people interview you you can see how will you, how will you get along with them. You can also see what kind of people they are. For example, if they're, if there are people from underrepresented groups there in the interview already that's that's I think a good sign. And I guess you can come up with good questions to somehow detect this I cannot think of anything at the moment because my brain is frozen. I'm pretty sure like, like you get you get you should already somehow feel the vibe from the interview and from the people who interview you. It just somehow clicks and and maybe you can ask them I don't know about you know about about work life balance and all these sort of things because they tend to go together with with a nice company culture. But I think there would, sorry, would you would you recommend going to a conference, sorry conference and into a company that obviously has these 10 times engineers so would you recommend not going there. The 10 times engineers or 10 times engineers. Well, you know the 10 times engineers the the ones who like to show off and Well, that's a, I mean, that's a big question. Probably not but there's also I think value in trying to, you know, to, to, to be sort of a force for change in in a community or in a workplace if you will. So, it really depends. Like, it also depends like how, how, how you are. Like what your approach is and how, how resistant you are to these kinds of things, you know. So I guess it comes down to personal preference but I would, I would, I would probably avoid that. Okay, thank you. So let me play the applause. I really like the fact.