Developer Tea

Context-Dependent Decisions and Linear Heuristic Mental Models

Episode Summary

Which language should you learn? Which book should you read next? In today's episode we're talking about intentional decisions we make and how those decisions can shape our immediate and long-term reality.

Episode Notes

What effect does your value system have on your personal and professional growth?

In today's episode, we're talking about context dependent decision making and how your current state of mind can influence decisions you make on a day-to-day basis and influence our happiness long term.

๐Ÿ™ Today's Episode is Brought To You By: HeadSpin

With HeadSpin, you only need one platform for testing, monitoring, and analytics across applications, devices, and networks. Check them out at headspin.io

๐Ÿงก Leave a Review

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.

๐Ÿต Subscribe to the Tea Break Challenge

This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.

Episode Transcription

Which language should you learn? What book should you read? Or what sorting algorithm should you use? Which car should you drive? Or should you drive a car at all? What school should you go to? Or should you go to school at all? These are all questions that hopefully are obviously incredibly context dependent. Today we're going to talk about some of the intuitions around how we solve these problems and how those intuitions might lead us down a path we don't really want to go down. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective and purpose in their careers. I want you to answer this question for yourself. How long should a podcast be? This is a loaded question for Developer Tealisteners because this show is intentionally short. We try to keep as many episodes as possible under 15 to 15 minutes on average and sometimes interviews go a little bit longer but for the most part. This show is intentionally short. We cut out most of the fluff and we focus on a very narrow amount of content. You might be biased towards the shorter end but it's not as simple of an answer as it seems. Who are you asking? Are you asking the content producer? Or are you asking the subscriber? And what kind of podcast exactly are we talking about? This only scratches the surface of how people may answer this question. We have some kind of analytics that can guide us towards a good answer but here's the problem. We haven't really even defined what makes an answer good. When we say how long should a podcast be, we probably have a shared assumption that we're asking how long should we make a podcast that appeals to the most listeners. Generally speaking, a lot of our heuristics tend to follow some kind of capitalist rule of utilitarian value. You'll see this pattern over and over. What is the implicit value that is described? Well, the greatest good for the greatest number of people or in the case of a podcast, the greatest number of listeners who are willing to tune in. And again, the implicit assumption is the more listeners we can attract, the better. And so when we ask these questions, the questions that have a should towards the beginning of them, we tend to assume an implicit value system. That implicit value system is usually influenced by our generation, our culture, our personal experience, and then eventually our own goals, our own tastes, the things that we personally appreciate. But this is somewhat of an aside from the main point of today's episode and that is that things are context dependent even for the same person. So for example, if you ask someone how long should a podcast be, it might depend on what that person is doing at the moment. They might want to listen to a two hour long podcast on a flight or they may be on their commute in the mornings and they might listen to a 20 minute podcast or right now in their current context and during a global pandemic, they may not have a commute. And so their podcast listening may have essentially gone to zero. But the point here is that the same question may have different answers for the same person. Now this should be really obvious, right? We know that we have different types of tastes. That one night we want a particular type of meal and the next night we want something totally different. If I'm going to eat sushi 20 times this year, well I don't want to eat those 20 different sushi meals back to back for some reason I prefer to space those out. And I might eat more sushi in one season than another. So we've established that we have different answers for the same question for a given person. And we've also established that our values when we are answering these kinds of questions are very often implicit. We're going to talk about today's sponsor and then we're going to come back and talk about how our heuristics for these different answers might lead us to believe something about our own preferences, something about our own tastes, about what would make us happy or would achieve our values. Believe something about those things that isn't true. Today's episode is sponsored by headspin. Has been from mobile. Headspin is made for any application whether you're doing a native app or a web app and you can run on any device on any network pretty much anywhere in the world. It sounds incredibly flexible because it is with headspins patented global device infrastructure you get sem-enabled devices on real Wi-Fi and carry your networks with 24-7 remote access. In addition, headspin provides AI-powered analysis which tracks user experience metrics and KPIs over time. With headspin you can even do things like cold and warm starts, errors, crashes, response times, audio and video quality and even biometric responsiveness. These are the kinds of things that headspin will track. You can learn more by heading over to headspin.io. That's headspin.io. Thanks again to headspin for sponsoring today's episode of Developer Tea. So I'm going to take a question that I asked earlier and change the way that it's formatted. The way that you answer this question will potentially lead you towards the thinking that I'm talking about. Which is better? A shorter or longer podcast. This question is intentionally framed for you to pick one or the other shorter or longer. Once you pick a side of this, note that we haven't explained exactly what that line is, what exactly constitutes a short podcast and what exactly constitutes a long podcast. This question is framed in a way where you choose a direction rather than a specific discreet answer. And if you'll notice, this is very similar to many of the other binary choices that we make. And even more mirrors, particular types of questions like do you lean left or lean right? These kinds of directional questions don't have any discreet marker point. Everyone fills in the blank for that. And they don't have any discreet end point either. If you lean right, you could lean very far to the right. Or if you lean left, you could lean very far to the left. And here's why this is important. If I ask you which is better a long or short podcast and you say long, then I could imagine that I could increase the length of the podcast. Let's say I double it. It's 30 minutes. Now let's say I triple it or quadruple it. We get to the two hour or three hour territory. What if it's six hours long? Here is where things start to break down. And that's because the question didn't include the framing or the boundaries. Now of course it seems like we would be able to detect this right away. Like very quickly we could say, well, we didn't mean six hours. Long podcasts tend to be an hour and a half to two hours. And short podcasts tend to be less than 30 minutes. And so we may have these implicit groupings. And very likely we share those implicit groupings with many other people. And so while in theory you may agree that making it longer is better and making it shorter is worse or vice versa. Practically you kind of know what you mean, right? But this comes back to bite us very often. For example, most people might expect that more exercise equals better health. And so in a linear fashion it's easy to believe that if you exercise seven times per week once a day, then you're going to be seven times more fit or seven times healthier or whatever metric you choose. Seven times that of someone who only exercises once per week. Now the thought experiment is very clear once you imagine what the effect would be of exercising no times per week. Clearly people have different levels of fitness even if they don't exercise. And so there's something more at play. And in fact the most likely optimum amount of exercise includes resting periods. So one time is probably not optimal and seven times is also probably not optimal. But because our brains are somewhat addicted to these kind of linear heuristics, right? More is better or more is worse. We tend not to think in those nuanced details. Those more complex systems that actually govern our reality. And the truth of behavior science is that we need to take advantage of those simple systems. We shouldn't try to hijack those heuristics and replace them with longer, more arduous thinking because we're not going to reach for that in the moment that we need it the most. It's generally a good idea to allow people to encourage people even to believe that more exercise is good and less exercise is not as good. For most people this simple linear heuristic is going to do them more good than harm. Once again we're assuming that our implicit goals are the best health for the largest number of people and we're also assuming that the few people who overexercise, well they're kind of on their own in this model. And it doesn't just happen when we're talking about links of podcasts and exercise. This happens all the time, very practically when we're coding, but also when we're trying to make business level decisions. For example, what got you your first hundred or 500 customers and even what keeps them around is very unlikely to be the same strategy that you need to use to go from 500 to 50000. And once again from 50000 to 50000 or 50000. It's easy to believe that if you spend $100 on advertising and that nets you let's say five customers that your return on investment of advertising is 5%. But this doesn't take into account things like network effects. Additionally, even if your return rate is 5%, is it possible that you could get a better return with that money? When you think very simplistically with these linear heuristics, it's very likely that you're missing something bigger. You're missing a more important piece of the puzzle. We know also that these apply these kind of context dependent ways of thinking. You can think about these as kind of mental algorithms, strategies for solving problems. They apply in specific scenarios for code too. For example, you might use a different sorting algorithm if you have a large data set versus a smaller data set. Your context is incredibly important and it's easy to believe that your model for one kind of particular scale of a given problem is going to apply across the whole scale continuously. Let me give you a final example to kind of drive the point home. I want you to think of something that makes you happy, something that you enjoy doing or perhaps a favorite food, time with a special person in your life, something that you generally would like more of. A very simple example of this might be playing a game you really enjoy or eating chocolate. Both of these happen to be favorite pastimes in my house as it turns out. If I eat too much chocolate or if I play the game long enough, I'm going to feel sick or I'm going to feel bored. Very often in many ways our eyes are bigger than our stomach. In other words, we predict that more of something that we like will have a continuous and endless positive effect on our well-being or on our happiness, on our mood. When in reality, our thresholds are probably much lower than we expect. And similarly, our thresholds on the opposite end, something that might make us think that we're going to be very unhappy if it happens. Because it turns out our thresholds tend to be much higher on that end of the spectrum. For example, studies show that people are very resilient to even the most extreme of life-altering accidents that leave you paralyzed or even blind. Of course, that doesn't mean that we're immediately resilient, but over the long term, multiple months after an accident like that occurs, people tend to return to kind of a stabilized base level of happiness. So what exactly is the takeaway? Well, what we want, what we believe to provide a particular output, whether it's for our personal happiness or in the context of a working problem that we have, very often what we expect based on a small subset of problems or based on a very simple heuristic doesn't actually pan out for the larger picture. Our heuristics tend to be linear. They tend to cut out a lot of important information and interacting variables that we couldn't really model for in our quick heuristics. And so we very often, we tune for the wrong things. We try to maximize in one area, totally ignoring the other area, for example. So what should we do about this? Unfortunately, there's not a lot to be done, but one thing that you can really focus on is understanding the context that you are solving for. And specifically your personal context. In addition, you might watch out for the kind of question that I asked at the beginning that tries to polarize you and doesn't provide any boundaries for that polarization, the directional polarization kinds of questions. Finally, remind yourself what your real goals are when you're thinking of a should kind of question. One that asks which direction is better. When you have that kind of question, be more explicit about what you're trying to optimize for. And if you're on a team, make sure that the team understands together what that shared goal is, what that shared optimization output should be. By making these adjustments to your thinking and slowing down, especially with really important problems that you're facing, you might be able to avoid substituting a bad heuristic for a more complex system that deserves exploring. Thank you so much for listening to today's episode. Thank you again to headspin for sponsoring today's episode, head over to headspin.io to get started today. Thanks so much for listening to this episode. If you haven't yet subscribed to this podcast, I'd encourage you to make that kind of fork in the road decision today. It sounds really on the nose. I'm trying to get you to subscribe, but the reality is I truly believe it's better for you to be deliberate about how you want to spend your time. And if you think this podcast is a good use of your time, then subscribing is one of the best ways to keep up with it. But if you don't think that this is a good podcast for you, then choosing to spend your time with something else, that's probably a better idea. And for those of you who have already chosen to subscribe and you've found a lot of value out of this podcast and you're looking for a way to kind of give back one of the best ways you can help the show out, probably not very surprising. Leave a review in iTunes. This helps the show in two really important ways. One is obviously it's going to help us with our ratings. It helps the show climb in the rankings so other people can find it. But then of course, with other developers reading your review, they can make that decision to subscribe themselves. Thank you so much for listening to today's episode. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.