happy friday everyone my name is jonathan cattrall you're listening to developer t and my goal on this show is to help driven developers like you find clarity perspective and purpose in their careers and all of us have goals the goal of this show is intentionally intentionally abstract this allows for the goal to be more like a set of principles that i can judge my efforts on this show against in other words if i ever have an episode that violates those principles then i'm probably not actually staying true to my goal but if i created a goal that was overly specific then it would narrow the lane that i can operate in you can easily look in the backlog of episodes of this show and figure out that a narrow lane just doesn't work for this for this show we have episodes that range all the way across the board from psychological principles to actual coding practices that we've talked about that are relatively evergreen but if my goal on this show was to help you get a promotion then that would be unnecessarily narrow and it would limit what i can do with the show and why am i telling you about the goal of this show well one so you understand why we do what we do here on this podcast but also because we very often do this automatically to ourselves think about it what's a recent problem that you solved in a software project that you participate on whether you're writing code or maybe you're the product owner what is a problem that you solved in a software project that you participate on a good example of this is performance issues let's say that you have a web application that has a slow endpoint on it it's returning the responses are returning they're taking way too long it's very likely that your chosen path for optimization will be highly dependent on your personal experience and your skills now you might hear that and say well of course it would be these are the things that are going to be the most important things that are going to be the most important things that i know how to do so why would i you know vary outside of that if i'm a software engineer and my responsibility is to write performant code then the choice uh the domain that i'm going to limit my solutions to is in the coding domain the actual application code so you may be less likely for example to think about the infrastructure you may be less likely to think about the location of uh the the server that's actually responding to the request. You may also be less likely to consider throwing money at the problem. Now, these are all things that are well within your reach, but there's also solutions to this problem most likely that none of your team would think about, whether you have architects or engineers or investors in the case of throwing money at the problem, I guess. Let's imagine that your expertise is in, once again, going back to the field of psychology. You might go and look at the reason why this endpoint needs to be faster to see if there's a way to convince people that it doesn't need to be faster. Of course, this is a contrived example. It's very possible that you have very strict reasons why it must be faster. Setting aside the contrived nature of this particular example, this does happen very often. In fact, it happens often enough that there is a concept, a name for this in psychology. It's called functional fixedness. Functional fixedness. This usually applies to the way we think about objects in the world around us or tools. We think about the intended use for something, and it's very difficult for us to imagine a different use for that thing. Of course, this is in varying degrees depending on how specific and how irregular it would be to use that particular object for some other purpose. But this concept in psychology reminds me of, and it seems quite related to, the fact that we choose categories as a mental shortcut. This reduces the workload on our cognitive function. So it seems logical that this is probably some similar kind of optimization that our brain is doing to reduce the amount of workload necessary. We see a thing and we associate it with a particular activity. We see a problem and we associate it with a common set of solutions, ones that we are familiar with. Ones that we can apply easily. I'll give a simple example outside of the domain of engineering so that you can kind of use this as an analogy going forward. I have a gym in my home. I built it during lockdown and it has allowed me to stay active. And so I've invested in making this space for exercising. And we've also invested in trying to make the space safer. Now there's a lot of investments you can make in a gym to make it safer. You can have a gym that's a little bit more spacious. You can have a gym that's a little bit more spacious. You can have safety bars on a rack. You can have correct storage on the walls or correct spacing between different machines or weight trees or whatever. My functional fixedness in this particular area was in gym equipment. My thought was that you needed to add certain things to the gym to that space to make it safer. But I realized that another solution, there's actually two solutions that we stumbled upon, one was removing things. Removing things from the gym actually made it safer because there's less possibility of things falling, less possibility of you running into something. There's less of an issue of a tripping hazard. The other safety improvement that I had totally ignored was increasing the brightness of the light bulbs overhead. And this seems like it would just be an ambient change in the environment. But for any kind of industrial engineer or kind of like hard sciences engineer, this would be intuitive. It might be one of the first things that you check. Is the lighting sufficient for the space that you are trying to light? And indeed, if you just do a quick Google search for the IEEE standards for lighting industrial spaces, that definitely exists. Now, this is not something that I would encounter on my regular everyday home gym owner kind of mindset. So my functional fixedness is, in that consumer mindset actually of home gym ownership, where it's usually something new to add. And this is partially because for so much of the time that I've owned a home gym, which is only a few years, the kind of mode of operation was to purchase something to add to the home gym to improve it. So this created that functional fixedness. I'll give one more quick example. It's pretty well established that good quality sleep is very, very important. And I think that's important. But how we get good quality sleep can be a little bit elusive. We might spend a ton of money on a good mattress, which I have done in the past. We might spend time researching exactly the right kinds of time to fall asleep. What can we do? What kind of noise can we play in the background? What should we set our temperature at? But something occurred to me this week that had not occurred to me before. And I've drastically changed my sleep style. I've changed my sleep style. I've changed the quality of my sleep with about 20 minutes and less than a dollar or two in investment. You see, I sleep next to my partner, my wife, Lauren. And historically, when either one of us would move around in the bed, it would squeak quite a bit. And we had kind of put off fixing it because it seemed like just a nuisance when we were awake. But I'd never considered that maybe, just maybe, that is disrupting my sleep. So I got four lag bolts and we fixed the bed thinking that we were only fixing the nuisance. As it turns out, the side effect was we started sleeping a little bit better. Now, the theme of both of these things, if you'll notice, is that the fixes or the improvements were actually pretty low investment. These were not very difficult to accomplish. They didn't take a lot of time and they didn't take a lot of resources. The same is likely. True in most problems that we face. We've talked about the importance of leverage on this show. And this kind of thinking, being able to break out a functional fix in this is one of the most critical ways to help you find leverage. Find things that have high return, but low investment. This means that you have to kind of break out of your thinking in terms of what your tool set is. Try to get to the core of the problem. And we've talked about ways to get to the core of the problem. You've probably heard plenty of kind of tactics for that, like asking the five whys. And part of the purpose of those tactics is to enable breaking out of your functional fixedness. If you were to start with just that first why, for example, we need to improve the response time of this endpoint. Why? Because it's too slow for service X over there. To consume it in the reasonable amount of time that they need to. If you stop there, the corridor of your likely solutions, right? Your total domain set of solutions is narrow. The more you ask why, the more likely you are to find a better comprehensive domain of potential solutions. And you're likely to increase the potential for that set of solutions to contain one that is higher level. So if you're looking at a set of solutions that are more leverage than the original set, think about this. All you're doing is investigating the problem a little bit more. And you're opening the door to potential higher leverage opportunities than you had found before. This is absolutely related to substitution or substitute questions. The idea that when we hear a question that's hard to answer, we tend to substitute it for a reasonably appropriate, but much easier to answer question. Sometimes what we should do instead is investigate the original question and learn more about the context that it's being asked in. My challenge to you today is to stop your thought process when you recognize that you are narrowing in. When you recognize that you're participating in this functional fixiness or identify when you hear someone else participating in it. Now, whether you identify that to them or not is up to you, but being able to recognize when functional fixiness is at play is a first step towards trying to expand that thought process. My bet, and you can correct me if you think I'm wrong here, my bet is that you will recognize that the substitution of the question has occurred and you may be able to ask a better question. Thanks so much for listening to today's episode of Developer Tea. I hope this concept of functional fixiness is helpful to you. Maybe it's enlightening to you. If you enjoyed this discussion, I'd encourage you to continue the discussion in the Developer Tea Discord community. Head over to developertea.com slash discord to join totally free today. Thanks so much for listening. Have a good Friday and a good weekend and enjoy your tea.