In the next couple of episodes, I'm going to spend some time talking about how we construct software. Not how we construct it in our editors, not the syntax that we use, but instead how we mentally construct software. This isn't going to be a comprehensive set of episodes, but rather these episodes will intentionally spark conversation and questions from you, the listener, so that you can go and think more about your construction process. My name is Jonathan Cottrell. You're listening to Developer Tea, a special series on the construction of software and the mental models that we use to construct software. Kind of in our heads and then expressing it in actual code. And the motivation for this discussion and the reason I'm even doing these episodes is because we often get caught up. We start making software. Perhaps we learn something towards the beginning of our career that gives us just enough information to get started. And we begin to build software. And along the way, we're learning about ways that. Software can be built better. Sometimes we learn a lot. Sometimes we don't learn very much. But typically, people are not taking a step back and looking at how that information flows. What is the fundamental process that's happening when we design software? This isn't a question of functional versus object oriented. This isn't a debate over which. Style of collaboration, for example, is better. This also isn't a language war. Instead, this is a glimpse into subjects like belief creation. How we develop a picture of reality and how our beliefs drive our predictions and our predictions drive our decisions. How our perspective wraps around. Whatever we're doing. Whatever reality we're trying to represent. And why we so often don't see eye to eye with other people who are creating the same software that we are creating. So I want to start today. By talking about something that we do at the beginning of most episodes of the show. Asking questions. Questions are a powerful tool. We've talked about this on the show before. Questions are powerful because. They're very difficult to ignore. We can fairly easily ignore statements. But when someone asks a question. Often our brain either actively or passively searches for an answer. Or we actively reject the task of finding an answer for that question. When I ask, for example, what color is grass? If you're like pretty much everyone else around you. You. You immediately came up with an answer. It was almost impossible for you to reject that. But if I were to ask you a different question. Perhaps one that doesn't have an immediate answer. Like what president's face is on the US $50 bill? Well, you may know that right off the bat. Perhaps there's a percentage of you that do. Many of us don't deal with cash on a regular basis. A $50 denomination is also a bit less common. Than a $20 bill or a $100 bill. By contrast, you probably have a pretty good idea who's on the $100 bill. And that recognition is very likely driven by the cultural. Context around $100 bills called Benjamins. Your lack of knowledge about $50 bills. Is not just because songs aren't written about $50 bills as much as $100 bills. But also due to something called a base rate. Only 6%. And that's. $50. $50. $50. $50. $50. $50. $50. $50. Of all notes. That is bills. Printed in 2009. Were $50 bills. By the way. If you were wondering. Ulysses S. Grant is on the $50 bill. It's exceedingly unlikely. That when I asked. Whose face is on the $50 bill. That anything that I said after that. Would have come to mind. Not only is it difficult to recall. The face of the person on the $50 bill. But it's also difficult. To understand why. You can't recall it. Even with the basic reasoning that I've provided. For why you are probably unfamiliar with the $50 bill. There's still so much variance. There's so much difference. Between the way our brains work. And yet these questions are powerful. Because they kickstart. Some kind of brain process. They're difficult to ignore. Now it's probably nearly impossible. To know the exact reason. That humans evolved. To have such a sensitivity. To questions. And we certainly have a sensitivity. To language. Some theories suggest that language. Is something that we are naturally predisposed. To do. Which is not all that surprising. But it is unique to humans. And it's also very important. To understand. That we are predisposed to language. And that helps us create the beliefs. That we create. So why do questions matter so much? And more specifically. Why do questions matter so much. To software development? And how do we get it wrong. When we answer questions. We'll talk about the software development. Specific context. For why questions are important. Right after we talk about today's sponsor. Linode. Today's episode is sponsored by Linode. Linode allows you to instantly deploy. And manage. An SSD server in the Linode cloud. Not only one server. You can manage a lot of SSD servers. In the Linode cloud. Because you can manage them all together. Using something like. For example. Linode's node balancer. This is a service that allows you to. Balance traffic. That is going to multiple nodes. On Linode's network. Linode's network by the way. Is super fast. So if you have those nodes connected together. They're running on top of a 40 gigabit. Internal network. And all the storage. On those nodes. Is SSD storage. So what does it cost to get started on Linode? $5 a month. Will get you a gigabyte of RAM. And Linode's going to give you $20 worth of credit. Just for being a developer T listener. That's $20 worth of credit. To all new customers. Head over to linode.com. Slash developer T. And use the code developer T 2019. At checkout. Thanks again to Linode. For sponsoring today's episode of developer T. Before we talk further. About questions. We should immediately note. That not every question is equal. Some questions will garner our attention. More than others. And some questions have completely different answers. Than others. We have open ended questions. And much more closed questions. For example. A true or false question. Versus a question about. Your beliefs. Or maybe your perspective. So it doesn't take. Very much effort. To answer a simple question. Sometimes the question is answered. Before we even cognitively decide. To answer it. Like our previous example of. What color grass is. But even a question that has. A very similar output. In terms of. What type of answer you give. May be very difficult. To respond to. And more importantly. We may use shortcuts. To respond to those kinds of questions. Let me give you an example. What color. Did you wear most often. As a child. Assuming that you don't discard this question. In order to answer it accurately. You need information that. You probably. Don't have access to. Barring examples like. Somebody wearing a particular outfit. To school every day. Because it was their school uniform. If you don't have consistent factors. Similar to. That. Then it may be. Difficult. Or perhaps even impossible. To accurately answer. This question. And yet we still. Want to answer it. And so. What do we do. What can we do. Most often. When we're faced with a question like this. We either. Discard it. As impossible to answer. Or. We unconsciously. Substitute. A different question. What color. Did you wear most often. As a child. May get substituted for. Something that is encoded in your brain. Like what was your favorite color. As a child. Or perhaps. You have a few iconic. Photographs. Of yourself as a child. And you remember a particular shirt. In one of those photographs. Which represents only. One day. Of your life as a child. And yet. We may use that color. As our answer. You may also substitute the question. What color. Do you think. You wore most often. You may substitute the question. What color. Do you like. To imagine yourself. Wearing. Most often. As a child. But ultimately. When you answer this question. You're very likely. Substituting. A different question. And this can be. Incredibly important. When we start asking questions. About software. For example. Asking the question. What does. The user. Want to do. You very likely. Substitute. A similar question. That. Often works out. Perfectly fine. What do I believe. That the user. Wants to do. What do I predict. Based off of my. Intuition. That the user wants to do. As it relates to. Actual software design. Regardless of the feature. That you're implementing. When you ask the question. How should I. Implement this feature. You may ask. What is the.! The answer. Very likely. You are substituting the question. What methods. Am I most familiar with. And most confident with. That I can use. To solve this problem. Once again. In both scenarios. These replacement questions. These substitute questions. Actually tend to work out. Okay. We found. Some reasonable heuristics. We're solving problems. Very often. Our intuition. About what a user wants. Can be correct. Especially. When you're. Using. A software. That is. Not. A software. That is. Not. A software. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. At all. doing the things that you're doing. Answering questions with action or with some kind of definition. Answering questions based on intuition and believing that you're answering that question based on some objective reality. All of these concepts are going to come to light even more in upcoming episodes, but it's incredibly important that we grasp this simple reality that our perception of what we think we're doing, how we believe that we are acting, can often be wrong. I encourage you to ask a question again. After you listen to this episode, take time when you hear a question or when there is an implicit question that you're answering quickly, perhaps based on your intuition, try to understand the question. Understand or perhaps articulate what the substitute question is. Often just understanding what the substitute question is can lead us to better insight and help us prevent more costly errors and assumptions. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Linode for sponsoring today's episode. If you want to get started on Linode and get $20 worth of credit, head over to linode.com slash developer tea and use the code developer tea 2019 at check at checkout. That's developer tea 2019 at checkout. Thank you again to Linode for sponsoring today's episode. Today's episode and every episode of developer tea is hosted on spec.fm. Spec.fm is the home of spec network. Spec was created for designers and developers like you who want to level up in their career. Go and check it out. Spec.fm. There's other podcasts, and content waiting there for you. Today's episode was edited and produced by Sarah Jackson. Thank you again to Sarah. Thank you so much for listening. If you enjoyed today's episode, make sure you subscribe in whatever podcasting app you're using right now. Until next time, enjoy your tea.