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 Cutrell, 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 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 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 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 bingements. 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% 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. It's probably nearly impossible to know the exact reason that humans evolved to have such a sensitivity to questions. 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 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 of the storage on those nodes is SSD storage. So what is it cost to get started on Linode? Five dollars 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. We've had over to Linode.com, size Developer Tea, and used the code Developer Tea2019 at checkout. Thanks again to Linode for sponsoring today's episode of Developer Tea. 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? Knowing 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? 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 if we are quite familiar with the persona of that particular user. And yet we are still under the illusion that we are answering those questions directly. So as you begin to engage this topic of how we construct software, start at this core fundamental place when you start developing software. Understanding why you're 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. Should 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 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 up front, head over to linode.com slash Developer Tea and use the code Developer Tea2019 at checkout. That's Developer Tea 2019 at checkout. Thank you again to Linode for sponsoring today's episode. Please 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.