It may not be immediately clear, but there's a common thread, kind of a common underlying reason. Why we over optimize our code, why you can go from one company to another and see drastically different levels of quality, even though the engineers have similar level of talent and experience, and finally a common thread between those two things and why you choose the size of coffee that you choose when you go to the coffee shop or tea, if you're tea drinker. And in today's episode, we're going to discuss that common thread. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you connect to your career purpose and do better work so you can have a positive influence on the people around you. Before we dive in, I do want to thank you for listening to today's show and let you know that I'm working on a very special project for the upcoming year. I'm hoping to launch it in early January and I want you to stay in the know. The best way to stay in the know about this project is to subscribe to the show because we don't have anything live yet. There's no way to sign up. And we'll give you more details as we continue working on this. But I'm very excited about this particular project. It's something that I've been wanting to do for a long time and we finally have enough content really is what it is to make this project actually happen. So if you want to hear more about this, I encourage you to subscribe to Developer Tea. And before we jump into today's topic, I do want to take a moment to thank today's sponsor, Manifold. Manifold has been making some updates. They have more services and all new discovery experience, refreshed dashboard and integrations and all of this makes Manifold the easiest way to build cloud native applications. Now, here's the reality. Here's what Manifold saves you from. If you have wasted your time building your own logging platform or your own content management system or your own auth service and you realized that it was more than you really wanted to take on, then you know the pain and the enormous amount of costs that you can incur. And you don't really need to because an API or a managed tool can solve the problem for you. But the reason you did it in the first place is because you couldn't probably, you couldn't find the right services to integrate. You didn't really know how to orchestrate all that together. It's easier for you to just build one, right? And as it turns out, it's not easier. It's so much more expensive. So how do you learn how to stitch all of these products that you know would probably do a better job before you, but you just don't know where they are? How do you even learn how to stitch them together? And how do you manage access to them? The credentials between the multiple projects and the multiple teams that you may be on, managing these details alone is actually a full-time job in a lot of companies, right? But Manifold can make your life easier by providing a single workflow to organize your services and connect your integrations. And you can share all this with your team. You can discover the best services for your project right in the Manifold marketplace or bring your own custom integrations and manage them all in one dashboard. Now, with services covering authentication, messaging, monitoring, content management, and more, Manifold will keep you on the cutting edge so you can focus on building your project rather than focusing on problems that have already been solved. This saves you an enormous amount of pain, an enormous amount of effort and resources. Once you have the services you need, you can deliver your configuration to any environment and deploy on any cloud. Now, you get $10 worth of credit to use on any services by heading over to Manifold.co-slash-debti. By the way, Manifold is free to use. So I encourage you to go and check it out. Manifold.co-slash-debti, that credit will go towards the services that you choose to use in the Manifold marketplace. Thanks again, Manifold for sponsoring today's episode of Developer Tea. So what do over optimization, varying level of quality between two companies, despite having equivalent engineers, and choosing a size of coffee have in common? I'll share another example that will expose this underlying, common theme between all of these things. Let's imagine that you set out to do a refactor on your code, and you cut your execution time in half. Now most developers would look at this number, most managers would look at this number and say, wow, this is excellent. This is a great improvement that you've made. The problem is that most of our judgments about these improvements that we make, the decisions that we make, the actions that we take are done almost entirely relative to an existing state. In other words, we're comparing. If we cut our execution time in half, but our execution was painfully long, like a website loading in 15 seconds, and we cut it to, say, 7.5 seconds, well, the reality is, even though the relative improvement may seem impressive, right? We cut it in half. So therefore, it seems like a good move. Still, from the outside looking in, an incredibly slow website, right? This comparison step that we take is perhaps one of the most useful things that humans can do. We're actually very good at comparison. We compare ourselves to other people. This is kind of the root of our comparison muscle is comparing ourselves to other humans around us, and that helps us decide the kinds of things that we should do. So we learn both how to be and how not to be by comparing, by observing the others around us, by observing situations and trying to size them up. So we learn to compare so that we could either mimic or avoid ancient humans if they were able to, for example, attract a mate. And we would compare ourselves to them and try to find out how they did that, right? So we're looking for success, and we're looking for failures, and we're trying to model ourselves after those successes. Part of the reason for this is because we didn't really evolve with the concept of having that macro view, the ability to look at a large amount of information, a large amount of data about humans at large. We evolved with the ability to literally see whatever was nearby, to see around us, and this is also reflected in something called the availability heuristic or availability bias. You can go and look that one up. We've talked about it on the show in the past before, but this comparison problem drives us to do things that are not necessarily rational or even in our best interest. When we choose a cup of coffee, and this is a fairly fine thing to do, no matter what size the coffee actually is, for example, it could be 16 ounces or 12 ounces, we as humans tend to choose the middle size. We don't choose the small and we don't choose the large or the extra large. We choose to tend whichever one is closest towards the middle. Now, it's not perfectly clear exactly why humans do this, but it most likely is the result of comparison. We know that we're comparing the middle size to the large or the small. Rather than making some objective calculation of exactly how many ounces we want, we choose the middle road, perhaps because we think it's most likely to be the most common size. And therefore, most other people have been satisfied with that particular size than maybe we will be too. How does this play out in over optimization? Well, remember we talked about that cutting our execution time in half. And if it's a painfully long execution time, 15 minutes or 15 seconds to load a website, 15 minutes to run a task or something on our server, and we cut it in half to 7 and a half seconds to load that same website, then it feels like a victory even though objectively, that's still an extremely slow website. But what if we look at the other end of the scale? If we get down to sub one seconds loading on a website, let's say we load the website in 300 milliseconds, 0.3 seconds. And we still try to optimize that down. We want to cut it in half again, 150 milliseconds. Or let's say that we're already at 100 milliseconds, feeling nearly instant for the human that's watching. And we want to cut it down to 50 milliseconds. Instead of kind of zooming out and reminding ourselves that every decision we make needs to be contextualized so that our comparisons are meaningful, rather than only having a relative measure, right? Rather than only measuring from where we were to where we went, we have some kind of external perspective. So we see the whole system. It's a more objective way of making the determination of how you should compare and what those comparisons mean. From there we can set better goals for how we should be comparing results, right? So the input coming in is 200 milliseconds. Well, that's fast enough. So maybe there is no optimization that needs to happen. Maybe our relative metric for optimization actually should be zero. We should have no input at all towards optimizing. And that's how we end up over optimizing in many cases is we try to chase a relative improvement rather than looking at the improvements that actually matter. A very common example of this, by the way, is trying to slim down your JavaScript file, for example, when you have very large, uncompressed images that are loading on the page. And it's much more likely that you're going to achieve the same effects, you know, much more quickly and with much less energy than if you were to try to shave your JavaScript down. And solely because those images are probably significantly larger than your JavaScript file and you're going to have significantly more savings by simply compressing them. And we mentioned the other example, the idea that you can go from one company to another. And depending on, you know, what's happening inside of that company, you could have drastically different quality, even with similarly talented and experienced engineers. So why does this happen? How does this happen? The standards that are set inside of the company and the standard that the engineer will hold themselves to are going to be relative measures. So the highest level of quality in one company may be seen as the minimum bar in another company. Now even though the engineers are talented in their experience, that doesn't necessarily mean that they can escape the relative comparison problem. So what will end up happening very often is the quality doesn't have an objective standard. There's not an external measurement of what quality means. And so quality becomes relative to the company. And in fact, you can even see companies that have a high standard for quality. And even their junior developers are producing quality that is, you know, much higher than the standard of junior developers, even senior developers in other companies. Of course, by no means is this a hard and fast rule, you're not always going to see these huge diversions in quality. You may see more likely what you'll see is diversions in focuses. So you have one company that is really highly focused on, for example, test coverage, but another company that's very highly focused on user experience. And both companies can have equivalently talented and equivalently experienced developers, designers, management, you name it. And so what we end up doing is comparing ourselves so that we can adapt to our situations rather than trying to hold to some kind of external standard because that external standard is not necessarily, you know, culturally appreciated within that company. And so once again, we use comparison to reflective values. We reflect the values of the company back into the company rather than, you know, holding our own values as extremely important to us. We're going to typically adhere to the values that we see culturally being propagated. So the simple takeaway from today's episode is the idea that comparison is a very strong behavior modifier. We don't have external, you know, measurements that we bring to a given decision most often. Typically we're trying to make comparisons between two things. When we're making a purchase, typically we're going to compare options rather than trying to make a decision based on the qualities of a given option. We're going to compare two options based on the qualities relative to each other. This is extremely important to understand in your decision making process because sometimes this can be used against you, right? This can be detrimental, of course, as we discussed with over optimization, but it can also lead to really positive effects, like for example, binding a community together. Thank you so much for listening to today's episode of Developer Tea. I encourage you, if you've enjoyed today's episode, and by the way, if you don't want to miss out on that stuff that we're talking about and talking about in the beginning, this new project that I'm working on that I can't share any more details about just yet. I encourage you to subscribe in whatever podcasting app you use and you are using right now, in fact. Thank you again to Manafold for sponsoring today's episode. You can get $10 worth of credit on any service in the Manafold marketplace by heading over to Manafold.co slash devt that's Manafold.co slash dvtea. Thanks again for listening and until next time, enjoy your tea.