Happy Friday everybody, you're listening to another Friday refill episode of Televative. My name is Jonathan Cutrell. If you're like me, you have a list of best practices. These are things that you use as heuristics, ways of determining whether you are acting in an appropriate manner or not. And when I say appropriate, I mean in a way that's going to produce something good, some good code, for example, maybe a highly functioning team, these are rules that we follow. These heuristics seem to be totally removed from our context. And usually that's because they are. We follow heuristics like dry and dry principle, or even really any principle of coding that we follow. But we also follow other heuristics. One of the heuristics that I tend to follow, the best practice rules that I tend to follow is to document things and to provide some kind of thorough documentation. And it's easy to believe that by following these rules all of the time that by doing that, we are going to ultimately produce better outcomes. And it's not an unfounded idea that if you did follow these rules all the time or most of the time that many of your outcomes probably would improve. But we're ignoring a big question, we're ignoring a big question. When we follow our rules of thumb, our heuristics, our best practices, whatever you want to call these things, when we follow these to a T, no matter the situation. That question is when? When is this particular rule most effective? Or even applicable to begin with? You've heard on this show over and over that context is critical. And when is one of the kinds of context that is critical? In fact, when you ask the question when, the answer usually isn't just a point in time. Typically, the answer to a when question we are applying it to best practices is actually asking a variety of context questions. When is this applicable? Well, when x is true or after, you know, some event, why? After or before some event, z, maybe it's true only when your company size gets to a particular point. And these different kinds of thresholds or conditionals, they're critical to understand. Because sometimes if we try to apply these best practices that we've learned, for example, you should always write documentation. Now, this might be applied at the wrong time. Perhaps you are very early in your company's history and the code base is changing incredibly rapidly. And documenting the code is actually not going to pay you back in the measure that you've invested in it. And I realize this is going to be a very contentious opinion. But you might as well have spent that same time changing over the code base that you just documented. In other words, that documentation is going to be stale so quickly that the diminishing returns that you spent investing into making that documentation a reality. Very quickly are that diminishes to zero. Right? It's close to zero. Even if the practice was beneficial for you. So understanding that, zoom in for a second on that. If the practice is beneficial, we have to kind of set that aside. Right? Because some of the practices that we engage in as a result of the what we're calling best practices here, improve our ability to do those things in the future. So if you're practicing writing documentation on a project that documentation has diminishing returns on, then you have a different kind of value generation. Right? You're practicing because now in the future, when it's time to write the documentation, you have the experience of doing that. And this is true for any kind of practice, really. Right? So you have to evaluate these things as separate concerns. One concern is the practice itself actually going through those motions, developing the muscle memory, developing, you know, there's neural connection. So you know what it feels like to refactor your code, for example, right? What it feels like to follow these heuristics. That way, when it's time to follow them in a higher stake scenario, you have that muscle memory there. You know how to do it. The value generated there is very different from what we're talking about when it comes to this context question of when. And the critical thing that I want you to take away from this episode is that best practices, best practices are tools, just like anything else. And using wrong tool, right? Using the wrong tool, even at the right time, this is the kind of mistake that we're most used to. We want to choose the right tool. We've identified a time that is correct. We've identified a situation that is correct. And we want to choose the right tool and we end up choosing the wrong one. This is the kind of mistake that we are most familiar with. Right? This is the kind of thing that you could do a write-up on that'll make the front page of hacker news because you chose one route and it was very clearly the wrong route. It was the wrong tool you should have chosen another tool. This is a very easy thing to comprehend. A much harder thing to comprehend is when we are making mistakes of choosing the right thing for the wrong time. When we are pushing for extensive documentation at the wrong time, when we're pushing to refactor code that is going to be disposed of in a week. All of these situations are about context or about asking that question of when. When is it appropriate to refactor your code and developing good criteria will help you understand and here's a really critical thing. As you move forward in your career, as you develop expertise, you'll begin to instead of just following those rules blindly right instead of just taking those heuristics and performing the actions related to those heuristics, as you learn the criteria, the context where those particular best practices are applicable, you'll begin to understand kind of the meat, the guts, the reasons why those best practices exist in the first place. You'll be able to derive why it makes sense to refactor code rather than just refactoring it as another task in order to kind of check the box that you follow the best practice. And this is the reason why paying attention to context is so important. It's not because you want to understand the context thoroughly on its own. That's not enough of a reason. Understanding context is what informs you of what you should do next. Understanding context is what will give you the grounds to develop expertise without understanding context. And if you're just applying rules blindly, that is not going to be the mark of excellence. You're not going to become an incredible engineer by just applying rules. You can succeed in a job by applying rules. That's be very clear. If you're doing that right now, it's likely that you are going to be successful for the time being. So don't stop applying them just because you heard this episode of Developer Tea. Continue applying those rules. But start to ask the question, what is the context where this particular practice, this rule, this heuristic is most effective, is most appropriate. And similarly, what is the context that would disqualify this as an effective practice? When is this a bad idea? Even though I've kind of developed the the mental model of this particular behavior like documentation is a great example of this. Most of us have a positive mental model of documentation. There are times when that documentation can turn into a bad thing. A strange is it seems disqualifying these various tools that we have in our tool out is just as important as practicing with them. Thank you so much for listening to today's episode of Developer Tea. Another Friday refill. Make sure you subscribe in whatever podcasting app you're currently using. So you don't miss out on future episodes of this show, including the one that will come out next week. Thanks so much for listening and until next time, enjoy your tea.