In today's episode, we're talking about a different way of looking at rules and perhaps come to a different conclusion on rules and understanding how and when rules apply.
In today's episode, we're talking about a different way of looking at rules and perhaps come to a different conclusion on rules and understanding how and when rules apply.
Discover.bot – a digital space for bot developers and enthusiasts of all skill levels to learn from one another, share stories, and move the conversation forward. New to bots? Get started with their Beginner’s Guide.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
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, while 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 Cutrell 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 an 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, discovery stories, advice and knowledge into part of a shared cannon that moves everyone forward. For veterans and beginners alike, Discover.bot is a place for learning, teaching and talking. Head over to Discover.bot.slaj Developer Teato 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 of 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? 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, we 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. Instead of thinking about the exceptions in our schedules, as just part of the schedule, we continue to think about them as exceptions, and we continue to treat them as exceptions. 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 every day this week has gone exactly as planned. There have been no anomalies. 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. 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 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 aren't happy. We have no reported bugs. Everyone is actively working today. No one is out sick. We have all of the resources we need. We have perfectly timed and perfectly articulated cards in our 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, 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 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. 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 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 a 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. 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 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 like clear bit, that your code must be reviewed before it goes out. You need to test your code and staging and 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, again, 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 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. That's 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 more strictly to your best practice. Now don't be dogmatic about it. Don't take it as 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 and those exceptional moments. Why does this friction exist? What is the function of making me go through 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. 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. And we're at least I'm 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. However to Discover.bot, slash Developer Teato 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.