Happy Friday everyone, I want to start today's episode with a very simple question. What code should be the cleanest? What code should be the cleanest in your code base? I'm going to give you a moment to answer this question and in lieu of a sponsor I'm going to tell you about the teabrag challenge. If you haven't signed up I encourage you to go to teabragchallenge.com. This is a daily soft skills exercise that gets delivered to your inbox. If you like Developer Tea you're going to love the teabragchallenge.com. Go and check it out teabragchallenge.com. So what code do you believe should be the cleanest? Part of my goal on the show is to help driven developers do better work. And this is the kind of question you should be asking yourself. Not all code gets the same treatment. It can't. There's so many different contexts and so many different types of problems that you solve. And the way that we treat code shouldn't be always exactly consistent. This wouldn't reflect the kind of efficiency that we want to have as developers, but it also doesn't reflect the reality of the point of the code that we write. And so some code is going to get treated differently than others. So I'll ask it one more time. What code do you believe should be the cleanest? I'll give a very short definition of clean code. This is by no means a comprehensive definition. And of course it is given kind of a macro context. Everything you have to consider the context for to decide what is clean in a given scenario. But for the sake of our discussion today on this episode, we're going to define clean code as code that is tested, that is small enough to understand, that is well documented. It's not stale, that doesn't have, for example, unused declarations. It has a reasonable naming. And kind of the hallmark is that a developer who has never touched the project before can come in and with any reasonable amount of time start making changes confidently. Okay, so that could be its own episode. Of course we can talk about clean code for the rest of this episode. But instead I want to talk about in light of this definition, what type of code do you believe should be the cleanest? At first it seems that the intuitive answer is the code that is going to be around the longest. The code that makes up the foundation of the system. And the reason this is intuitive is perhaps not surprising. We don't want to base all of our work on difficult to read code. But the truth is that the clean code definition that we've described and the most common one of being able to easily and confidently change things, right? Being able to add new features, change existing features, adjust an interface, for example. That definition of clean code suggests that the clean code should be the code that is most likely to change. The code that has the most churn. The code that's touched most often and perhaps even more importantly, the code that is touched by developers who are new to the project. And there's some simple reasons why this is the case. Even though it's not very intuitive that you would spend the time to polish, supposedly polish this code to make it clean, this is actually the most economic decision that you can make when you're trying to decide where to put your energy in your code. Let's think about it as a statistics problem. Given a set of changes to a code base, let's say 100 changes, we would like to minimize the amount of energy necessary to make those changes on average. And so if the majority of the changes are happening in a high-churn part of the code, then it makes sense that we want the high-churn part of the code to be easily changed. So if for each change that you make in a high-churn part of the code, you add some constant and relatively predictable factor of refactoring, making that code clean before it actually gets moved into the code base, then assuming that that constant factor that is necessary to make the code clean beats out the variable factor of working with unclean code, then it's a reasonable investment. Now the question is, how much investment is it to make the code clean? And this is where the magic of some kind of compound interest starts to occur. As you clean the high-churn code, the next pieces of code that get added are naturally going to be easier and lower energy to remain clean. Getting clean code to a dirty code base is, let's say, 5 out of 10 on the scale of difficult. Changing dirty code to be clean in a dirty code base is much more difficult, we'll say maybe a 9 out of 10. Adding dirty code to a dirty code base is probably a lower difficulty factor. And this is why it occurs, perhaps a 3 out of 10. But the interesting thing is that adding clean code to a clean code base is also a lower factor, perhaps similar to adding dirty code to a dirty code base. So the economics of why we add dirty code to a dirty code base are similar to why we would add clean code to a clean code base. So it's definitely true that this takes some effort, and perhaps most importantly, it takes an initial extra amount of effort. You can think of this as kind of activation energy, that extra push to actually get the ball rolling in the right direction. But if you think about the long run, if you think about the predictability of your code base, especially in areas of high turn, then you're much more likely to see the value in making the new code and the new changes you make, the highest quality that you can. If the old code is touched once or twice a year, then it's a little bit easier to stomach the variability of the predictability. So the simple lesson in this episode today is to focus on making the high turn sections areas of your code bases the most predictable. However, you can make something easy to change. Clean. You should focus on the highest predictability being in the most valuable place. And that is the place that gets changed most often. Thank you so much for listening to today's episode of Developer Tea. Once again, I encourage you if you enjoy these kinds of discussions, then I'm certain you will enjoy the T-Brig Challenge. Go and check it out at tbrachallenge.com. Thanks so much for listening and until next time, enjoy your tea.