 Not really, not really, let me know how this sounds, don't look convinced, okay testing again, one, two, three, four, five, nothing, I should have wore a shirt with a collar Is this okay, can you hear me? Okay, let's see if we can do any better. I wonder if this improved anything. I think this was the best. How's the volume now? Okay, testing once more, one, two, three, test, one, two, three. I'm just gonna keep on talking until I get any feedback. Okay, awesome, thank you. Excuse me. Yeah, are we waiting for the moderator or to just start? Okay, I'm waiting for him. Good afternoon. Good afternoon. My name is Simon. Our next speaker is Alan Murienic. Murienic. Murienic. He is presenting automatic for the people and I'm sure he can introduce his talk better than I can. If you have any questions at any time let me know and I'll get I'll deliver a mic to you. So, hey, good morning. Welcome to DevConf. I'm Alan Murienic. I'm a senior manager at Synopsys where I manage the Node.js and .NET agents for Seeker which is probably the best I asked product out there but that's not what I'm gonna talk about today. First of all, I want to apologize for those of you who saw the title and thought this is gonna be about the greatest rock music of the 1990s. It is not. If you are expecting a talk about that, feel free to leave. No hard feelings. If you're still here, what I do want to discuss is the realization I got in the last couple of years. So, at least for me and possibly for all of you, as we or as I advanced in my career, I found out that less and less of what I do is actually coding and this doesn't matter if you're an engineer and you're being promoted to senior or principal or staff engineer or whatever they call it in your company or unofficially if you move up the ranks or the so-called ranks in your excuse me open source project and become a committer or maintainer or even God forbid if you turn to the dark side like I did and become a manager. Less and less of what we do is coding. We're suddenly expected to do all sorts of things like define policies and do code review and mentor people, all sorts of soft skills. I have absolutely no idea why I call these soft skills. They're really, really hard to do and most of us or sorry I will not speak for all of us. I personally am just not good at these things. I've come to meet a couple of engineers that share the same problems. Excuse me and even if you are naturally good at these things, you just don't scale. We're just humans. There's just so many hours a day and some of us also take some of these hours and do other things like sleep or interact with your family, things like that which takes away even more of your time. So we're kind of in a problem here or at least I am. The good news is that as engineers we are really, really good at coding. At least I hope we are. Otherwise we're in the wrong profession. What I'd like to propose today is perhaps a mind shift of how we take the skills that we are naturally good at and apply them to this new problem of soft skills. So how do engineers solve problems generally? We automate things. This is just what we do and what I'm going to talk about today is how we apply this mindset to, as I said, a different set of problems. A short disclaimer. I'm not going to discuss any specific technology or any specific framework. If I do, this talk will quickly deteriorate into a traverse versus circle CI versus Jenkins talk. I have a plan to catch in about 10 hours so we won't go down that route. There's a bunch of project logos here which are all links to the respective projects or share the slides afterwards. Just feel free to check them out. The second disclaimer is I'm probably not going to show you anything new. I'm probably going to show you things you already know, already do, and just I want to get you to think about them in a somewhat different perspective. For example, why do we have unit tests or why do we need unit tests? That's like an open question to the crowd. So the wrong answer is to find bugs. Another wrong answer is to prevent regressions in the code. Excuse me. Well, not exactly a wrong answer, but an incomplete answer. This does not address the issue of soft skills. From a soft skill perspective, unit tests are a way for me to document my software, to document how it's used, how it should be used, and what I care about when I develop it in a language that's really easy to share. A lot of projects, sorry, trying to document the code in this awful language called English, if any of you have heard about it. English is a horrible language. It's full of ambiguities. It's full of double meanings. If you ask two people from two different sides of the Atlantic Ocean, they can't even agree on how to spell stuff. Have you ever seen color with a U? Some people do. And worst of all, for a lot of us, English is just our second or third language. Now, if I want to contribute to a project, let's say in Python, I suddenly need to learn two different new languages I don't speak, Python and English, which doesn't make a lot of sense to me. So if I can just learn one language, Python, and get the documentation in that language too, it's much easier to transfer knowledge like this. So from a junior engineer's perspective, when I am introduced to a new project and when I read through the code, I want to only read through the actual code of the project. I'll read through the unit tests or system tests, integration tests, whatever. And this will kind of tell me what considerations I should care about, how different parts of the system are already used, how they should be used. This kind of hints to what I should be doing. As a senior engineer, someone who reviews new code, I now not only review the code, I review the tests which are submitted in it, with it, sorry. And this is kind of a shortcut for me. It takes away a lot of these conversations of have you thought how your code behaves in a multi-threaded environment? Have you thought how this code handles different encodings? These are really easy questions. If you have a test for it, you thought about it. If you don't, you did not. And since we like to automate things, code coverage tools are your best friend here. Now, I'm not saying every patch can have 100% coverage. I'm not necessarily even saying that every patch should have 100% coverage. But if I review the coverage report, this is, again, another shortcut for me to find the glaring blocks of code which are untested. And I can give this quick feedback, hey, look, this part of the code isn't tested. You may want to look back at it. So unit tests are kind of an obvious example of this. Why do we need linters? The wrong answer is to make sure the code looks nice. Has anyone ever had this discussion about tabs versus spaces? Does anyone know what the right answer to tabs versus spaces is? I'll give you a hint. It's not spaces. I'll give you another hint. It's also not tabs. The only right answer for this discussion is not to have it. Because tabs versus spaces isn't a technical discussion. It's a religious discussion. And like any other religious discussion, it's fine to have it, but you won't convince anyone. If you aren't pro tabs walking into the discussion, you won't be pro tabs walking out of it. Linters are a way of not having these discussions. First of all, linters are a way of documenting a consensus we already have in the project. And a consensus can be reached really early on when there's a single contributor. And then that consensus is really simple. I decided to use spaces. This is what we're going to do. You can document this consensus in a configuration for a linter. Check this in as part of the false code. And from now on, you are not having this discussion anymore. Every patch that's submitted gets run through the linter, automatically fails if it doesn't adhere to your standards. And that's it, problem solved. Not only does this save time for me as a senior engineer that needs to review stuff, it saves time for the junior engineer that needs to submit a patch. Has anyone ever submitted a patch to a project he didn't know as a junior engineer? So you submit it, you wait a day till someone takes a look, get 25,000 different remarks, please remove trailing white spaces. Take your patch, remove 25,000 trailing white spaces, submit the patch again, wait for another two days till someone takes a look. Then someone does says, yeah, well, we like our curly braces up here and not down there. So you go through that again, wait another two days. And a week later, you finally get an answer. Yeah, you know, what this idea can't work. You just wasted the week of your life. If I could get this feedback immediately from my local build, I won't even submit a patch with these problems. I'll get the feedback, effective feedback much faster. Also, from a perspective of someone who needs to review the patch, I then go through four cycles of mindless reviewing of I can't look at this patch, this tabbing is all wrong. I can actually focus on stuff I care. Now, most of these tools are highly configurable and you can tweak them in whatever way you want. Most of these also pretty easy to extend or quite straightforward. The tool passes the code, you get back an AST and it's usually pretty simple checkers that go over the AST and either fail or don't. But so you can add your own rules. But even if you aren't using a tool like that, these are immensely useful. As someone ever used to go fmt for go. So I don't quite remember the phrasing, but it says something like go fmt forces a style which nobody likes, but everyone can agree upon. They just took away the entire argument, which again, just saves time and makes us easier for all of us. My personal favorite, why do we need static analysis tools? So kind of like a hint here. But this is the wrong answer again. Static analysis tools from a soft skill perspective, a really quick hack to amp up your knowledge. Even us so called senior engineers don't know everything. We can't know everything. The world is just too complicated. And we can't think of everything. Static analysis tools, if you think about it for a moment, is just this massive knowledge base where a lot of people who are usually experts in certain really small field, like synchronization issues, or encoding issues, or I don't know what, took all this knowledge, coded, coded some simple rules, simple best practices, rules of thumb into an automatic tool. And now I don't need to know everything about everything. I kind of have a mind trust encoded in my software helping me. And this isn't just for genius engineers. Even as a senior engineer has been doing this for over 20 years. I still found myself learning new things from fine bugs from spot bugs, definitely from JSC and just by doing something a bit different in my job and exploring something I wasn't very proficient in. Like, hey, wait a minute, these guys are right. Never thought about that. Did my deeds for the day, I learned something. Check. And of course, this has a much higher effect if you're a relatively junior engineer that doesn't have so much experience. Also, as a senior engineer, as someone who needs to teach and impart his knowledge, the key point here isn't the tool. It's usually the ability to configure the tool. A lot of the most of these tools allow you to say what type of issues you care about or don't. There should be errors or warnings per file per module, per directory, per whatever. And these are more than just personal preferences. If I configure my tool to ignore synchronization issues, it's not me alone saying, yeah, I don't care about synchronization issues. This is a codable way of me to transfer the notion that this is a simple utility library. We don't care about synchronization issues here because we don't have enough context to do so. We don't know where we are being called. A caller needs to do this. And by configuring these tools, I again, share this knowledge with my junior, junior colleagues, and practically with people who are going to use this library too. Once you kind of get over this hump and stop thinking about these tools is just how I'm how I make the code better. Once you start thinking about them in the sense of how can I share knowledge, how can I offload mundane tasks off of me and have someone better do them, someone better being a computer. There are a world of tools out there. Far past these three categories I discussed. For anything and everything for spell checking, which is kind of obvious, we all grew up using spell checkers. Not enough of us do this in code. Have you ever had a blocker bug on the last day of the release because someone had a typo somewhere in an error message? Yeah. So million lines of code. 40 minutes before we are supposed to release one blocker bug about data corruption. Someone else will handle that. And the typo and an error message. Absolutely no reason to have these. Licensing if you want to make sure that all the third parties you use and all the third parties they transit transitively use have compatible license to what you want to do. There are good tools that do that. Accessibility. Things are good talk about. Unfortunately, right now in a different room. But do you make sure all your images have alt text for accessibility issues? I never remember to do that. But I have a tool that helps me. Top end to the point. Security issues, which is kind of what I'm doing nowadays. Security is very interesting field, which frankly, not a lot of people get properly not a lot of people get at all. Those who do a lot of them do not get it properly. Those who don't get it properly will usually brag how the software is secure because they did X, Y, Z. And of course, I have no idea what they're talking about. And it costs excuse the French a crap load of money to have a security expert shadow every developer. Let's have a tool do this. And so on and so on and so on. Basically, if you can think of anything, mundane, repetitive, which a computer probably can do better, a computer can do better. And the probably already is a tool for this. And if there isn't, please go right one. Please ping me up afterwards. I'm always happy to contribute to such projects. One of my pet peeves in my free time. Well, so I can't finish this without the obvious lesson. Never believe anyone presenting in the conference. We're all liars. I said I won't talk about specific tools. I will. The one tool I just have to mention is editor config, just because that's so awesome. So editor config is an open standard, which allows you to really easily configure how you want your source code to look with regards to tabs, spacing, new lines, position of brackets, etc, etc. It supports any programming language I can think about. Any reasonable ID supports us. For those of you asking, yes, VI and VIM are IDEs. They both support editor config. So either natively or with a plugin, I can't imagine an editor nowadays doesn't that doesn't have a plugin for this. So you just it takes about 10, 15 minutes to write a config file, just check it in with your source code. From that point on, anyone checking out a project, no matter what he's using, he or she is using will format the code the same way. And you get rid of all these stupid arguments. But it looks quite in the clips. Are you opening it in IntelliJ? Come on. It's not 1995. We should not have this argument anymore. Problem solved. This is the one tool I will specifically and explicitly talk about. One last lesson or one last point I want to make is there's a proverb about the early bird getting the worm. And in our context, the earlier we give this feedback as anyone who's done a team lead training or something awful like that will know the earlier you give the feedback the better. Earlier in our context is the earliest possible in the development cycle. A lot of these tools will integrate into your ID. And if I can write my code and as I'm writing get warning saying, hey, look, you should have done this. Hey, look, this is a problem. This is great because I'm already writing my code. I'll just fix it as I go. I don't need to think about it. If you can't do that, at least have your tools run in your local build. So I can write the code, run the local build, make sure it's okay, then submit my patch. If you cannot, even if you can do that, the next level of feedback is unsubmitted patches. And again, regardless if you're running Traverse or Circle CI or Jenkins or a little gnome who executes things, doesn't matter. And so this way, I submit my patch and get back some feedback. Hey, look, you failed to unit tests, your indentation is wrong, blah, blah, blah. Even if you do have all of these in your local build, please, please, please leave them in the CI also developers or horrible people. I know I am one. If I write code and some tool prevents me from compiling it. Chances are, depending on how much coffee I had today, I'll just remove the tool from my local build instead of fixing it. So please, please, please have this in your CI regardless of if whether it's available or not in the local build. And of course, if you don't do that, you can always fall back to running stuff periodically or nightly, which is not a bad idea, but doesn't really, doesn't really have the same effect. I won't name names here, but I used to contribute to an open source project which had a release every quarter, give or take. And once a quarter, we would all get an email saying, okay, we are about to release in two weeks, we run, we ran find bugs on our code. Here are the 260 errors. Here are all the issues with licenses, et cetera, et cetera. If any of these look familiar, please fix them. Two months after I submitted a patch, I have absolutely no recollection of what I did, no way to correlate errors to code. What usually happens is some poor sub usually me ends up once a quarter going through tons of errors created by other people's code and trying to fix them without having any idea what he's doing. This is awful, please do not do this. So I've covered quite a lot of grants here. Chances are you won't remember any of this. People usually remember one sentence from a session if the presenter is lucky. So there's really just one thing I want you to take away from this. As software engineers, as senior software engineers, as we progress, our job becomes not only to make the code better, but to make the other developers around us better. If you think your job starts and finishes with the code, you are wrong. Luckily, we can use the skills we have as developers to help us with this new job, even if it isn't just about a code. With that, I'll open the floor to questions. It's not a question, but just a remark. I've been lead of projects for 10 years, and we have about 30 different developers going in and going out. We just two years ago started discussions about coding styles, etc. We found that just having discussions helps quite a lot, because there were some frictions we didn't know about, people that didn't want to touch other people's code, because it was that person who uses British English, I use American English, etc, etc, etc. And just having those discussions help quite a lot just to have everything on one plane if it's possible. But sometimes we just have to say, okay, we can't agree on this than different developers have to do different styles. But I think quite a lot of people are just scared of having discussions, because it's like everyone has to do their style. But sometimes it's actually possible to agree. Okay, so I'll maybe refraise something I said earlier. I'm all for discussion. I'm all for communication. Having discussions is great. The problem with ease is they don't scale. It's great to have this discussion and decide we use British English or tabs or whatever. It doesn't make sense to have this discussion every single time a new developer joins. So we kind of got to a point and now a new developer joins and says, Hello, I like tabs and I'm going to write in Australian English. Why? Because we just can't keep on having these. We need to reach a consensus documented in a way that will actually fail you make you make process. And then it's kind of obvious. You don't get into these discussions on why we're using British English. No, use British English. You will see for yourself the code just does not build if you do anything else. Let's stick with that. Can you say the takeaway again? So the takeaway for me is one sentence. Our job as developers isn't just to make the code better. It's to make the developers around us better. That's one sentence. Okay, so with that, I will thank you for your time and enjoy your lunch. Thank you.