As you begin to think about next year, it's likely that you are going to think back on this past year. And many of us will think forward to the next year. In the last episode we talked about figuring out ways to use better labels. And I called on you to try to incorporate this into your resolutions. Whatever your resolution type practice is, perhaps you don't have one. But if you do, I hope that you will incorporate some of the thinking, or at least ponder, what we said in that last episode about labels. And we're going to continue that theme in today's episode. We're going to talk about something that's very important to software engineers, exceptions. My name is Jonathan Cutrell, 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. Exceptions are often used in exceptional states. This is what they're made for. We have special kind of a redirection of code paths for exceptions. And it's important to understand what an exception is. An exception is a situation that is unexpected. You can think about exception as kind of the inverse of an expected state. It is an exceptional state, an unusual or otherwise unplanned for situation. And of course, we are planning for it in some way by creating those exceptions in our code. It's way of saying, if this unusual or unexpected thing happens, then we know what to do. We have a way of handling it. We handle the exceptions. But sometimes exceptions don't have explicit handlers. Sometimes the exceptions are something that we don't necessarily anticipate. And the language itself, hopefully, handles those exceptions for us. Usually it doesn't do it in a graceful way, but at least we don't have an entire server fall over because of some exceptional state that we didn't necessarily predict. Here's the interesting thing. As with most tools that we have as engineers, we have a tendency to use things in the wrong ways and sometimes to reinforce and create habits out of those wrong uses. And in our case of exceptions, we might use exceptions to control logic. We might create exception handlers for situations that are, in fact, expected. Why would we do that? Well, in code, it might simply be bad mechanics. We may have forgotten the, quote, correct way or a better alternative, something that doesn't require us to label something an exception when it's not. But I want to go a little bit deeper in this episode and talk about exceptions in our lives. Of course, on Developer Tea, we don't talk about code for very long without immediately relating it to our behaviors because behaviors drive everything else. And so what is the analog to exceptions in our lives? It's all too common for us to do exactly the same thing that we do in our code incorrectly or perhaps unknowingly. This bad habit of labeling things, like we talked about in the last episode, poorly, labeling something an exception when it's not really an exception. Ultimately, what we create is a system that allows us to, on the one hand, maintain a story about our lives, maintain some perception about our actions, maybe, or our values, while having a totally different and parallel story that agrees more with reality. We may have a whole list of values or a whole list of things that we believe, our beliefs or maybe even a list of actions or behaviors that we subscribe to. And then we have a list of behaviors that we actually practice. And the way that we resolve these two things, the way that we can kind of remove the cognitive dissonance of the differences between our actions and our perception or our hope is through exceptions. We're going to talk about how that happens right after we talk about today's sponsor retool. Retool is the fastest way to build internal tools. And if we're being honest, most engineers don't really love building internal tools. I know some that like it, but for the most part, people want to work on things that are customer facing, not internal apps, like admin panels for crowd operations or customer support and inventory management tools, those are kind of the boring things that nobody really wants to get caught doing. And every business runs off of these tools. They're so important, but they're also something that nobody really wants to do and nobody wants to deal with the headache of maintaining them either into the future. And when you think about it, internal tools are mostly all the same. They have kind of the same building blocks. They all have basic UI elements that you would expect, tables, drop downs, et cetera. But they all pretty much need to connect to a data source along with some kind of code to filter that, right? To change that data in some way, to present that data, all of those core actions we already mentioned. And this is exactly what retool helps with. It gives you a drag and drop interface so engineers can build internal app UIs in hours rather than days. And spend more time building features that customers will see. This makes maintainability a whole lot easier as well, because instead of having a bunch of custom code, you're using a tool, right? It connects to any database, any API. For example, it can pull in data from Postgres. You can just write a SQL query and drag a table onto the canvas. And you can also write JavaScript pretty much anywhere inside retool to manipulate your data any way you would like. So the accessibility of kind of customizing those data manipulations is very highly accessible, right? So go and check it out, head over to retool.com slash devt. That's retool.com slash d-e-v-t-e-a to get started today. Thanks again to retool for sponsoring today's episode of Developer Tea. So we're talking about exceptions today and we're talking about using exceptions in ways that are not really appropriate. We know that this happens in our code, but it certainly happens in our real lives as well, in our day to day decision making. For example, it's very easy to see that we make exceptions about our choices with health. We make trade off decisions that don't really follow the logic or what we say we believe in. And the way that we consolidate this, the way that we can kind of bridge the gap between the obvious cognitive dissonance between what we claim and what we actually do, what we say we believe and what we act on, the way we resolve that is through this kind of tool, this really big hammer of exceptions. We say this particular case was different. We do this both at the individual level as well as the team and even the ultimately the organizational level. In fact, it goes even beyond organizations. It goes to entire societies, we create exceptions and we create special cases for our entire society. In fact, you can hear this term very often used in political discourse, the idea of exceptionalism, regardless of what group you belong to. And so this exceptionalism, it applies all the way down to our atomic decisions and it matters deeply when you're starting to think about behavior change, when you're starting to think about your resolutions, which is what we're talking about today. And so what we end up doing, the way this tool ends up working and how it's so damaging is that we look at a given situation and if somebody was to ask us to judge it for someone else, it's imagine that someone else took part in that particular behavior, we could easily draw the line between what we believe, the kind of the delta between what we think should have happened and what actually happened. For example, we have pretty good evidence that if you choose to eat the extra food during the holidays, if you choose to have the extra desserts, you're probably going to put on some weight. Now, you may have already subscribed to the idea that you don't want to put on extra weight. And yet, so many of us who have fallen that category myself included will justify based on a specific exception. We create exceptions to our rules. Now, the interesting thing is we don't really give ourselves a budget for the number of exceptions we're allowed to create. And this might be a decent intervention. How many exceptions are you allowed to have before it's no longer an exception? And in fact, this kind of gets at the underlying definition of the word exception, something that is unusual, something that is unexpected. So many times we create exceptions for things that actually are systematically expected. We expect for the holidays to roll around and we expect that there will be dessert that we want to eat. We expect that we're going to be tired in the morning, more tired than we really want to be, more tired than we would like to be in order to get up and exercise. And so this happens on a regular basis because systematically we're set up for that. It's not an exceptional state. It's a more common occurrence than our imagination leads us to believe because we lean on this idea of exceptions. And the next part of the show is where you might expect me to go into some kind of long diet tribe or to preach to you about why an exception is basically the same thing as an excuse. And that's not what I'm going to do because we can't just stop making exceptions and expect everything to work. In the case of code, if you pulled out all those exceptions, it would just break because those situations are happening. Those situations that are not necessarily exceptional that you are controlling with exceptions, they still occur. And so you need to address them somehow. But what I will recommend instead of saying, well, exceptions are excuses. Instead, I want you to come to terms with those occurrences. Come to terms with those systematic, more common occurrences in your life. So what does this mean practically? It means coming to terms with the fact that what we're labeling exceptions, what we're calling exceptions today, are not actually exceptions. Right? We have to kind of wrap our heads around the idea that, well, I'm always tired in the morning. This isn't an exception. It's not new that I'm tired in the morning. It's not unexpected. I didn't go to bed last night expecting to wake up fully energized. I want to have a life where I'm fully energized in the morning, but I don't necessarily have that. Right? This is about an honest look at those things that you call exceptions and then rethinking how you can understand the situation. And either, if two choices, once you've kind of accepted the fact that the things that you're calling exceptions are not actually exceptional states, you can either choose to do something different so that you will have the more expected state. Right? In other words, you change your situation in a way that those things that are currently, you're calling them exceptions. They actually become exceptions and that will lend kind of credibility to that label that you've chosen of exception. Or you change your mindset about that occurrence, about that event. So, if you know, for example, that you're not a morning person, instead of trying to subscribe to this endless pursuit of becoming a morning person in order to work out in the morning, maybe it's time to change your idea of the time that you should work out. Right? Maybe instead of believing that you're going to become this excellent computer scientist, even though you don't have an appreciation for math, you're hoping that eventually, through some sheer effort of will, that you'll start liking math one day, maybe instead of saying, well, it's an exception, I just don't feel like doing the math today. Maybe you can embrace that part of yourself. Maybe you can choose that you're no longer going to kind of walk down that path, you're no longer going to expect that of yourself. And instead of it being an exception that you don't like math, that particular day, you're not in the mood to do it, you can just embrace that you don't like it. And really, this gets to the core of the problem here. We have expectations that we put on ourselves. We have this picture, very often a false narrative, that we imagine is true about ourselves, about our surroundings, about maybe even our family or our company or our jobs, our talents, our skills, our relationships, all of these things. We have our own kind of projected picture of what those things are. And then we have something that's less projected and more transparent. If we can learn to see that and accept it, right? If we can learn to see that our company is not going to become a super growth company in three months, for example. Then we can learn that our, you know, each of the steps along the way, they can imagine that if you believed that or if you were trying to project that, that you would have to create all of these exceptions to why that didn't happen. You would rewrite all of these day-to-day storylines about why that thing that you believed is actually not happening. And you would do it through the frame of exceptions. Well, it didn't happen because of this unexpected thing. But if you're looking from the outside looking in, those were not exceptions at all. The premise, the entire storyline, the narrative that you bought into to begin with was wrong. And so all of the things that become exceptions when you start from a wrong basis, right? All of the things that you wrap the exception label around, they turn out to be resolved. Most of the time, at least, by rebasing your narrative in an accepted reality. I want to make something very clear here. This sounds patronizing if you're hearing it from the perspective of, you know, get your head up out of the sand and accept reality. It's very hard. It's very hard to know what reality is in a given moment. It's very difficult to be able to parse through that. But the first step in that direction is to recognize that all of our aspirations, all of our hopes, all of our plans, all of the things that we believe very often are at odds with our behavioral reality. Very often we aspire to something that is either unrealistic or it's incompatible with the things that we actually care about. Much of this exercise is about fear. And it's about the fear of departing from a previously held value, previously held belief, a previously held perception of reality. Coming to terms with something that isn't comfortable to come to terms with is an important part of being able to operate more effectively as a human, as an engineer. It's very important to be able to do this because otherwise what we're doing is we're creating these very weird ergonomics, mental ergonomics, right? We're creating these kind of double standards as our primary base of operation. And so other people will pick up on this, by the way, right? Other people are going to see and recognize that what we're claiming or what we're saying that we're pursuing doesn't really necessarily line up with our actions. And so it's worthwhile. It's worthwhile to, first of all, recognize that this is difficult, right? And then there, you know, if you have other people who you are going through this with, if you share this podcast with another person and you talk about it, for example, do so recognizing that empathy is incredibly necessary in this discussion. This is difficult for everyone. There's nobody who has totally figured this out, right? If you're going to share this, if you're going to talk about it with somebody else, recognize that you're in the same bucket as them, that we all have a lot of these distortions that we buy into and then we label these various things exceptions mostly to preserve. This is the key point that I don't want you to miss. We use this to preserve our previously held viewpoints, our previously held perceptions, beliefs, values, etc. We can encounter anything in our lives. And if we can have literal use of exceptions, then our kind of philosophy, we'll bucket all those things that we were talking about before, the values of beliefs, all those things. Our philosophy can stay intact because our new encounters, we put them outside of the philosophy by labeling them exceptions. I hope that as you think about your next year and hopefully beyond that, that you will integrate these ideas, that you'll try to find ways to reduce the number of things that you label as exceptions, reduce the number of things that you believe are exceptions. And perhaps more importantly, recognize areas where that philosophy, that philosophy is not totally accurate for you. Thanks so much for listening to this fairly challenging episode of Developer Tea. I am talking as much to myself as I am to you, the listener in this episode. So hopefully you realize that I'm in this with you as well. And I hope that you will continue listening to this show to hear more about this kind of thing. If you want to continue listening to Developer Tea, make sure you subscribe and whatever podcasting app you're currently using. And of course, thank you, a huge thank you to today's sponsor, Retool, head over to retool.com slash devt. That's retool.com slash dvta to get started today. Thanks so much for listening to this episode, this episode and every other episode of Developer Teacan be found on any podcast app that you use. My name is Jonathan Cutrell and until next time, enjoy your tea.