But when it comes to making decisions, we have to simplify. That's what we're talking about in today's episode. My name is Jonathan Cutrell. You're listening to developer TMI goal on this show. Please help driven developers like you find clarity, perspective, and purpose in their careers. Think about the last big problem that you solved. How did you solve it? Think about the biggest product that you've worked on. For most people listening to this show, it's a product that you couldn't think about in one go. In order to explain everything that's happening in the code, it might take you hours or even days to even remember it all. And yet, it exists. Of course, the answer in its simplest form is that you decompose the problem. Instead of one big problem, which is not really one big problem anyway, you decided to approach each small problem that the big problem actually represents. Making these problems down into their sub parts. Decomposing from the top and then composing from the bottom. This is how we build complex software. We don't build complex software. We compose it. The subtle difference here is that each of the pieces that we're composing the complex software from are simple. And in today's episode, we're not going to talk about the process of decomposition. Instead, we're going to talk about an underlying principle, the principle that makes decomposition work. And it's not just about decomposition. This is also about, for example, debugging. It's also about finding your next job. It's about making a decision in a complex environment with a bunch of competing interests. This principle is a principle of isolation. And if you've had to make a complex decision before, you have done some form of this, whether you know it or not. Now you can either do accidental isolation or intentional isolation. We're going to talk about both of those right after we talk about today's sponsor. Today's episode is brought to you by Square. There are millions of sellers across the globe using Square today to run every aspect of their business. And many of them are looking for customized solutions that are deeply connected and easy to use. They don't have developers on their team, and that's where you come in. You can grow your business by extending or integrating with Square using free APIs and SDKs to build tools for those millions of sellers. Learn more by going to developer.com slash square. That's developertea.com slash square. It makes again the square for supporting Developer Tea. Let's say you're at the grocery store and you're trying to pick what cereal you're going to buy today. You look at the top line and you see brands that you recognize, things that might have some nostalgic value to you. And then you look at the line below that and those are the healthy brands, things that have a different kind of value. And then below that you might see the off brand versions, the kind that are virtually identical to the ones above them, but don't necessarily carry the same brand value that you come to know. Real again you might see some organic brands and you may also see the bulk brands, the ones that are the family size. All of these different cereals are selling you on different types of value. And your job is to decide which one of these boxes is for you. If you're like most people and you're going to try to optimize for as many of these things as you can. Of course, you may have both hard rules like you won't spend more than X number of dollars per box. And then you may have soft rules like you want to avoid too much sugar. Using these rules you create a subset of the super set. In other words, a handful of cereal boxes that you're actually considering that you've ruled out the rest. And then you make the decision. At this point you may have run out of rules to use. You may be going off of intuition or memory. Maybe you usually buy this cereal and you know that someone in your house likes it. These are not rules necessarily. They may be taste profiles. Ultimately, you end up choosing a box of cereal. And this isn't quite the explicit process that most people flow through. Many times people use much more heuristic processes. They go with something they know, for example. And I'm not here to help you make better cereal choices. Instead I'm here to not allow your habits of decision making when you're choosing cereal to carry over to bigger decisions like who to hire or what place you're going to work at next. In situations where the impact of the decision is sufficiently important is sufficiently large, it makes sense to employ isolation. Okay, so let's talk about this principle of isolation. This is a skill that we learn in many different domains. The skill is practiced differently in those different domains. But the basic underlying principle is the same. In other words, let's imagine that you have three candidates on the table and you're trying to determine which of these are you going to hire. How do you determine what specific thing or perhaps things should you use? This is the criteria that you base your decision on. This isolation process is not necessarily easy. There's not one way to do it. You can't just ask what are the specific criteria that I'm going to use. Sometimes you may have some intuitive answer, but usually this requires more advanced thinking and discovery and technique. For example, you might perform a thought experiment. In the example of having three different candidates, imagine that all of the candidates had the same qualifications and then use one of those qualifications as a modifier. Let's say for example that all three candidates have different education levels. They also have three different work histories. Maybe they have three different primary areas of focus. For the sake of the thought experiment, imagine that their education levels are equal. How does that affect the way you think about the candidates? What you're trying to sort out here is some kind of waiting or some way of understanding each of these components, these factors that you're optimizing for accidentally. Again, we were talking about accidental isolation. Sometimes we accidentally isolate by over-weighting things that we don't really want to overweight. Let's say for example that you're conflicted about which person that you want to hire. Well, thought experiment may eliminate factors that you didn't realize, whereas we're playing as big of a role in your decision as they were. For example, let's say that you have those three candidates, one of those candidates was referral from another person in the company. You may really want to hire one of the candidates who was not a referral, but you feel conflicted because of the fact that the other one was a referral. You have these two candidates. You've already ruled out the third one. What happens if you imagine that the candidate was not a referral? You can quickly recognize is just how much you are weighing the referral as a factor in your decision making. You can isolate these factors going back to our principle in this episode as isolation. When you can isolate the factors, then you can measure them better. Talking about a totally different application of isolation, we can think about our software engineering process and each of the tasks that we are going to accomplish in a given iteration, we can use isolation in those environments as well. The skill of isolation is, for example, one of the most important things when determining priority order. If you had to do only one thing, if you had to isolate one delivery that would come next, what would it be? This skill transfers in so many domains and it's necessary to learn the different tools and the different processes that you can use to improve your ability to isolate. Sometimes those tools are very mechanical. You can do them literally using code or you can use something like a basic learning algorithm, even things like Excel, it might be able to help you. Other tools may be a little bit softer, like thought experiments that we discussed in this episode. Ultimately, the idea in all of these situations is the same. And the most atomic and most essential parts of the puzzle that you're trying to solve. Thanks so much for listening to today's episode of Developer Tea. Thank you again to Square for sponsoring today's episode. However to developertea.com slash square to get started, building four millions of sellers around the world today. Thanks so much for listening to today's episode. If you enjoyed this episode, I'm going to ask you to do two things today. Again, if you've never left a review for Developer Tea, we absolutely rely on those reviews to help this show spread to more engineers. So either leave a review or share the show directly with somebody that you know that you think will enjoy it. That's a direct way to give back to what we're doing with Developer Tea. The second thing I'm going to ask you to do is to join the Developer Tea Discord community. You can head over to developertea.com slash discord and we have discussions like this one all the time. It's totally free. There's nothing to lose on that one. You might gain some good networking with other like-minded engineers like you, other engineering managers. Go and check it out. It's totally free developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.