You have definitely experienced this before if you've been a software engineer for very long at all. The temptation to make a little bit of a sacrifice. To do something that you know is not the maintainable solution, but it is the faster solution. Now, this episode is not going to be me trying to convince you to never do fast solutions. The quality of a solution is dependent on context. And we've talked about this in so many episodes of the show before. Instead, I want to give you a solid understanding of why making that one concession, why breaking that rule that one time, is unlikely to be the last time. My name is Jonathan Cottrell. You're listening to Developer Tea. And my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. If you've listened to the show very long at all, you know that I am heavily biased towards taking your time to do something right. I believe, personally, that if you're rushing, there's probably something wrong. And I've shared that view on this show before. But today's episode is not about finding an arbitrary speed at which you should execute. Instead, we're talking about the behavioral patterns around breaking your own rules. This is incredibly important for you to understand for yourself, but it's also important for you to understand if you are a manager. If you encourage your direct reports or other people in your company to break rules in order to do something right, then you're going to be in a position to do something right. And that's why I'm here today. I'm here to help you. I'm here to help you. I'm here to help you. I'm here to help you. I'm here to help you. I'm here to help you. I'm here to help you. I'm here to help you. And especially if that disorder is illegal. Not grossly illegal, but misdemeanor level kind of illegal. You're likely to not see one instance, but many instances of that kind of disorder. And what is the reason for this? Well, in every context, there is some social component to our lives. We learn how to operate based on these social interactions. And when we say social here, we're not necessarily saying that it's, you know, friends meeting up at a local restaurant. Instead, we're talking about how other people act in a given community. That community can be a workplace, or it could be a neighborhood, or it can be an online community. We take signals from each other. And this is how we have survived for millions. Millions of years. But when we take these signals, we're tuning what the signals mean from that social context. And there's different signals that you get in a given social context. Some are signals from, for example, authority figures. Others are signals from your peers. And then there are hidden signals or implicit signals. The implicit signals that you receive, if you're in a community that allows disarray, is that you may have some explicit signals from authority figures, but you have implicit signals that are saying that those explicit signals don't matter. In other words, you don't have to follow the rules. In fact, it's normal to not follow the rules. And conforming to this social norm is a much more common behavior than trying to conform to authoritative norms. So what's the difference? So what's the difference? So what's the difference? What does this mean? Well, it means that if you establish a social context, like a company, that has some authoritative norm, like guidelines, and those guidelines get broken on a regular basis, well, it's very likely that they're going to continue getting broken. And it doesn't even have to be that prevalent. In fact, the theory of this comes from public policy, and it's called the broken windows theory. And this theory is called the broken windows theory. And this theory played out in New York City and in other cities. It didn't really take very much at all to trigger this additional rule-breaking behavior. And perhaps what's more alarming or at least cautionary to us as people who are kind of creating these social environments is that when people saw these misdemeanor-level offenses, they would also be more likely to participate in these kinds of social environments. They would also participate in even more serious crimes. Now, we don't have to necessarily view ourselves or our employees as criminals for this to apply. The norms of our rule-breaking don't have to be felonies to be harmful to us. So this is one reason why breaking the rules, the established guidelines that you set for yourself in a company, in any given social context, must be done carefully, and with consideration for this social norm shifting. If you set up a new social norm, think about the long-term impacts of that new social norm. Think about the signals that you're sending when you choose to break a rule rather than following it. Now, to be clear, this podcast is not trying to reset your conviction for following rules. Instead, you should understand what breaking a rule does. There are absolutely functional reasons to break rules, and sometimes rules are simply bad. They may need rethinking altogether. So be considerate of the social norms that you are setting or that you are changing by breaking a previous norm. We're going to take a quick sponsor break, and then we're going to come back and talk about how, in a moment, we're going to talk about how to break a rule. So let's get started. Breaking of these guidelines, of these rules that we set for ourselves, can set us up for a new kind of accelerated habit building. But first, let's talk about today's awesome sponsor, Square. Square APIs and SDKs make taking payments and managing orders, catalogs, inventories, or employees a breeze. Square supports iOS, Android, Flutter, and React Native for in-app mobile payments, or you can even install it on your phone. You can even integrate with Square Readers straight from your own app. That means you can take a credit card directly through Square. Square also provides an embeddable payment form for adding a checkout experience into a website. You can check out tutorials and learn about key concepts like item potency on Square's new YouTube channel for developers. Go and check it out, youtube.com slash square dev. That's all one word, youtube.com slash square dev. Thanks again to Square for sponsoring today's episode. I'll see you next time. Bye.! Bye. Sometimes the feedback is telling us to stop doing those things. But the mistake that we often make is that we attribute some kind of wisdom to the feedback that we get. We believe that the feedback is giving us our path. And this path is driven by whatever we're measuring as a result of our actions. But we aren't stopping to think about what that feedback actually is. We'll take an obvious example. When you exercise, it's possible that you injure yourself. But if you don't injure yourself, it's likely that the exercise is good for you. However, your body is likely to tell you that the exercise is somewhat uncomfortable. Similarly, we might get a positive reward, a positive feedback, when we eat unhealthy food. We have a craving, we satisfy that craving, and our body initially rewards us. And so the feedback that we are receiving in these scenarios is flip-flopped. Very often, we would benefit from more exercise and not following our cravings for bad food. But this is incredibly hard to do. In fact, there are entire industries that are built on this simple reality. That the feedback that we receive in our immediate environment does not always equate to the long-term intentions, to our long-term welfare. And so if there is a disparity in these simple things, then certainly we can consider the idea that feedback is giving us the wrong signals in more complex decisions. For example, we choose to break the rules, and we get that level of appreciation from the investor, from our boss, from our customer. While there may be lasting positive effects, we shouldn't ignore the fact that we have given ourselves a reward for going against a guideline. This reward of choosing to do something that we previously said we shouldn't do. This reward system will reinforce the behavior. Instead of feeling like you shouldn't have done something, like you shouldn't have broken the rule, you will feel like the barrier is actually much lower the next time. Because your brain will remember that reward. It will reinforce that behavior unless you step in and regulate. This is why it's so important to be careful about what you celebrate. What you celebrate in a company culture. When you reward behaviors, you can expect those behaviors to continue. And so consider the incentives in your social situations at work. Consider the incentives in your own life, and whether those incentives are rewarding behavior that you don't really want to reward. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Square for sponsoring today's episode. Head over to YouTube.com. You can find us on Twitter, Facebook, Instagram, and Twitter. We're all on Twitter. And you can find us on Facebook, Twitter, and YouTube.com. That's all one word, Square, D-E-V. To learn more about the APIs and the tools that Square provides to you as a developer. If you enjoy Developer Tea and you'd like to give back, you'd like to help us continue making this show, one of the best ways you can do that is to leave a review in iTunes. In the first couple of years, we got a lot of iTunes reviews, but those have slowed down significantly. Now, I know there's a lot of people who are listening to this, who are listening to the show right now, and you haven't shared what you think about the show with other developers. This is one of the best ways to help other developers decide to actually download that first episode of the show and join us. Thank you so much for listening to today's episode. A huge thank you also to Sarah Jackson, today's producer. My name is Jonathan Cottrell. And until next time, enjoy your tea. Thank you.