As a developer, part of your job is estimating risk and value, a trade-off. You can consider risk a type of cost or at least a probable cost. And you can consider value a probable profit. And we aren't always just talking about money and we aren't always just talking about time. There are other kinds of risks and values, but ultimately when you are making decisions, for example, even a single line of code, you're deciding a trade-off. You're deciding for a given method, a given function, you're deciding is it worth both the time that it takes to implement, but also is it worth whatever I'm introducing in terms of risk to gain whatever the value is. Now, this sounds obvious, but unfortunately a lot of the time, the way that we understand risk and value is far too static. In today's episode, I want to talk about changing our risk and value evaluations from a static process to a functional process. This isn't going to involve math in today's episode. Instead, it's going to talk about our kind of mental calculation that happens without explicitly identifying any kind of math. My name is Jonathan Cutrell and you're listening to Developer Tea. This show exists to help driven developers like you find clarity, perspective, and purpose. When we evaluate a given decision, let's say the choice of a particular algorithm or maybe a framework, a lot of our evaluation is trying to understand how could things go wrong and how could things go right. Will we be able to achieve, while we're trying to achieve, and then will we experience some kind of threat if we choose this particular route? Our decisions often create that dichotomy automatically. We imagine that success is on one end of the spectrum and failure is on the other and that we will either succeed or fail and then we make our decision. Fortunately, a lot of the time, the models that we use to decide whether something will be successful or not, they're incomplete. We have a bad way of evaluating risk and we also have a hard time evaluating opportunity. Let's take, for example, choosing a particular framework. We try to create a process where we weigh the pros and cons. We have the pros and a column and the cons and a column and then maybe we try to weight those. We put a score next to each one and then we add up the scores and if there's more pros than cons, then that choice wins. This is a linear way of thinking about risk and value. When we weigh pros and cons, we're flattening all of the information into a single kind of score and this is that dichotomy that we're talking about. You can imagine that a zero risk score would have no chance of success and no chance of failure. It would just be in the middle, maybe equal chance of success or equal chance of failure. A positive risk score would be more likely to succeed and the negative risk score would be more likely to fail. If you come out at a wash, then are you more likely to succeed or more likely to fail? It's easy to see the shortcomings of this linear way of thinking about risk and value. By thinking about risk and value as highly correlated to each other, those who take the highest risks also have the highest opportunities for success. This isn't always true and it's not a rule but it's very unlikely that you will have a great amount of success without also accepting some risk. We see this in markets and we see it in our own lives. The things that are risky often also have the highest capacity for a reward. It's important that instead of creating this linear way of thinking about risk and value, you start by breaking up those terms and defining them more clearly. This can help you realize that weighing the pros and cons is a compression of information and very often that compression leads to more confusion. The model that you use to understand the risk or the value of a given decision could likely be much better suited if it was more dynamic, more functional. What does a functional model look like? What is a functional model when we're talking about risk and value? We can stop talking about risk and value now because those are compressed terms. As we mentioned previously, risk and value are much more abstract notions. When you have a model that you need to evaluate for a given decision, you're going to be looking at much more specific terms to what you're trying to do. What does it mean to be successful? What are the aspects, the characteristics, the traits of success? How would you describe that? Once you understand what it means to be successful and what it means to fail, then you can select more appropriately a functional way of thinking. When we're talking about choosing a framework, for example, we may need to define success as the framework is easily supported in the future. For example, another consideration for success may be we want to scale our company. We want to build a product and scale a company around this framework. We need to be able to recruit people who can pick this framework up and use it. You can also look at the opposite side, the risks for failure. How do you define failure? We need for our application to be fast enough. We're going to use our application to serve some kind of web app. We need that web app to be highly responsive. If the framework doesn't have good performance at a given scale, then that could be a risk. There are some immediate risk and success evaluations that you can do. Then there's second order success and risk evaluations that you can do. You could imagine that, for example, if the community of people using this framework is very big, what are the effects that that may have on your company? It's easy to believe that any one of these factors is only going to have a positive effect on your company, on your efforts. That's usually not true. Usually there are positives and negatives. For example, having a large community of people using this framework, you could have a lot more churn than you expect to have. Yes, there's a higher available pool of people for you to hire from, but also on the flip side because a lot of people use this framework. That means there's a lot of alternative jobs for people who, for whatever reason, decide to move on from your company. They have a lot of options. By no means are we saying that you should choose a framework in order to retain people based on the lack of other options they have. That's probably not a very good hiring practice in the first place, but you should be evaluating these fringe realities, the characteristics that your choices have. Don't think only on one particular frame of reference, think about all of the ways that those traits and those realities could affect you. You're not going to be able to always analyze every single tiny little thing, and that's not the goal here. Instead, we're trying to create a system where you can imagine this success and failure evaluation as a function. What does that mean? It means that if you provide some kind of situation to that function, you can imagine how the different parts may interact. For example, if you are desiring a particular outcome like we want our company to be sustainable for at least the next five to ten years, right? Maybe that's one of the goals that you have. You can use this functional thinking to evaluate in a dynamic way how that decision may affect you over time. Time may be a argument to your function. You may choose a framework based on how popular is that framework, but it's not just about how popular it is now. It's also about projecting how popular it will be in one or five or even ten years from now. This is good not only when you are making very serious decisions and trying to create sustainable solutions that can last the test of time, but also when you're trying to decide how much investment should I be making into this given decision. What is the optimum amount of energy I should place into this? So imagine that your goal is to have a particular type of output from this functional way of thinking. And your output is determined by your input, at least in pure functions that's true. And so if you're inputting a certain amount of energy, you can imagine that that is resources, some kind of cost metric, then you are kind of incentivized to decrease that amount of energy to the least possible amount. So imagine this as a literal function. And when we say a function, we mean something that takes a particular input or set of inputs and provides a particular output. And that function should provide the same output given the same inputs. So let's say that your goal is to have a marketing page on your website. And the marketing page has some characteristics. One of the characteristics is that it will never be changed. It's a landing page, it's going to be used one time for a short period of time. Maybe it's a promotion that your company is running and then it's going to be taken down. So you can think about maintainability as one of the outputs from the function. So if you can think of a couple more variables, a couple more inputs to this function, then you can start playing with those variables to get the right kind of output. Imagine the particular personnel and the amount of energy that you put into the function. Now, it gets very interesting when the types of arguments that you take into that function are things like time. You can imagine the same function having a different output based on time. And we might even be using these different kind of arguments to represent other more primitive arguments. For example, how does time actually change things? Well, over time, culture changes. So the receptiveness to a given product in the market is highly dependent on culture and culture changes with time. So we can kind of use time as a way of estimating how different culture may be. You can imagine that culture will be slightly different in one year, slightly more different in five years, and even more different in 10 or 15 years. So the entire goal here is not to actually come up with the perfect function that describes your most optimum solution. That would be prohibitively expensive and ultimately probably pretty difficult to do as well. But instead, it's to shift your thinking away from this flat structure, this linear structure of bad versus good, this false dichotomy, and instead to start thinking about some key factors that help you make your decision. Think about those factors and how they change as you shift just one factor at a time. This can not only help you make better yes and no decisions, but it'll also help you find parallel opportunities. Things that may be similar, but one of those arguments to your function would shift it a little bit. Over time, your brain will use these functions to learn. You can think about your brain as kind of similar to a trained model. And so if you can improve the underlying models, then the immediate responses in your gut intuition will follow suit, given enough time and given enough iteration over those functional ways of thinking. So this kind of thinking will not only make you a short term better thinker and make your decisions more representative of your goals, but it'll also change the way you operate in a longer term scope as well. Thank you so much for listening to today's episode of Developer Tea. We wouldn't be able to do what we do here on Developer Tea without spec.fm. Spec is a network for designers and developers looking to level up in their careers. Tons of other wonderful content for designers and developers. However, to spec.fm also, you don't have to be a designer developer. You could be a product manager. You could be someone who doesn't work in this industry at all. And there's tons of valuable content at spec.fm for you. Thank you again to today's producer, Sarah Jackson. We also wouldn't be able to do the show without your help. This show only exists because it has listeners and the best way to ensure that Developer Teacontinues to thrive is by providing other listeners with a good reason to listen. So if you'll share this episode with someone you think will appreciate it. Or if you leave us a review on iTunes, this helps the show tremendously. Thanks so much for listening and until next time, enjoy your tea.