When we build systems, guidelines, rules, suggestions, best practices, when we have barriers and when we draw lines around what we should or what we should at least encourage others to do, what we as developers should do, or what we should enforce in our companies, on our teams. We build these systems, we create these rules with an assumption most often that they apply in the average case. That our normal everyday work is bound by those rules. But at the moment that we experience an exception, that the rules can be set aside, that the guidelines are no longer applicable, that the best practices, well, we can kind of skirt around them. In today's episode, we're going to discuss a different way of looking at rules. And perhaps come out with a more useful reason. A more useful reason for having the rules and understanding how they apply, when they apply. My name is Jonathan Cottrell and you're listening to Developer Tea. My goal on this show is to help driven developers connect to their career purpose and do better work so they can have a positive influence on the people around them. Today's episode is sponsored by Discover.Bot. Discover.Bot is an online community for bot creators. Amazon Registry Services Incorporated created Discover.Bot to serve as a platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from one another, share their stories, and move the conversation forward together. On its own, even a good idea isn't always as powerful as it could be. But when a good idea is shared, it gains strength and momentum. It becomes capable of changing things. In ways both small and large. And a good idea shared becomes an innovation. Discover.Bot aims to sit at the intersection of ideas and innovation. Discover.Bot wants to help people turn their experiences, discoveries, stories, advice, and knowledge into part of a shared canon that moves everyone forward. For veterans and beginners alike, Discover.Bot is a place for learning, teaching, and talking. Head over to Discover.Bot slash Developer Tea Become a part of this conversation today. Whether you are creating bots today, if you're interested, or if you've had a whole host of bots already go live and are out into the ecosystem, Discover.Bot is absolutely built for you. Go and check it out. Discover.Bot slash Developer Tea. Thank you again to Discover.Bot for sponsoring today's episode. I want you to think back to the last week. your life. I want you to imagine each day, if you can, even the last three days. Imagine or recall the events of that day. What events were normal? What events were repeated between those days? And it's likely that even with this small of a sample, there was some anomaly. There was some kind of appointment that you had to go to, maybe an unexpected event with the weather, for example, or perhaps you stayed home from work because you were sick. This is something that happened to me recently. Now, I want you to extrapolate this across the last month. Two months, the last season, or perhaps the last year or two years. How often do you experience anomalies? The strange thing is that we continue to call these anomalies exceptions, even though they are relatively common. And so instead of thinking about the exceptions in our schedules as just part of the schedule, we continue to think about them as a part of the schedule. And we continue to treat them as exceptions. Now, this isn't always true. Many of you who are listening right now, you can look back at the last three days or even the last week and say, no, this is, you know, every day this week has gone exactly as planned. There've been no anomalies. But the truth is that most of the time when we create what we consider to be the normal day in our minds, we aren't thinking about things that are, typical. Instead, we think about the optimistic base case. Now, this isn't a fancy term that you can find if you Google, as far as I know, it's something that I'm making up for the sake of this episode. But this optimistic base case is the idea that nothing is going to go wrong. No interruptions are going to happen. That everything will go as planned. And this optimistic base case is important. We need to understand what that means. And we need to understand what that base case is. But the truth is that it's not actually representative of the average. When you think about planning, when you think about planning over the course of a week or over the course of a month or a year, you need to be considering that the average is not optimistic, nor is it pessimistic. The average is an attempt at a realistic picture. But the problem is that we create expectations for ourselves based on an optimistic picture. Okay, so why does this matter? And how does it relate to the rules and guidelines and best practices that we have for ourselves? Well, we apply these rules and guidelines in that optimistic base case scenario. When we're building features from a stable state, for example. We have a stable master branch on our project and all of our tests are passing. And we have adequate test coverage. And no users are unhappy. We have no reported bugs. Everyone is, you know, actively working today. No one is out sick. We have all of the resources we need. We have, you know, perfectly timed and perfectly articulated cards in our, you know, project management program, whatever software we use for that. And everything is just right. Now, we feel that we can operate and follow our best practices. This is a utopian state that we've created where those best practices are applied. They're kind of like icing on the cake. And the moment that any of that ecosystem is disrupted, we're going to have to start to disruption. At the moment that we don't have the resources that we need, or there's a bug that's been introduced, a lot of our so-called best practices tend to fall apart. And then we do something that is outside of our best practices, outside of our guidelines, outside of our unwritten contracts of how we should behave and how we should write our code, the clean code contract that we may have. with ourselves or with our employers, that unspoken commitment to quality, for example. But as we've already demonstrated in this episode, and hopefully you can grasp and agree with this simple reality, the optimistic base case is not the average case. That means that on average, we're not necessarily applying best practices. When we view best practices as applicable only when we're not in an exceptional state, then very often we won't be applying our best practices. So that's kind of the first part of the argument for today's episode, that we are not applying best practices universally because we don't build our best practices with the average case in mind. Instead, we build them. We build them with the optimistic base case in mind. The second part of the argument is that best practices are most effective during exceptions. In other words, the rules shouldn't be thrown out when you experience an exception. Instead, the application of those rules and those guidelines, those best practices, the lines that you draw, all of that becomes even more important. In those exceptional cases. I'll give you a simple and perhaps even controversial example. Imagine that you and your team are running up close to a deadline. And this deadline is bearing down on you. And so as the deadline approaches, as so often happens with software, you've underestimated how much you would need to do to accomplish what you expected to accomplish. Now, you know that a best practice, a rule that you've set up to accomplish is going to be a rule. And so the best practice that you can set for your company and for your culture is to not overwork yourselves, to not work past, let's say, a 40-hour work week, to stand as a champion of work-life balance or mental health or whatever other reasons that you don't believe working long hours is a good idea. Now, the problem is that now you have a conflict. You have an exceptional state. You're not always running up against the deadline. It's very rarely the week of launch. And so you have to make a decision. You have to make the decision. Do we break the rules because we are in an exceptional state? Now, here's the interesting part of this argument. This rule is easy to follow and perhaps not even necessary when you're not in the exceptional state. It's very likely that when you're not running up against a deadline, keeping work-life balance is a reasonably easy thing to do because the sacrifice to cut your, for example, 45-hour work week down to 40 hours is fairly small. There's not a lot of negative consequence. And so this guideline becomes easy to follow. Now, when the guideline becomes important, and perhaps, incredibly important, is in the exceptional state, when you have a lot on the line, when you have to make a value judgment, choosing to maintain work-life balance at the expense, for example, of meeting your deadline or meeting the deadline with the number of features that you plan to meet it with, that's where this rule becomes important. That's where this rule becomes valuable. That's where this rule actually changes your behavior. That's where the guideline actually makes a difference. And the same is true when we're dealing with code. When we have to have reviews, for example. Let's say that you have a guideline, and we do this at Clearbit, that your code must be reviewed before it goes out. You need to test your code and see if it's good or not. You need to test your code and see if it's good or not. It's in staging and in development, and it needs to be reviewed by another developer. Now, let's say that you're in an exceptional state where, for example, you're rushed. Maybe there's a bug that you need to get resolved, or there is a deadline that's impending. Perhaps you're ending your sprint, and you wanted to get this thing done, and so you feel rushed. There's some kind of external stressor that's making you... feel like you're in some exceptional state. At this juncture, you are much more likely to make mistakes. You're more likely to write code that has bugs in it that could easily break production. Now, contrast this to when you're not feeling stressed. You're less likely. You're less likely to push dangerous code. So, when is a review... When is a review more useful? When is this rule, this guideline, this best practice, when does it actually provide the most value in catching problems? As it turns out, very often, the rules that we have, the guidelines and the best practices, and the procedures, and the lines that we draw, they are most applicable in exceptional states. Not less applicable. That's our intuitive response. That we should be able to break the rules when the context allows for it. But I want to challenge you, as a listener of Developer Tea, I want to challenge you, when you feel like you're in a place where you should be able to break the rule, where you should be able to kind of ask for forgiveness rather than permission, I want to challenge you to adhere to the rules. I want to challenge you to adhere more strictly to your best practice. Now, don't be dogmatic about it. Don't take it as, you know, this is absolute and there's no way around it. That's not the spirit of what we're saying. But instead, to see what the rule was intended to do. And how you may, in that exceptional state, if you break the rules, that may be the reason the rule exists in the first place. Now again, I want to be very clear. We aren't just talking about rules here. We're talking about things like proper naming structures and separation of concerns, good coding practices, internal company policies. Often these things feel like friction. They feel like things that are impeding on your ability to work. And it's important to recognize when that is actually true. We're not kind of blindly accepting every supposed best practice. But instead, we should be considering in those especially stressful moments, in those exceptional moments, why does this friction exist? What is the function of making me go through this friction? This friction point? Perhaps it is intended for this moment in time, for this exact scenario. Thank you so much for listening to today's episode of Developer Tea. I hope that this is both inspiring and challenging. I know that this is something that, especially as a seasoned developer, I feel the kind of the authority to jump over the rules whenever I feel like it. But I also understand that when I do that, very often I look back and I realize if I had only stuck to it, if I had allowed myself to be patient through that friction point, a lot of the problems that I face would evaporate. Or at least I'd be able to address them a little bit easier. Thank you so much for listening to today's episode. Thank you again to Discover.bot for sponsoring today's episode. Head over to discover.bot slash developer tea to check out the Discover.bot community today. Thank you so much for listening. If you're enjoying today's episode, I encourage you to subscribe in whatever podcasting app you use so you don't miss out on future episodes just like this one. Thanks so much and until next time, enjoy your tea.