A lot of the time on this show, we talk about how difficult it is to find a method that will produce the results that you actually want. In today's episode, we're going to take a little bit of a different frame of reference. We're going to assume that you've found a way to get something that you want, some kind of outcome, but then you need to figure out your boundaries. My name is Jonathan Cutrell, I'm a trail you're listening to Developer Tea. I created this show to help driven developers like you find clarity, perspective, and purpose in your career. And so this idea that we have systems, we have methods of generating the output that we want as developers, as humans, as companies, we have various kind of procedures, certain scripts, ways that we behave to achieve some kind of outcome. And a lot of the show, as we've already said, is about the difficulty in refining those systems. And how much of a battle we have just because we're human. There's a lot that we have to overcome, but today we want to kind of suspend those difficulties. We want to assume that we've identified or that we have the ability, rather, to identify a system, a procedure that will actually give us an outcome that we're shooting for. But we run into a problem. When we approach our issues as developers, as people, as managers, as business owners, even as consumers, we often try to apply a rational frame of thinking to those problems. But when we only look at the input and the output, we miss a lot of context that we actually will end up caring about. A lot of communications problems are born at this juncture, where one person has a different frame of their rationality in mind than another. When I say frame, I mean a variety of inputs, for example, a restriction on that rationality of a time frame, or maybe the available resources or the amount of risk that you're willing to take on. So we're going to talk about a handful of these frames that aren't necessary to bring up when you are discussing these different ways of achieving some particular rational outcome. And again, assuming that you have figured out how to apply some kind of procedure to get what you want. Today's episode is sponsored by Century. Speaking of applying rational frames and specifically time frames, if we had all the time in the world to catch our errors, all the resources in the world to throw into testing, then we wouldn't need something like Century, because we would eventually make something that was bug free. But the truth is, even then, there is some chance that a user is going to input something crazy. They're going to behave in a way that we would never be able to predict. And so without being able to exhaust all possible inputs, which is, again, prohibitively expensive, and it would take way too much time in resources, we need a better way to approach handling errors in production, finding them and triaging them as quickly as possible. So on the more reasonable side of things, you don't lose money. Your customers don't leave your platform, and you can get down to the bottom of your errors much faster. But over to century.io to get started today, you're going to start seeing errors pouring into your slack that you never even knew were there, and you'll be able to fix them faster because you'll know what commit they belong to. You'll know exactly where in the code it's happening. You'll get a stack trace. You'll get environment and context variables, all kinds of stuff. We use Century at Clearbit for exactly these purposes. Go and check it out, century.io gets started today. Thanks again to Century for sponsoring today's episode of Developer Tea. So a very simple summation of what we're talking about today is that rationality, when it comes to decision making, is not obvious. Every decision that we make, when given rational frames of reference, must be contextualized. So in other words, if you have a particular outcome, let's say that your outcome is a more productive team. Well, now I have to ask you questions. A more productive team with unlimited resources to spend in order to make them more productive? What is the timeframe that you need to be more productive within? Is there some level, some threshold that you need to surpass, and you're willing to do suboptimal things in order to surpass that threshold? Another fairly critical one for developers, are you willing to sacrifice, temporarily, your productivity in order to gain productivity in the future? If you think about this curve of productivity, this is often what we see when we pay down tech debt. So what we can see emerging here is a variety of frames. You can think about these as boundaries, or maybe even parameters for a given rational problem. So if you apply these parameters, you may find that your rational solution becomes either impossible or irrational. So let's play a little game. We'll use a little bit of a simulation here. Let's assume that you, as a developer, you are a rational actor, and you believe that as long as you are benefiting the company that the company will in turn benefit you. There's no perverse incentives, and there's no politics that we're going to consider in this particular example, assuming that you do well for the company, you will be rewarded at a rational rate. And then let's assume that you have a manager, and they have the same goals. They have the same alignment on reward and investment. There's no politics that are kind of muddying up their perspective on this problem. And you begin to review some work that you have maybe queued up for the next sprint, or whatever your working cycle is called, and you disagree about priority. Your manager says that a smaller bug needs to be prioritized over a major feature. Your perspective is that the major feature is in the long run going to be much more important than fixing the smaller bug. Now, let's imagine that you could extrapolate the data out, that you know for certain the financial impact that fixing this bug will have and the financial impact that the new feature will have, and you can look at that curve. And the curve tells an interesting story for each of these types of work. The curve for the bug means an immediate impact on revenue, albeit a fairly small one, but the curve for the new feature is a fairly slow sloping curve, but it goes up much higher as you extrapolate out into the future. Now, what's happening here? Why is it that two rational actors with both with the same information, both with the same incentives? You know, there's no uncertainty here. How can you choose different things to optimize for different types of work? Well, what we're doing here is we're going back to those frames. So for you, your frame may be the long term. You want the business to be successful in the long run. And your manager is using a frame of a shorter term. Now, both are important. Both have impact and both are rationally good choices. The amount of positive reward given the amount of input is probably similar to the amount of positive reward for the other. But by applying this different frame, this parameter of time, we start to see a different choice take place. There are other parameters, other frames that may be incredibly important to you. Perhaps the most important frame, the most important parameter to add to any of your rational decisions is your values. And here we'll also include ethics. If you see a way to rationally make a lot of money, but it goes against your values, then perhaps that particular solution that may be rational in terms of its output may become irrational for you based on that extra parameter of a given value that you hold. It's also important to keep in mind that this isn't just about you as a person. We need to think about ourselves as dynamic as situationally affected. And so investing a lot of money in stocks when you're younger is probably a more rational decision than investing money in stocks when you're older. This is how we get things like the automated target date funds early on in your investment career. Maybe in your early 20s or 30s, you're going to be heavily investing in stocks. And then that portfolio automatically begins to invest more and more in safer investments like bonds. And this is a very simple reality that as our situation changes and it's changing all the time, even without our input, we also need to change the way we make decisions in response to the situation changes. So here's the real takeaway and the real homework for you to do. Most of the time when you have a problem and you and a coworker or a manager are disagreeing on it, it's likely not because you want different things. A lot of the time it's easy to get on the same page. For example, neither of you wants this product that you're working on together to fail. There are very rare circumstances where your incentives aren't actually in the reverse. Probably you can find some common ground when it comes to the outcome, the goal that you're going for. So when you find yourself in conflict, a lot of the time it's either different perspectives and beliefs about what will happen given a particular input or it's exactly what we've been talking about in today's episode. Those frames are different. Those parameters that you're putting on your decisions, they may be different. So when you find yourself in these situations, be certain that you're identifying those main parameters that you care about. For example, time frame, values, resources, there's a long list of these kinds of parameters and they're going to be specific to your situation, to who you're working with, the people that are involved on the project. There's so many of these kind of variables but it's important to be explicit about the important ones, the ones that have an effect on the decision. Once you can be explicit about these, you're more likely to come to a common ground's location with the person that you have a conflict with. Thank you so much for listening to today's episode. Thank you again to Century for sponsoring today's episode. A huge thank you to Century for sponsoring today's episode of Developer Tea. If you set up Century, then you won't have to worry about losing sleep at night, wondering if your users are experiencing errors on your platform and you're just waiting for that dreaded email to come through. You can get alerts from Century that have much more relevant information than the average user email might. Go and check out Century.io to get started today. Thank you so much for listening to today's episode. I want to encourage you to do something with Developer Tea. This show, it comes out three times a week. It's a lot of content. You don't have to listen to every episode. Here's what I encourage you to do. I encourage you to use a specific day, choose a day, choose some kind of routine to attach this podcast to. You can do this with other learning material as well. Things that you are going to invest in your career, attach them to something that you already do. A lot of people who listen to the show listen to it on a commute. This is a perfect way to associate it with something that you do by default. What this is going to do is it's going to help you constantly grow by default. Of course, this is with the caveat that you believe that this show is valuable and then it's helping you grow as a developer. If you believe that, then choose one specific day, one activity or context that you regularly find yourself in and listen to this show during that time. Again, you don't have to listen every episode to get value out of this. There's actually a lot of joy and appreciation that you might find in curating a list of episodes that you think are relevant to you. We have nearly 700 episodes and this show is designed to be useful no matter how long ago that episode aired. There are some episodes that that's less true for, but for the most part, all of these episodes of Developer Tea, they're applicable to you no matter when they aired, no matter where you are in your career. This show is not something that you have to listen to every single episode to understand the next one. In fact, I encourage you to choose the ones that are most relevant to you because you're going to get the most value out of this podcast if you do it that way. Thank you so much for listening to this episode and until next time, enjoy your tea.