As programmers and as humans, we encounter a long list of rules. Sometimes these rules are more stringent than others on this list. Sometimes the rules are reflective of something that we can't bypass. For example, we can't go back in time. This is more of a law than it is a rule. And as developers, we encounter these more often than we do in other careers because there's a lot of subjectivity in what we do. We encounter things like code smells. These are heuristics that we use to uncover things like anti-patterns. These are all ideas around creating good code. And we talked about the subject of nature of even those terms on the show before. In today's episode, though, I want to talk about new ways of thinking about rules, new ways of looking at rules, and using them in novel ways as well. We're going to use some logic to help us kind of examine rules in a different way in today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on this show is ultimately to help you connect to your career purpose so you can do better work and have a positive influence on the people around you. And one of the ways that you can do better work, that's what we're talking about in today's episode. But this is also a way that you can kind of uncover more about the world around you. This is not just limited to rules that you encounter in software development, not just limited to anti-patterns or to code smells. These are ways of thinking, patterns of thinking, creative ways of slowing down your thought process and examining things from a almost a literally new angle. So we're going to talk about three things in today's episode, three angles that you can see rules through. These are new angles. Instead of taking rules kind of blindly, right? This is kind of what the early beginner developer does. And rightly so, when we first learn a rule, we have to kind of practice that rule first, right? In order to contextualize and to grow, to understand the rule, first we have to kind of apply it without really knowing why. And this is supported by research on how people move from beginner to intermediate levels. And we talked about that on a recent episode when we discussed the draface model. But it's important to understand that rules exist to kind of be an easily transferable way of practicing, of operating, of doing. A rule contains sometimes a lot of information. Sometimes the rule is based on years of experiences, years of failures, years of experimentation. Sometimes those rules, those heuristics are based on very little experience, very little experimentation. So it's important to kind of investigate and can flip these rules around. Look at them from new angles. And that's exactly what we're talking about today. So the first new angle that I want you to consider a rule through is its inversion, the opposite of the rule, the inversion of the rule. And I like to think of this as kind of like a color inversion. The inversion should not be a restating of the rule or the heuristic. It should have a new character, right? For it to be useful at least, right? So you want to not just restate and use logical operators to flip the rule around, but instead consider the character of that inversion a different and opposite meaning. Now when I say opposite, I don't mean opposing the original rule, but instead the character of that. So let's give an example. Don't repeat yourself. This is a rule that we come across as developers. This is more a heuristic than it is a rule we've talked about times when repeating yourself might be the right thing to do. So how do we arrive at that conclusion? Well, let's look at an inversion of the don't repeat yourself rule. Do, right? So there's the first inversion, the inverted word. Don't repeat yourself. Do things once, right? Say one thing. Repeat yourself, say one thing. And so what we have to understand here is that not repeating yourself may be evaluated in a different way. We may see that rule differently than the inversion, the say one thing rule. You could also bend this a little bit because on the one end, don't repeat yourself as kind of a binary scenario, right? You either do or you don't repeat yourself. On the other end, the inversion could be a little bit of a soft inversion, right? When I say soft inversion, I mean you could say be simple. Make your code brief. Prefer brevity, right? The reason that this is important is because it still acts as an inversion of the same rule, but it contains in it a little bit of a different approach, right? Don't repeat yourself as a hardline rule, whereas prefer brief code is a much more open rule. You can interpret it differently. And so repeating yourself, repeating code may still be saying different things. Now this is an extremely powerful concept. It's extremely powerful, especially when you are applying it to your own behaviors. We've talked about habit change in the past couple of episodes. We've talked about how behavior changes very hard. We've for a long time, years now, we've talked about bias and how we have overconfidence in ourselves. So if we're looking at really any subject, it doesn't even have to be a rule necessarily, but certainly with things that are statements. These are not rules, but they are claims or some kind of declaration, right? Something that we are asserting is true. If we look at the inversion of those assertions, often we can uncover more powerful ways of working with those assertions. This is particularly true if we are trying to develop a healthy habit of not doing something, right? If we're trying to remove some behavior. This often fails for many reasons. One of the reasons that behavior change and trying to stop a bad habit fails is because we don't look at the inversion. We don't do something, but the inversion is we do something else. If we can think about behavior change in terms of behavior replacement rather than simply ceasing or beginning, then we have a much more actionable plan, a much more cohesive plan. The same is true on the flip side. If we want to start something, then perhaps we need to stop something else. A new habit of going to the gym absolutely requires not only the new habit, the new pattern of going to the gym, but it also requires setting an old habit side or changing the old behavior, stopping doing something else. Doing these inversions can be really enlightening and perhaps even more than they seem, right? On the surface, you may uncover something a lot quicker, a lot more thoroughly than you would have otherwise. I encourage you to do this with all kinds of your thinking. Another version of this inversion technique was mentioned on one of Tim Ferris' episodes, whether you listen to his podcast or not. This particular technique is pretty interesting. On the episode, he was talking about questions that changed his life. One of the questions was, what if I did the opposite? And this seems nonsensical to developers. What if I did the opposite? Sometimes we might parse that into what if I did nothing at all? But instead we need to be thinking what if I did the inverse? What if I did things in a completely different way? Or what if I thought about this rule in programming, this heuristic, this code smell, in the opposite way, what kind of character does that new code smell take on? Okay, so let's talk about angle number two. Angle number two. We've talked about rules as kind of this single point in time, this, this, or maybe even a timeless thing, something that we expect to kind of govern the way that we operate. But rules have an origin. Not only do they have an origin, but you encounter the rule at a certain point in your project. So what I want you to think about, the new angle is time shifting that rule. Imagine if that rule applied earlier or applied in a different place than you are currently using it. Imagine also the origin of that rule. Where did it come from? Why was it even created? Was perhaps there another rule that preceded this one? What was the thinking behind this, behind this rule? And then beyond this, play it out, go forward into the future. What is the end goal? What are the effects that we're trying to get out of the rule? So here we're time shifting the rule, and I'm using time shifting very loosely because all we're trying to do is understand maybe the rule applies, but it applies at the end of the project. Maybe the rule should be applied earlier in the project or earlier in the sprint or earlier in the task that you're currently working on. And perhaps this rule doesn't apply directly to the project, but the end goal might. Or maybe you don't want the same end goal that this particular rule is shooting for. For example, we as Developer Tend to think of our rules about clean code as kind of a uniform set of rules that we should apply to all of our code, but this isn't necessarily true. Typically, the business goals at least of clean code is sufficient maintainability. This idea of context is so important. That maintainability for a program that you'll only use once is totally un-maintainable. And that's not a popular opinion, and it's not one that we really like to think about, but it's true. If you're only going to run this code once, then it's okay for you to write an ugly shell script, for example. And we do this all the time with consoles. We run code once, and then the code essentially disappears. And so we can't think about code that we're shipping as one big thing, as one thing that we can apply all of the rules to unilaterally. That is devoid of context, and great developer understands, perhaps more than anything else, the context that they're working in. This helps you avoid things like over optimization. So I encourage you to take the rules that you are considering applying and time shift them. Understand where they came from, what their end game is, what their end goal is, and then apply it at different points in the project. By the way, these angles happen to be kind of multiplicative, right? Because you can have the same time shifting, you can apply to the inversions of the rules that you're exploring. And those inversions with the time shifting may have different goals, right? So you may change the goals of whatever it is that you are inverting. Okay, let's move on to our last angle. This one's a little bit more difficult to explain, but the best way that I can describe it is to understand things in terms of an extra dimension. Other than understanding, let's say, two dimensions, a front and a back of a piece of paper, for example, we're going to think about things in a third dimension. Mentally I imagine this being like a parallel understanding of a rule. You're not really trying to understand if your code follows a rule or not, but rather, you're inspecting the rule itself. You can imagine this being like rule of self-awareness. You're looking at the rule from the side. So as I said, this is a little bit difficult to explain how I have kind of this mental vision of this, but imagine that you're essentially you're zooming out, right? And instead of trying to apply the rule, you're inspecting the rule itself. This may allow you to do things like substitute concepts. So you can substitute the idea of code for design. And then apply that same principle, the dry principle, for example. You can apply that to your design elements. When you zoom out, you're kind of looking at the rule itself. You have this awareness of the working pieces of the rule. And then you can also, as we said in the second new angle, the time shifting angle, you can also start to think more about context that this rule applies in. You can investigate how the rule kind of changes depending on the types of input that you give it. And really the whole idea here is instead of applying the rule as if it is in itself, like a black box, right? You apply it as an adjustable model. You find the parameters of that rule. And maybe you change those parameters. You imagine ways that this rule can be applied in other scenarios. Maybe this gives you the opportunity to use the rule in a different sphere, right? This is the idea of a mental model. If you can use the same kind of guiding principle in multiple places, well, that means that you understand that principle more thoroughly. You've given some time to understand the parameters and how, you know, those parameters move through the rule. Very often what this results in, and I encourage you to go back and listen to this, the last episode of Developer Teaon this subject. But what this often results in is a construct theory. A construct theory, just a quick reminder, is different from an event theory because you can't really prove that it's true or that it's going to work. And instead, you're using rules as tools at this point. Rather than using rules as kind of boundaries for yourself, you're using them as a step ladder, as a way to improve. And perhaps that's the most important takeaway from today's episode. I want you to take this episode as inspiration to use rules, use these patterns, these smells, not as a way to restrict yourself. But instead as a way to improve the work that you do. Thank you so much for listening to today's episode of Developer Tea. I hope it was inspiring. And I encourage you to take some time to look over the rules that you use on a regular basis. And anytime you hear a principle mentioned, maybe mentally think for a moment. What would the useful inversion of that principle be? How can I apply this principle in a different place? What are the parameters of this principle? What if I applied it earlier or maybe I delayed and applied it later? Thanks so much for listening. If you enjoyed today's episode, I encourage you to go and subscribe in whatever podcasting app you use. The one you're using right now to listen to this episode is probably a good one. Go and subscribe so you don't miss out on future episodes. Thanks so much for listening and until next time, enjoy your tea.