 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 balsamico sauce. And I guess that's a sentence that you've never heard in your life. And that's OK. We will get to it. But first, let's get 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 I usually look like. Yeah, I like to paint mugs. It's just the thing I do. I have way too many plans. And they seem to multiply on their own. I'm 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 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 fine. 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 a web service developer. So I basically build web services and APIs, mostly with the iOS, GTP. And I kind of like Python. Like, it's OK. 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 sometime in between getting my first engineering job and bringing down my first production database, I basically came to realize that 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. OK, like whatever tool, software, library, process, you name it, there will be somebody who just doesn't like it and is 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. Or OK, it means 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, OK, maybe accept that. But otherwise, it's great. OK, OK, OK, fine. I mean, it has some hiccups, but what doesn't. OK, how can you not like the place that brought us synonyms rules? I mean, there is just no way, right? It's physically impossible. So I mean, so there's a lot of stuff 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 dynamicsing them, right? So people on the internet have opinions about all sorts of things. So obviously, what it means to be a good or bad 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. But 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 this all up 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 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. So this is awkward. I mean, I guess we can all just go home being the mediocre programmers we are. I mean, I like going to conferences, see what other people are doing, what other tech is out there, what other problems there are, what other solutions. But I guess that correlates somehow with me being a mediocre programmer according to somebody on the internet. OK, I hope you will understand if I skip the part where I actually try to debunk this, like considering the circumstances. OK, 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. Please don't do that 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. You can often see hallmarks 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 buy. 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 down. So I mean, to me, this kind of makes sense because reading to your program, unlike 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 chances are that the problem might lie elsewhere. And also, I have basically, I think I have to cut 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, OK, seriously, though, should you get too attached to your program unless you're a debugger, it's probably not that good of an idea. But does being said that your program doesn't work make you a bad programmer? I mean, your guess is as good as mine. So next up, the internet tells us that with the right tools, win-win, 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, a 10 timeser has already streamlined it and is two steps ahead. So there is this tool that will streamline your productivity all for the low low price of 1,000 euro per month. I mean, where do I sign up? I mean, usually I like to have some sort of a need for a tool first, but I guess it's just the case here that this is the pizza scissors of software tooling, right? You didn't basically even know it existed until you found out you needed it. Or is that the other way around? Next up, another sign of a good programmer is that they can complete any sequence of dialogue from Lord of the Rings, Star Wars, or Redworth, or Monty Python. So does Gilmore Girls count? Or are those the only approved shows? Because is it fine if I know all but one season because that one season was written by somebody else and it's really bad and the characters don't act like themselves bad? Like, OK, listen. I like nerdy stuff as much as the other person, OK? But I think it's important to recognize that stereotypes like this can prevent us from recognizing the potential and the value of people who basically do not fall into a need bucket like this. Because nerding out is cool and all, but gatekeeping a bit less. I mean, there are many people who would never even consider programming because misconceptions like these are just so common. Like, they feel like being alert is a requirement. You know, it's like this club. But instead of showing them your ID, you have to do a really good Jedi mind-tracking question. And it's a shame because while being alert is cool. Let's be honest, it has no bearing on how good of a programmer you can be or you are. And nobody should be telling you that you shall not pass. I mean, you cannot get into the club unless you know your elven name, OK? And I'm saying this as somebody who actually owned a set of handmade elven ears in my teens, OK? So there's a reason why I don't write that down on my CV because nobody would be interested. No other reason. If you want to become a better crawler, according to the internet, you should type faster. And 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 Jeff Atwood put it. So luckily, this one is a bit less demanding on memory than the previous one because instead of 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 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 very disproportional to the time spent thinking. So what is more important, the ability to dismantle a problem and find a solution or writing it down? I mean, your guess is as good as mine. Next up. So 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, F, and X are usually worn out more than A, S, and E, email senders. So I do prefer black mode or dark mode, and I usually change the defaults. So I guess that's good for me. But I have no idea what makes I, F, and X more special than A, S, and E. And probably in my case, W, A, S, D is the most worn out keys anyway. But I guess if you kind of make the math, it still makes me 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 ease as writing English. No breaks, no pause, just type. So I have to be honest with you, I'm failing this one so hard. 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 too average for me to meet the standard of some random person on the internet. Let's try to leave again. In case you started programming in your 20s or 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. Now it's too late. All you can be is a normal engineer. So I guess it's not really about willingness to learn more motivation like I thought. I mean, it's too bad. OK, 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 you know, I'm looking at other people's code and them looking at my code and pull requests 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 out later. So don't get discouraged. Next up, one guy, he just graduated and called himself a programmer. I asked him a couple of questions. Have you set up the tooltips of the application? Have you made a setup for your program? Have you set up tab stops according to the flow? His answers were simple. No, no, no. Yeah, I don't know either. Let's just move on. So next up, as proof, believe it or not, I have written one million lines of code in under six months, resulting in a very functional, relatively bug-free, commercial product on the scale of something like Microsoft Office, though totally unrelated. Further, the product was innovative and in fresh territory, as in no competitive products, no answers on Google, which is completely on my own. I wouldn'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 6k LOC a day. The average engineer I've worked with puts out about 500 LOC a day, the best, but not rock stars, put out about 2k LOC a day. So it's not a clear 10 times mapping, but that's 12 times a 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, huh? I mean, you know, I made that joke about being a 3.5 times engineer, like a couple of 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? Like it's the easiest 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 do more often, right? The new shiny thing or like maintain this existing spaghetti code base, like doesn't make more 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 code golfing. All right, let me take a breather here. So the thing about a lot of this kind of advice is that the author basically assumes that everyone works exactly like them. Like 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 the tooltips person. And you know, the worst thing about this is though that the perpetuating basically the myth of a rock star or a ninja or 10 times or a 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 gotta 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 because that's the hidden price of worshiping 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. So let's talk about something else for a bit. Let's talk about food. For example, balsamico sauce or BS for short. I think that we as developers come in contact with balsamico sauce every day. And in my opinion being able to tell whether something is legitimate or balsamico sauce is an essential skill. And unfortunately 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 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? 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 as it will not be very helpful or encouraging. If an article is condescending towards people who do not need some arbitrary standard and this is a fairly large group of articles. I mean, in some cases this might be legitimate, okay? Like I don't know, don't store plain text 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. Finally, if an article tells you to dance around the campfire naked on the sixth 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 random advice from the internet. So you might be like, okay, everybody can criticize but what is your pros and 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 shouldn't, at least not until you apply your own bosomical filters to it beforehand. So that being 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 Git repo with notes, with solutions to problems that took you days to figure out because you will forget what the actual solution was and you will come up, the problem will come up again. And don't be too hard on yourself and if you can stop comparing yourself to others, you just need to remember that for every amazing program you see, what you don't see is basically the days of mistakes and struggling and you basically only see the end products 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 too, of course, but it's more about the attitude. It's more about how the person approaches problems and how they approach other people. It's 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 others from them, that sort of thing. And I think there is one thing that I think really gets underestimated sometimes and that is that whenever we write code with very few exceptions, we are part of a community, right? If, be it 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. For instance, like that one time that you were lazing with 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, if they can get away with it? Or I don't really care about implementing this feature in a nice way because there's already hacks in the cold base. So why bother? And this extends to social interactions too. So your actions set a 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 sight. 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 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. Yeah, 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 pip install this package and it will tell you bonus points if you can get the true ending. With that, thank you everybody for listening. Thank you very much for this very, very nice talk. We have one question from Jill. Any suggestions on understanding during interviews if the company you're joining has engineers like the ones you showed, or the 10 times engineers? So as a participant. Yes. Well, that's a good question. Well, there are things that you can maybe already spot like at the interview, right? You can see what kind of people interview you. You can see how well you get along with them. You can also see what kind of people they are. For example, if there are people from underrepresented groups there in the interview already 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. But I'm pretty sure like you should already somehow feel the vibe from the interview and from the people who interview you. It just somehow clicks and maybe you can ask them I don't know about work life balance and all these sort of things because they tend to go well together with a nice company culture. But I think there are... Sorry, would you recommend going to a conference? Sorry, conference and company that obviously has these 10 times engineers or would you recommend not going there? The 10 times engineers or the 10 times engineers? Well, the 10 times engineers, the ones we like to show often. Well, that's a big question. Probably not, but there's also I think value in trying to be sort of a force for change in a community or in a workplace, if you will. So it really depends. It also depends how you are, what your approach is and how resistant you are to these kinds of things. So I guess it comes down to personal preference but I would probably avoid that personally. Okay, thank you. So let me play the applause. Thank you, really liked it. Thanks, thanks.