Hello, hello, hello to all the brilliant souls on the another side of the screen. I hope you're doing great. At first, let me introduce myself. My name is Denis. So, as you can see, I've been in this field for quite a while. Long enough to have caught HTML for an escape navigator. I imagine some of you might not even know what this is. And it's perfectly fine. no worries here. there have been many interesting developments in those days. I've worked in numerous roles here and there, but always within the tech industry. Along the way, I earned some badges I found really handy and fancy, like Associate Coach from the International Coaching Federation and Professional Scrum from Ken Schwaber's Scrum. org. And, long story short, I'm currently a contributing engineer at a tech startup. We're developing project portfolio and program management software. So, yeah. for the banking industry. And, today I'm going to bring out some insights I found available to share with you. when considering sustainable software development. So, let's go ahead. You know, whatever is suffering, as Buddha said, but, I suspect software engi software development is the real cause of the problem. I see that, coding is actually a relentless choice between bad and worse. you know, many of these delays, microservices, or monolith service side render, or client side render, space complexity, or time complexity, making a call, or sending an email, and so on and so on, thousands of them every day. Let me simplify here. Imagine the code you write every day is just a set of words translating business requirements into machine code. So, here I suppose coding is simply communication. Communication causes a lot of issues. I didn't get it. I forgot it. I didn't hear it. maybe I don't like it. Familiar situation, innit? If we agree on the idea that coding is communication, then corollary one is the best code is no code. And I would like to show you how complexity arises from absolutely nothing. So, have a look at this. It's quite an ordinary situation. We have a page with a footer. It's here. Footer. And, we want to add some copyrights, some copyright block here. With dates. Let's do it. Like, 2024. Denis Ermakov. All rights reserved. Let's check in the browser. Refresh. Something goes wrong. Perfect. it's here. We, we can see a photo. We can see a photo here. but, what if the new year comes? May wonder a newbie engineer. we need some automation here. So, let's do it. New Year comes, like that. Let's say New Year is current year. New Year is current year. Let's define the current year. Let's check. Let's check. Yeah, it works. It works. It works. So, that looks great. But, wait, what if someone else, will use our great solution? and it might happen another year and we don't know. What's here exactly? So let's help them. let's say they started it. Started using it at the start year. Let's define start year. Let's say it started the same year. Let's check. Oh, something goes wrong. we can see 2025 twice. That's a problem. we must fix it. Let's check. I did it before to save our time. There is solution. Let's check in the browser. Perfectly, it works. Let's check another case. Let's start with 2023, fresh. Yeah, it looks great. We fixed the problem. But wait, there was no problem to begin with. We add some code, conserved a problem, and then we fix it. That's absolutely, absolutely no, no sense. Imagine, nobody dies if there is no code at all. Nobody loses their fortune if there is no code at all. Absolutely nothing happens. No code, no problem guys. Let's fix it. Let's fix it. Let's fix it. Yeah, we did it great again. Fantastic. Let's go back to the slides. Go back to the slides. so, here is another example. there is a simple GitHub flow. Someone pushes to a repository. which triggers a linter to run, and then build runs, and finally the deployment happens. So, let's, let's see, let's see, what do we have here? That's, that's a GitHub action described in YAML format. So, we have, push to stage, and then we run some lints. When we run build, if everything okay, if everything okay. here, everything okay on success, we'll send message to Telegram channel, and if something goes wrong, if something fails, we'll send a warning message to the Telegram channel. Looks fine, good enough, not really a newbie engineer might reply, they don't want broken code in the staging branch, they want to revert the broken code, hmm, let's check. There is, adjusted GitHub action. It, does the same thing, but there is a reversion, a reversion on fail. So we added one step to robot comment, and then if everything okay, we'll send message to telegram. Fine. We fix the problem. Yeah, we fix the problem. But wait, what? The previous committee is also broken. Let's, run linter and run build one more time to check if it's okay. So, the same extended or adjusted action. So, we revert last commit. And then we run, we run lint and build. So, and then we send telegram message. Fine. Hmm. Wait, but, What is, the comet before that comet? Is it also broken? We need to find the last healthy comet. We'll say in UBIngineer. Let's do it. It's easy. So, so here we are. There is a recursive revert and rebuild. So, we have, the cycle whileJune, where we, run reversion, and then we run lint build, and if everything is okay, we'll exit from the loop, and it looks perfectly fine, but, but, guys, are you ready to bet against GitHub, and, are you ready to bet against, possibly an infinite loop? You know, I've played this game before, and I lost, so I can't advise. the idea that we really don't need to cover each cases here. bro, just go and fix the problem in the comment. It's easy. So, let's get back to slides. What is going here and here we have the corollary to The best library is no library. So let's have a look. Let's have a look Best library is no library. So, you know, take a look on this piece of code Here imagine we have a duration in milliseconds Like the time a ticket has been in progress. We want to format the duration in a human readable style. So, if it's too long, we'll print out days. Otherwise, we'll show hours, minutes, or even seconds. So, what will the newbie engineers say? they could say that date objects are really awkward. Wait milliseconds that normal people never deal with. The 29th of February only happens once every four years. The 2038 problem is looming, endless division by 60 and 24. Let's use a handy library like moment to handle days like normal people made. Bro. It's a trap. It's a trap. Let's see. So we have, what we have here, we have milliseconds. We have, function for duration. We have. milliseconds as a, an argument. So we are, we're going to use moment here to convert, in human readable format using human readable methods as second. We, we get milliseconds and, apply the method eight seconds. And we then we took milliseconds and, converted to minutes. We took milliseconds and, converted to hours. And so on, and so on, milliseconds, two days, great, great enough, but, let's have a look, let's have a look, the next piece of code. So, let me, let me do this one. Oh, something goes wrong, let me check, huh. Okay, what's going here? we can achieve the same result, same result, the same function, yeah? Okay. Formal duration. We can achieve the same result with proper naming. We don't need to use library with proper naming. We can just use proper naming in our variables. So we took milliseconds and divided first on 1000. So we got seconds. Next, we divide seconds. And, got means, and so on. Hours, days, the same number of, the same number of lines. The same result. And we have saved 145 kilobytes of collateral code. Amazing. How does it work? I didn't show you. Yeah, here it is. Duration, days, like that. Yeah, so, let's back to, let's back to deck with lights. What's here? Corollary 3. Well, if you still need words to communicate, then code them. There is no need to write long stories in your readme. md or in your wiki or Confluence or whenever. do you have your own unique code style in agreements? Yes. Good, code them into linters and let them run on every command s after saving. let's have a look. So, what's here? Yeah, what, what, what's here? Yeah, there is printer, and there is this lint. So, it's quite easy. what actually happens? you actually don't need to write the number of spaces for your tabs. In Confluence, it's described here in Pre TRC, so you, you can just put them in, in your repository, let them be part of your repository, and, relax. So, it's quite easy, you don't need any words. Add some code and put it in your repository. That's great. So, back to slides again. Corollary 4 is foster your team's dictionary. So, what does it mean? foster your team's dictionary and keep it in your readme. ind. and I suggest to start with done. What does that mean to the team? do you know I sure everyone is aligned on what does, what done means. Let's write it down to make sure what's what, what does done means. What does done mean? So, let's write it. Yeah, readme. What does done mean? So, here is readme. And I want to start with dictionary. Dictionary or glossary. Okay, let's start with done, as I suggested. Done. So, I suppose there are a lot of work items you deal with every day, like rechart. Like, maybe a user story, or maybe task, or even bug. So, let's define, let's define dan for user story. When I said, When I say, then I say a done for user storage, that's mean. for example, the re the Ram Unit tests, unit tests and the coverage, I say 70%. So when I say done, that means there, that means, there, Integration, integration tests and coverage say, I don't know, 50%. When I say user story done, that means there are end to end tests, end to end tests. And say coverage, I don't know, 30%. Okay, what else? When I say done That mean, product, documentation. Done. Yeah, documentation. If I say, if I say done, that means, there is documentation. If I say done, that mean product owner got a video link. With end to end test. And if I say done for user story, that mean that Pure said amazing, guys. So, if Pure said amazing, we are ready to ship the user story. So, we did it. Now everyone knows what does done mean. Means. So, let's, go ahead. let's go ahead two slides. yeah. Remember corollary three, it said, code, code. If you have words, it's better to code them. So let's let, let's, let's do it. Let's code the words. There are a lot of words. something about unit tests. So, let's imagine we already have unit tests. And, we want to run it. And see the coverage. Let's run. Something goes on. Going on. Yeah. Look at that. Come on. Come on. Yeah. Great. We are green. We are totally green. At first. We have coverage. So, fantastic. We can, we can, we can check that it's done. So, next, imagine we are done with integration and end to end tests. So, what about documentation? Yeah? what about documentation here? I need a code. Let's make some documentation. So, I would use I will use robot for that, let's ironman walk, works, give me a type doc, I use type doc, comment, for function format duration, yeah ironman is walking, yeah we have some description, let's save it, and next we need to generate some documents, I use tab doc, The generation is in progress. Yeah. Generation is in progress. Something goes wrong. What? Yeah. Everything is done. Everything is done. Let's check. Let's check here. Yeah. Here is a documentation for our function with comments from Copilot. So, We are done with this function, this item, this item of done, we are done. So, and and so on and so on. there are, there could be any items, any items in your done definition. So, it's your choice. But, what is important about here, now you can easily make this choice a part of your GitHub action, you know. And to save time, I'm going to skip this part. And, what's important here, by the way, speaking of testing, there, you know, there is a mass load pyramid for normal people, and there is a testing pyramid for engineers. And, the Pyramid suggests writing a lot of unit tests, and just a few end to end tests. But, I'm afraid, I'm, I'm afraid we are mistaken. I suspect, it's really telling us, one end to end test is worth a billion unit tests and mocks. So, I prefer one end to end, one end to end test. and, that, is what I Can advise so let's go father We called it. We called it. We called it some words. Yeah, we are here. So We still talking about communication. And if you still have to communicate then Just short shorten the feedback loops you have I Suppose there is the smartest guy in the room Who reviews your pull request once a day And, well, that's good enough, but, what's, about an hour of peer coding session or an hour of mob coding session each day with ongoing peer to peer reviews? that shortens feedback loops and forced sharing of knowledge, you know? So, try to shorten your feedback loops, any, any feedback loops you have in your team. And, you will be wondered. So, about communication, most people feel uncomfortable in uncertainty. Feeling uncomfortable leads to wrong decision. And wrong decision lead to messy codebase. So, how can, how do we handle it? Let's see. Let's see. As a software engineer, you spend most of time, most of your time operating within this triangle. I call it the Manager Sensara Triangle. So, that's a, that's a triangle about money, time, and requirements. So, your decisions are restricted by boundaries of this triangle. But, say me, does it make sense? Make you feel any better? I bet not, very much actually. So how can you, how, how, how can we empower our re resilience? It's, simple. Follow your principles, share them with your team. Enjoy. Sounds simple because that's simple. Principles are something you always carry in your pocket. So, they are always with you. And you can say, what even are principles, dude? What's it, what are you talking about? There are plenty to choose from, and you can pick something from above. You can take some from Scrum, or Java, or Kanban. Or you can ever take something from Prince, if you are a votes for guy. So, just go with the 10 commandments, I've heard they work pretty well, indeed. So, you can pick any system of principles and values, but you should embrace them entirely. That's the key. You cannot deliver 10 times a day and only meet business people once a fortnight. Yeah, that's agile principles, if you're familiar with. Yeah. So, what else? Build your daily routine step by step. Have you ever heard that small, small kids tend to develop attention deficit hyperactivity disorder? If they are, if they aren't properly routinized. That's exactly what you would expect as a software engineer. So, I suggest, fill your day or week with simple routines. Every short day, briefing, paid programming session, maybe mobbing session, refactoring session, whatever works for you. Maybe retrospective or sprint reviews, whatever. And just stick to them. So, few words about bad news, you've already been out if you choose comfortable task or those that truly matter, you spend time trying to figure out the best solution instead of focusing on workable one, or you are simply tired, so I suggest next best action for you, remove one library from your app today, eliminate one item from your backlog next sprint. And, define you're done and automate it, please. So, at least get some rest if you're tired. but, That's the end actually, around the end, don't hesitate to reach me, to reach out to me, all my contact details are on my website, which you can find on the second slide above. And, guys, always remember, syntactic sugar causes cancer of semicolons. Bye bye here.