I want you to think about a belief that you hold relatively strongly. For example, something that is fairly common knowledge that's verifiable by science like the Earth being round or close to round. And I want you to take a moment and answer this very simple question. Why do you believe that in this case, the Earth is round? It seems like a simple question and it seems like it has a simple answer, but the truth is probably a little more complicated. In today's episode, we're going to take a slight detour and talk about our reasoning and why our beliefs might be a little more complicated than even we think they are. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective and purpose in your careers. So we'll come back to the question of whether the Earth is round. And instead, we're going to talk about something that's perhaps a little bit easier to have different answers to. Like how should we build our JavaScript application? What kind of tooling can we use? What is best for our particular situation? These questions seem harder to answer. And this is somewhat paradoxical. The question of what shape the Earth is seems a little bit harder to verify than what language should I learn coming out of college. And yet we have a strong conviction on one belief and less of a strong one and even arguments about the other. So what is happening here? And why is it that your belief about the Earth being round is probably not just based on science? As it turns out, humans very often, when they're faced with difficult questions, provide substitute answers. I'll give you another perhaps less consequential question. What would you like to have for dinner? If you go out with your friends or maybe your significant other and you're trying to decide where you want to go to eat dinner. And next time you ask this question, I want you to notice the types of answers that you provide. Usually, the answers are not straightforward. The answers aren't simply, I want x, y or z. Instead, the answers are often formed through some kind of reasoning, some kind of construction to explain to ourselves why we want something. For example, you could say, what would you like for dinner? And my answer might be, well, I had Chinese last night and this afternoon, I had a salad so I want pizza tonight. It's asking difficult questions like, what language should you learn after college? Well, it requires a lot of analysis. So you may substitute the question, which language is most popular? In the same way, when you're asked whether the earth is round, you probably are not drawing on your own personal study, your own scientific verification. In fact, you probably aren't even surveying the scientific verification of other scientists who came before you. Instead, you are probably substituting the answer to what is the consensus amongst the scientific community. We do this kind of substitution all the time, not because it will produce the best answer, but instead because, well, it's more efficient. We can often rely on things like consensus to get us a reasonable answer. In other words, if you can trust that a lot of the scientific community is not colluding, they're not trying to convince everyone that the earth is round for some nefarious reason. And instead, you can default to trusting the scientific community. Well, now you have a proxy. You have an easy way of answering questions that otherwise would require some kind of expensive or difficult verification that you're not really going to do. And this outlines a key difference that our brains kind of muddy up a little bit. And that is the difference between something that you know or something that you have kind of experienced versus something that you believe. When we ask ourselves, what is the best way to solve this particular problem in code? We aren't running every possible solution and then choosing the perfectly optimal solution. Instead, we're looking back at our experience. We're trying to predict into the future which one of those experiences matches the pattern of our current problem. And then we're going to try to apply some kind of insight from that past experience. If we don't have something that matches the pattern from the past, then we use the things that we know. We use our common kind of algorithms, maybe data structures, our common ways of approaching problems, certain models that we may have, best practices. We might collaborate with other developers and their experiences. And ultimately, we're making our best guess. And very often that best guess requires some of this substitution. Instead of answering what is the best way to do something, we might substitute what is the fastest way, or maybe in a better scenario, what is the most maintainable way to do something? The substitutions often provide us the value that we're looking for, even if they aren't necessarily directly answering the question or answering the problem that we have placed on the table to answer. Ultimately, if we can be aware of when we are substituting and ask ourselves if we're OK with that substitute, we can start to better hone our choices to the outcomes that we desire. Rather than convincing ourselves that we chose the optimal solution, we can actually identify the points where we are taking shortcuts. Thank you so much for listening to today's episode of Developer Tea. If you enjoyed today's episode, I encourage you to subscribe and whatever podcasting up you're currently using. We are only able to continue what we do on this podcast because of our incredible sponsors. If you would like to partner with Developer Tea and invest in the development community, encourage you to reach out to us at sponsors at spec.fm. Thank you so much for listening to today's episode. Thank you to today's producer, Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.