Jamaica real time feedback into the behavior of your distributed systems and observing changes exceptions errors in real time allows you to not only experiment with confidence, but respond instantly to get things working again. Code welcome to my talk. The five developer principles that help me as a new father. You won't believe number seven. Let's start with the elephant in the room. The title the joke here is that I'm a tired father and forgot how to count. Not that funny, but I'm a developer, not a comedian. Let's meet our criminal. This is Gil, but don't let his cuteness fool you. As we will soon see, he can make your beautiful designs from elegant to a mess in a matter of minutes. But before we dive in further, a little bit about myself so I'm a developer for years now, but the most important one is that I'm a new father for two. And the first year as a father, you are very, very tired because you need to do a lot of things. You need to keep working and also be with your son or daughter. And it's hard. So I got to a point where it was so overwhelming and I had to do something. And I'm a developer, so I used principles that I used in the everyday work as a developer to make my life much easier as a new father. Right? So let's get started. So monolith design so this is not me here, obviously you can see from the picture, but also because my house looked way worse in the first month when we came back with Gil about two years ago. But this is what our application usually looked like most of the time. If it didn't happen, it will happen. That's okay because we want to move fast, but once we reach a certain level, this mess start to affect our productivity. The main point as a new father is that you are tired. You can fix everything around the house. You need to prioritize. So these picture is where we will start off our journey with a set of the five developer principles. So, spoiler alert, I'm going to tell you right now. What's the key takeaway that I want you to take from this talk? The first one is to fight coupling as hard as you can. Of course, when it's applicable, that will greatly help you down the road. The second one is to keep your code as simple as you can and also be kind. I don't mean here that you need to be kind in code reviews, even though you should, or to say good morning in the morning when you first ask for something on slack. Also remember the no hello hashtag what I mean here is to be kind when you are writing code. I will explain it further in these talk. So this is where we are going with this. We will talk about each of these principles. We will start with definition, code examples, and then my home example. Let's get started. All right, so the first one is these single responsibility principles. The idea behind the SRP is that every class, module or function in a program should have one responsibility or purpose in a program. Let's start with some code examples to illustrate it better. This code might look okay, but let's highlight some potential issues. First one is these function name. It does two things. It also gets the user and the location. You can see from the style that this function does two things. Always remember if there is an and or an or in the function name. Something is fishy here. We can also see that in order to get the location, we must use the user object with its ip. But why? At the end we return two objects that are not necessarily related. So let's try to fix that function. First we extract the logic of the query validation and normalization of the user into its own function, which will be easier to also use in other places. Next, let's do the same with the location. You can see that now we don't need the user in order to get this normalized or enriched location, just an ip that will give other developers or yourself the option to use that function when you need it outside of this scope and not needing the user id in order to get it right. And here we have it, the modified version. Now we have two function that does one thing right. So here we can see my living room. It's a typical end of the day state. There are a lot of things going on here. The toys are the most obvious. But why is the trolley here? Why is the laptop on the sofa? Why are there dishes here? What's going on? Let's move those to another place and keep the living room for adults. Kind of all right. So we moved like it's neater, right? It's neater. And the secret here is to move most of the stuff out of the way at these first stage. You can still see some toys around because this is also Guild's house. But they are on the side. And not all the toys are here. I moved them to their own place. It's Guild's room. I also moved these trolley to the storage, the dishes to the sink. And I just left the computer there because I work these as well. Next one is the boy scout rule. Leave your code better than you found it. So you are tasked with adding a new function that should calculate some profit. Well, what do you do? Well, adding the function obviously with test is what you are paid to do. But what about the rest of these code? We can see here that down below that there's these place to add the function and above it's the already written code that you need to add to. So what can we do here? So there is a grammar issue here. That default date. Got a typo. How about we fix that? Cool. Also, what is ACC? And row? What is r? If someone just went into this function, will he know what that means? So we are changing the ACC into total income, rho into expensive, and r to expense. But this is highly improved the readability of this function. So this is the usual case when I go camping with my family. So we are set in our camp and obviously we clean after ourselves. But if these are some trash around us, even though it's not ours, we will still clean it because it doesn't matter that other people left it. We want to keep the world with less trash as much as possible. This is the original voice cut rule, right? So let's continue. The next principle is keep it simple stupid, not saying stupid. The more complex something is, the more ways it fails and the more difficult it is to explain to someone else who actually needs to understand it. Let's look at some code example. So this might look like a good idea. You have one function that holds all the logic to calculate a specific section did the invoice, but in reality it will get very large and very hard to understand when we'll add more logic into each section or add new section. In reality, these function is hard to test as well because you need to know every piece of logic in this long function, because you need to run the whole function every time. So let's try it in another way. Here we split our calculate per section function to have a function for each section. The above logic is responsible to take each section and use it how it likes. And also we can add test for each section. And by the way, the added benefit here is we can actually change the order of each section if you want. For invoice, let's talk about our home example. In my house when the baby can't find its pacifier, you can buy, and I bought a lot of pacifier, stash them everywhere, closet, everywhere, in the bed. Or you can just put a strap on it. Problem solved, right? Let's move on to the next one. You ain't going to need it. Always implement things when you actually need them, never when you just foresee that you may need them. Let's say that we need to add a new feature, a function that accepts a user id and return the user from the Db. How should we implement it? Let's give it a shot. I'll give you a few seconds just to briefly look over it. All right, so this is even not the worst case. I call reviews and even admittedly myself, but I want to have something that will actually fit on these slide. So unless you already have the infrastructure above because you needed it, there is no need for it. But what is actually wrong here? Let's find out. Why do we need an interface, this base repository, just for a get method? What do we get here? Other than the thought that maybe down the road it will help us? Right? So now it's simpler and we remove the code we don't actually need. What else is there? Why do we need this prisma orm here? So I actually removed these additional code that we actually need to implement in order to use the Prisma right here. Like there's a whole infrastructure code in order to get prisma to work. Why do we need that? We can just remove the OrM code and use SQl, what's wrong with that? But also, why do we need a class? Can't we just use a function? Right? I think it's far enough that we went with this, but just the before and after we started with this whole base repository that the user repository extends from with an Orm and we got to this. But how does that relate to me being a new father? So this is a very short list of stuff these baby should taste and eat from birth to approximately one year. So I bought special cups and created spreadsheets for all these stuff that he ate. So I will know if he's the only child in the world that is allergic to salt. He's not and most children are not, but at the end they just eat from the floor, so you ain't going to need it. All right, our last principle is the tell dont ask. So the tell dont ask principles suggests that it is better to issue a command to perform some operation or logic rather than query its state and then take some action as a result. So let's start with these initial example. I will also give you a few seconds just to briefly look at it, right, so we can see that somewhere in our code base we are checking if a task is not started created before January 2022 and there is no subscribers to this task. If that happens, we should just close the task. But what is wrong here? We are asking the task for some information and then we are closing that same task. Why do we care about that? That seems to be the task responsibility to handle that internal logic, not the color itself. Let's see how we can improve that. We move the internal logic of the task inside task class. That way the client who wants to use that task object will tell him to close the task rather than ask for more information before doing that. I will finish with the best tell don't ask person. I know Gil. He isn't asking for nothing. He demands my attention. He will not stop until he gets his way. But one final advice on that don't ask on the tell don't ask. If you should do the dishes, do them. Dont ask for it. Thank you for watching and for all you new parents. We are in this together. You can find me at Twitter, at hashtag benitool or just send me a message via email. Goodbye and thank you.