Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're going to be talking about the conundrums of comparison. Thank you to today's sponsor, hired.com. If you are a developer or a designer and you're looking for a job and you don't know where to start, go to hired.com today. Of course, there's a special link in the show notes. We'll talk more about what hired is offering exclusively to developer T-listeners later on in today's episode. But first, I want to jump straight into today's content. I've got a ton of content to cover today and as you know, only a short amount of time to cover it. So I want to jump straight into talking about comparison. Some of the problems that can be a part of comparison. Comparison is an incredibly powerful tool, but it can also lead our minds into believing things that we shouldn't believe. So we're going to expose some of those issues in today's episode. You know, our brains constantly analyze our surroundings using many different types of information and input. We're extraordinarily capable, for example, of recognizing something that resembles a human face. We're also very good at compressing our surroundings, so to speak. We learn the basics of a physical space and we tune out the things that we don't need to focus on. We tune out the textures of our desk and we tune out the edges of our computers and instead focus on the things that we need to focus on. We discuss this particular phenomena in a previous episode or two. When we talked about routines, we also talked about when to break from your normal routine and how to kind of force your brain to not compress the world around you so that you can see those details again. But today we're going to be talking more about comparison specifically. Comparison is an incredibly complex subject and it's one of the richest landscapes to study for psychologists because it consumes so much of the way humans make decisions. Decision research has only scratched the surface when it comes to why humans behave the way they do. And comparison is one of the core pillars, if you want to talk about it that way, it's one of the core pillars of decision making. So I want to start by kind of defining what comparison is in its simplest form. Comparison simply consists of taking two things and determine how they relate to one another in one or more factor. For example, comparing one person to another or comparing humans to plants or stars to planets. But comparison isn't only limited to those physical things, it can also be applied to abstract ideas or concepts. We may compare the beliefs of one person to the beliefs of another or one time period to another time period. We typically use comparison to make decisions by analyzing different variables of those decisions, different variables of the actual decision itself and the outcome of that decision. For example, should I buy a laptop or a desktop computer? Well, one allows me to go mobile and the other one doesn't. So let's go with the laptop. Now what brand should I buy? What screen size? All of these decisions come down to comparing two distinct options. And there may be multiple tiers that we compare on, one or more aspect of those multiple options. Comparison may also be used to compare something to nothing. For example, should I buy a computer at all versus should I buy a laptop or a desktop? The negation of having something or doing something. These are also decisions that can be made using comparison. Of course, this process is incredibly complex and tricky. And many times we think we have a full grasp on all of the variables in that subject in that particular comparison. But quite often we make bad comparisons. We make bad decisions. I want to try to illustrate this through an example here. So imagine you have just won the Powerball lottery. Congratulations, you've beat all of the odds and you've won an incredible amount of money. You are looking to ship your brand new Dreamcar across the Atlantic Ocean. Now the car costs you $150,000. And you go to the shipping company and they tell you that they can ship it for just $10,000. This seems like a decently reasonable price for such a major job. I mean, after all, you just spent $150,000 on this thing. What's another $10,000? Now, let's reframe that same type of situation. Imagine you didn't win the Powerball, which is most people. Imagine that you didn't win the Powerball, but you still have an old beater car that you bought for about $4,000 10 years ago. And you're looking to ship that car by the same company from the same location to the same location. And the shipping company tells you they can ship it for $10,000. Now, this seems outrageous, doesn't it? But logically, there's nothing anymore outrageous in one scenario than the other. Why do we think this way? Well, this brings us to our first conundrum of comparison, the relativity conundrum. Often, we try to identify relation between two elements where there is no actual relation. In our car example, there's no relation between the cost of the shipping job and the cost of the thing being shipped, assuming, of course, that you're not paying for insurance on that shipping job. And yet, when we compare those scenarios, it's difficult to separate those values. This is very much related to our tendency to draw cause from statistical correlation where the measured elements may not necessarily have anything at all to do with each other and instead are only coincidentally correlated. This comes up with bug testing and debugging all the time. We find what we think to be the cause of a problem and we chase it down and we chase it down and ultimately it ends up being totally unrelated to that particular problem. It just happened to occur around the same time. We're looking at the logs and we see that the server went down at the same time that somebody tried to upload a photo. Maybe this is totally unrelated and maybe it's not and maybe our reporting just doesn't have the right level of granularity to tell us that. We have to be very aware that the two things that we compare, the correlations that we find are not necessarily going to be related. They are not necessarily going to have causation if you want to use the term that is so commonly used. Correlation does not equal causation. I want to take a minute or two to talk about today's sponsor, hired.com. On hired software engineers and designers can get five or more interview requests in a given week. Each of these offers has salary and equity included up front and they have full-time and contract opportunities. You as the user, you can access hired totally for free, by the way. You can see your interview requests before you ever even talk to the company and accept them or reject them. You don't have to worry about awkward encounters. And hired works with over 3,000 companies from startups to large publicly traded companies. And these are companies that are not just based in San Francisco, but in 13 major tech hubs in North America and Europe. And again, it's totally free for you. If you do get a job through hired, normally hired gives a $1,000 thank you bonus. But if you use a special link that you can find in the show notes, hired is doubling that bonus to $2,000 when you accept the job. That bonus doubles just for using the link that you can find in the show notes. Those show notes are at spec.fm. Of course, every episode of Developer Teacan be found at spec.fm, as well as other fantastic shows from spec. So go and check it out, spec.fm. Thank you again to hired for sponsoring today's episode. And let's get back into talking about the conundrums of comparison. The second conundrum is the decoy conundrum. And this one's kind of simple. Let's say you have two options presented to you. The first one seems relatively acceptable. It's not the best in the world, but it's also not the worst in the world. You're not totally sold out on that particular option. But then the second option is revealed. And it is absolutely out of the question. It is totally not acceptable. Well, our tendency is to respond to this by quickly running back to the first option and feeling totally resolved in that particular scenario. This can cause problems because we often forget to introduce a third option. And we also forget some of the shortcomings of that first option. We fall victim to our comparisons because we create that false dichotomy again. Instead, we should be very careful to identify when a decoy is introduced because in that situation that decoy is never going to be chosen. And it's likely that it is introduced obviously to push you towards the other option. And it could be that this is done unintentionally. So you don't need to necessarily demonize the people who are introducing the decoy option. They could possibly be falling victim to the third conundrum. And the third conundrum is called the anchoring bias or the anchoring conundrum. Anchoring is used in sales negotiation all the time. It's similar to the relativity conundrum. We discussed this tendency to compare things using correlations that don't necessarily exist. For example, shipping costs being related to the cost of the item being shipped. But the anchoring conundrum is slightly different. The anchoring conundrum occurs when a particular aspect of something is evaluated initially, creating a frame of reference for that particular option. That same aspect is then reframed, causing a different response based on the initial frame. That's the important part. The initial frame had to be in place before it was reframed. So let's look at a fake example here. Imagine that you have wanted a particular backpack for a while. I'm using backpacks because I personally love backpacks. I have too many of them and I'm addicted to it. But imagine you have one in mind. And the normal price for that backpack is an astronomical $850. You love that backpack and you perceive the quality of the backpack to be very high, but you're not really willing to pay $850 for it. Then all of a sudden, you get an exclusive email for one time deal to buy that backpack for $400 more than half off. You immediately press that buy button. But if we take a step back and look at the backpack market, all of the backpack options that you have, $400 isn't really drastically different from other backpack prices. In fact, the number we focus on more is the more than 50% off. In fact, a $400 backpack is probably at the top of the line for most backpacks. Now, if instead the backpack for always $400, and it went up to $850 one day, we would think that the company was totally out of their minds. We use this comparison with the original price to justify our decision and then relate our decision to the availability, to the market, and our personal exclusive opportunity via that one day email to justify our more than purely financial logic. Again, this can be seen in our jobs. We could fall victims of this in the hiring process. If one person, if they are demanding a salary of $120,000 and then you negotiate them down to $90,000, it may feel like you are getting a deal, but if somebody who initially was asking for $60,000, it changes their tune to $90,000, well now it feels like you are getting the short end of the stick. The reason for that is because of the initial frame, all things being equal. Imagine that that $60,000 person could produce the same type of work and brings the same value as the person who initially demanded $120,000. We do this in our jobs every single day. A perfect example of this is performance engineering discussions. Let's say you have two web servers. One responds on average five times faster than the other. Now which server would be more appropriate for your organization? Your gut reaction may say, well, the faster one obviously, right? But there's a few problems with this question, with the framing of the question. Number one, we're only looking at one dimension of the decision. In other words, we aren't talking about cost. We aren't talking about the capabilities of the server. We aren't talking about what that particular server is faster at. We just have this one very simple dimension that we're trying to make a decision on. This is far too narrow to make that kind of decision. Another problem is we're not discussing the necessary numbers to make the decision. We don't know how much faster of what number. In other words, it could be 10 seconds and 50 seconds or 10 milliseconds and 50 milliseconds. We don't really know. We've set up a scenario where one or the other seemingly must be chosen. This is kind of the third problem with this particular question. Should I choose this one or that one? What about a third option or what about changing one or the other of those servers to be more appropriate for my organization? If you're pitting these two things against each other, you're creating a false dichotomy there. The reality may be that the servers are identical and one is serving with a response of 25 milliseconds and the other one is 5 milliseconds and practically speaking, either of those servers would likely work perfectly fine for almost any web server scenario. The question in and of itself has some issues. We've discussed a few of these conundrums that are related to comparison. This is something that I'd love to focus on more in future episodes of Developer Tea and how to escape these biases. We talked about cognitive biases last week and we're talking about comparison conundrums. These are very tightly related to some of the biases as well. All of this is very important for the way we make decisions and our decisions kind of frame the way that we actually execute our jobs. I think it's incredibly important for developers and really anybody who is at a decision-making level at their jobs. It's important for us to understand how we make decisions and also understand our natural tendencies as humans. I'm going to focus more on this in the future and hopefully you enjoy this content. I hope you have enjoyed today's episode. Thank you so much to Hyde for making it today's episode possible by sponsoring Developer Tea. Make sure you go to the show notes and click on the link for Hyde. You can get a doubled bonus if you end up getting a job through Hyde. Thank you again to Hyde for sponsoring today's episode. I want you to take two minutes to go and subscribe to Developer Tea and leave a quick review in iTunes. This is the best way that you can help other developers just like you find Developer Tea. And that in turn helps Developer Teacontinue doing what we do here. I wouldn't be able to do this show unless there were people listening and unless there were sponsors who sponsor the show. So thank you to all of you who are listening and thank you so much for making it possible for me to continue making this show. Thank you so much for listening and until next time, enjoy your tea.