Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, 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 Tea 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. You know, comparison is an incredibly powerful tool. But it can also lead our minds. It can 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 discussed 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. 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. 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 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? What brand should I buy? 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 dream car 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, right? Right. Right. Right. Right. Right. Right. Right. Right. Right. It 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. You're looking to ship company from the same location to the same location. The shipping company tells you they can ship it for $10,000. This seems outrageous, doesn't it? But logically, there's nothing any more 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 be the same. So, we're going to try to identify the relationship between the two elements 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, right? 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, right? So, 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. And 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. And you can see your interview requests before you ever even talk to them. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. And you can also get a free trial of Hired.com. 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. The anchoring bias or the anchoring 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. The anchoring bias or the anchoring conundrum is slightly different. The anchoring conundrum is same aspect is then reframed, causing a different response based on the initial frame. Now that's the important part. The initial frame had to be in place before it was reframed, right? 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 a 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. And 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 were always $400 and it went up to $850, 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. Now, again, this can be seen in our jobs. We could, in fact, fall victim to 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 changes their tune to $90,000, well, now it feels like you're getting the short end of the stick. And the reason for that is because of the initial frame, all things being equal. Imagine that that $60,000 is going to be $90,000. 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, 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 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 is, should I choose this one or that one? Well, what about a third option? 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. So the reality may be that the servers are identical and one is serving with a response of 25 milliseconds and the other one is five milliseconds. And practically speaking, either of those servers would likely work perfectly fine for almost any web server scenario. So the question in and of itself, has some issues. And so we've discussed a few of these conundrums that are related to comparison. And this is something that I'd love to focus on more in future episodes of Developer Tea and how to kind of 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. So all of this is very important for the way we make decisions and our decisions kind of frame up the way we make decisions. And so I'd love to talk about some of these the way that we actually execute our jobs. So 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. So 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 Hired for making today's episode possible by sponsoring Developer Tea. Make sure you go to the show notes and click on the link. For Hired, you can get a doubled bonus if you end up getting a job through Hired. Thank you again to Hired 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 Tea continue 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. Thank you.