How We Construct Software - Part 1 (Substitute Questions)
Summary
In this episode, host Jonathan Cottrell kicks off a series exploring the mental processes behind software construction, moving beyond syntax and tools to examine how developers think. He frames the discussion around the fundamental role of questions in shaping our beliefs, predictions, and decisions.
Cottrell explains that questions are powerful cognitive tools because they are difficult for the brain to ignore, often triggering an automatic search for an answer. He illustrates this with examples like “What color is grass?” versus the more obscure “Whose face is on the U.S. $50 bill?” (Ulysses S. Grant), highlighting how our ability to answer depends on familiarity and base rates in our environment.
The core argument is that when faced with complex or unanswerable questions, we frequently and unconsciously substitute them with simpler, related questions we can answer based on intuition or available information. For instance, “What color did you wear most often as a child?” might be substituted with “What was your favorite color as a child?” In software development, “What does the user want to do?” is often replaced with “What do I believe the user wants to do?” or “How should I implement this feature?” becomes “What methods am I most familiar with?”
While these substitute questions and heuristic shortcuts often work, Cottrell warns that they create an illusion of answering the original question objectively. The episode concludes by encouraging listeners to become more aware of this substitution process in their own work. By articulating the substitute question being answered, developers can gain better insight and avoid costly assumptions, setting the stage for deeper exploration of mental models in future episodes.
Recommendations
Services
- Linode — A cloud hosting provider offering SSD servers on a fast network. The host mentions a promotion for listeners offering $20 of credit.
Websites
- spec.fm — The Spec network, home of the Developer Tea podcast and other content for designers and developers looking to level up their careers.
Topic Timeline
- 00:00:00 — Introduction to the series on mental software construction — Jonathan Cottrell introduces a new series focused not on coding syntax, but on how we mentally construct software. He explains the goal is to spark listener reflection on their own construction processes and the mental models involved in turning ideas into code.
- 00:02:42 — The cognitive power and difficulty of ignoring questions — Cottrell discusses why questions are a powerful tool, as our brains find them difficult to ignore. He contrasts easily answered questions (e.g., “What color is grass?”) with harder ones (e.g., “Who is on the $50 bill?”) to show how our responses are tied to familiarity and base rates in our experience.
- 00:07:19 — Not all questions are equal; we substitute difficult questions — The host notes that questions vary in difficulty and that we often lack the information to answer complex ones accurately. Instead of discarding them, we unconsciously substitute a different, easier question. He gives the example of substituting “What color did you wear most often as a child?” with “What was your favorite color?”
- 00:10:13 — Applying question substitution to software development — Cottrell applies the concept of substitute questions directly to software design. He argues that questions like “What does the user want to do?” or “How should I implement this feature?” are often replaced with intuitive, heuristic-based questions like “What do I believe the user wants?” or “What methods am I most familiar with?” While these substitutions often work, they create an illusion of objective problem-solving.
- 00:11:36 — Encouragement to identify substitute questions in practice — Cottrell concludes by encouraging listeners to actively identify when they are answering a substitute question, especially when relying on intuition. He suggests that simply articulating the substitute question can provide better insight and help prevent errors in assumptions during software development.
Episode Info
- Podcast: Developer Tea
- Author: Jonathan Cutrell
- Category: Technology Business Careers Society & Culture
- Published: 2019-02-08T10:00:00Z
- Duration: 00:14:14
References
- URL PocketCasts: https://pocketcasts.com/podcast/developer-tea/cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263/how-we-construct-software-part-1-substitute-questions/c8154c49-094f-4607-b750-581ef46a0065
- Episode UUID: c8154c49-094f-4607-b750-581ef46a0065
Podcast Info
- Name: Developer Tea
- Type: episodic
- Site: http://www.developertea.com
- UUID: cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263
Transcript
[00:00:00] In the next couple of episodes, I’m going to spend some time talking about how we construct
[00:00:09] software.
[00:00:11] Not how we construct it in our editors, not the syntax that we use, but instead how we
[00:00:20] mentally construct software.
[00:00:23] This isn’t going to be a comprehensive set of episodes, but rather these episodes will
[00:00:30] intentionally spark conversation and questions from you, the listener, so that you can go
[00:00:38] and think more about your construction process.
[00:00:42] My name is Jonathan Cottrell.
[00:00:43] You’re listening to Developer Tea, a special series on the construction of software and
[00:00:49] the mental models that we use to construct software.
[00:00:53] Kind of in our heads and then expressing it in actual code.
[00:00:58] And the motivation for this discussion and the reason I’m even doing these episodes is
[00:01:03] because we often get caught up.
[00:01:07] We start making software.
[00:01:09] Perhaps we learn something towards the beginning of our career that gives us just enough
[00:01:15] information to get started.
[00:01:17] And we begin to build software and along the way, we’re learning about ways that
[00:01:23] software can be built better.
[00:01:25] Sometimes we learn a lot.
[00:01:27] Sometimes we don’t learn very much, but typically people are not taking a step back and
[00:01:34] looking at how that information flows.
[00:01:39] What is the fundamental process that’s happening when we design software?
[00:01:44] This isn’t a question of functional versus object oriented.
[00:01:50] This isn’t a debate over which.
[00:01:52] Style of collaboration, for example, is better.
[00:01:57] This also isn’t a language war.
[00:01:59] 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.
[00:02:22] 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.
[00:02:34] So I want to start today by talking about something that we do at the beginning of most episodes of the show.
[00:02:42] Asking questions.
[00:02:45] Questions are a powerful tool.
[00:02:47] We’ve talked about this on the show before.
[00:02:50] Questions are powerful because.
[00:02:52] They’re very difficult to ignore.
[00:02:55] We can fairly easily ignore statements.
[00:02:58] 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.
[00:03:13] When I ask, for example, what color is grass?
[00:03:18] If you’re like pretty much everyone else around you.
[00:03:21] You immediately came up with an answer.
[00:03:24] It was almost impossible for you to reject that.
[00:03:27] 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 U.S. $50 bill?
[00:03:37] Well, you may know that right off the bat.
[00:03:41] Perhaps there’s a percentage of you that do.
[00:03:43] Many of us don’t deal with cash on a regular basis.
[00:03:46] A $50 denomination is also a bit less common.
[00:03:51] And a 100 bill.
[00:03:53] By contrast.
[00:03:55] You probably have a pretty good idea who’s on the $100 bill.
[00:03:59] And that recognition is very likely driven by the cultural context around $100 bills called Benjamins.
[00:04:07] Your lack of knowledge about $50 bills is not just because songs aren’t written about
[00:04:13] 100 bills, but also due to something called a base rate.
[00:04:20] Only 6% of all songs.
[00:04:21] Only 6% of all songs.
[00:04:21] notes, that is bills, printed in 2009 were $50 bills. By the way, if you were wondering,
[00:04:29] Ulysses S. Grant is on the $50 bill. It’s exceedingly unlikely that when I asked whose
[00:04:36] face is on the $50 bill, that anything that I said after that would have come to mind.
[00:04:42] Not only is it difficult to recall the face of the person on the $50 bill, but it’s also difficult
[00:04:48] to understand why you can’t recall it. Even with the basic reasoning that I’ve provided
[00:04:55] for why you are probably unfamiliar with the $50 bill, there’s still so much variance.
[00:05:03] There’s so much difference between the way our brains work. And yet these questions are powerful
[00:05:10] because they kickstart some kind of brain process. They’re difficult to ignore.
[00:05:18] Now,
[00:05:18] it’s probably nearly impossible to know the exact reason that humans evolved to have such
[00:05:24] a sensitivity to questions. And we certainly have a sensitivity to language. Some theories
[00:05:31] suggest that language is something that we are naturally predisposed to do, which is not all
[00:05:37] that surprising, but it is unique to humans. And it’s also very important to understand
[00:05:44] that we are predisposed to language and that helps us,
[00:05:48] create the beliefs that we create. So why do questions matter so much? And more specifically,
[00:05:56] why do questions matter so much to software development? And how do we get it wrong
[00:06:03] when we answer questions? We’ll talk about the software development specific context
[00:06:09] for why questions are important right after we talk about today’s sponsor,
[00:06:13] Linode. Today’s episode is sponsored by Linode. Linode allows you to
[00:06:18] instantly deploy and manage an SSD server in the Linode Cloud. Not only one server, you
[00:06:24] can manage a lot of SSD servers in the Linode Cloud, because you can manage them all together
[00:06:30] using something like, for example, Linode’s Node Balancer. This is a service that allows
[00:06:35] you to balance traffic that is going to multiple nodes on Linode’s network. Linod’s network,
[00:06:42] by the way is super fast, so if you have those nodes connected together, they’re running
[00:06:47] on top of a 40 gigabit internal network. So you don’t have to worry about running all
[00:06:48] bit internal network. And all the storage on those nodes is SSD storage. So what does it cost to get
[00:06:55] started on Linode? $5 a month will get you a gigabyte of RAM. And Linode is going to give you
[00:07:02] 20 worth of credit to all new
[00:07:07] customers. Head over to linode.com slash developer T and use the code developer T 2019 at checkout.
[00:07:15] Thanks again to Linode for sponsoring today’s episode of developer T.
[00:07:19] Before we talk further about questions, we should immediately note that not every question
[00:07:25] is equal. Some questions will garner our attention more than others. And some questions have
[00:07:31] completely different answers than others. We have open ended questions and much more closed
[00:07:38] questions. For example, a true or false question versus a question about
[00:07:44] what’s going on in the world. And we have open ended questions and much more closed questions.
[00:07:45] We have open ended questions and much more closed questions. For example, a true or false question
[00:07:45] your beliefs, or maybe your perspective. So it doesn’t take very much effort to answer a simple
[00:07:53] question. Sometimes the question is answered before we even cognitively decide to answer it,
[00:07:59] like our previous example of what color grass is. But even a question that has a very similar
[00:08:06] output, in terms of what type of answer you give, may be very difficult to
[00:08:14] respond to. And more importantly, we may use shortcuts to respond to those kinds of questions.
[00:08:22] Let me give you an example. What color did you wear most often as a child? Now, assuming that
[00:08:29] you don’t discard this question, in order to answer it accurately, you need information that
[00:08:36] you probably don’t have access to. Barring examples like somebody wearing a particular outfit to school
[00:08:44] every day, or wearing a particular outfit to school every day, or wearing a particular outfit to school
[00:08:44] every day, because it was their school uniform, if you don’t have consistent factors similar to
[00:08:50] that, then it may be difficult or perhaps even impossible to accurately answer this question.
[00:08:57] And yet we still want to answer it. And so what do we do? What can we do? Most often when we’re
[00:09:06] faced with a question like this, we either discard it as impossible to answer, or we unconsciously
[00:09:13] substitute a different question. What color did you wear most often as a child may get substituted
[00:09:22] for something that is encoded in your brain, like what was your favorite color as a child? Or perhaps
[00:09:29] you have a few iconic photographs of yourself as a child, and you remember a particular shirt
[00:09:35] in one of those photographs, which represents only one day of your life as a child. And yet we may
[00:09:43] use shortcuts to respond to those questions. And so what do we do? Most often when we’re faced with a question
[00:09:43] that color as our answer, you may also substitute the question, what color do you think you wore most
[00:09:52] often? You may substitute the question, what color do you like to imagine yourself wearing
[00:09:59] most often as a child? But ultimately, when you answer this question, you’re very likely
[00:10:05] substituting a different question. And this can be incredibly important when we start
[00:10:13] asking questions about software. For example, asking the question, what does the user want to
[00:10:20] do? You very likely substitute a similar question that often works out perfectly fine. What do I
[00:10:30] believe that the user wants to do? What do I predict based off of my intuition that the user
[00:10:38] wants to do? As it relates to actual software design, regardless of the fact that the user is
[00:10:43] going to use software, you can ask the question, how should I implement this feature? When you
[00:10:46] ask the question, how should I implement this feature? Very likely you are substituting the
[00:10:52] question, what methods am I most familiar with and most confident with that I can use to solve
[00:11:00] this problem? Once again, in both scenarios, these replacement questions, these substitute questions
[00:11:06] actually tend to work out okay. We’ve found some reasonable heuristics.
[00:11:13] We’re solving problems. Very often our intuition about what a user wants can be correct, especially
[00:11:20] if we are quite familiar with the persona of that particular user. And yet we are still under the
[00:11:26] illusion that we are answering those questions directly. So as you begin to engage this topic of
[00:11:36] how we construct software, start at this core fundamental place.
[00:11:43] You start developing software, understanding why you’re doing the things that you’re doing,
[00:11:50] answering questions with action or with some kind of definition, answering questions based on
[00:11:59] intuition, and believing that you’re answering that question based on some objective reality.
[00:12:07] All of these concepts are going to come to light even more in upcoming episodes,
[00:12:13] but it’s incredibly important that we grasp this simple reality, that our perception
[00:12:21] of what we think we’re doing, how we believe that we are acting can often be wrong.
[00:12:31] I encourage you to ask a question again. After you listen to this episode,
[00:12:38] take time when you hear a question or when there is an implicit question,
[00:12:43] you’re answering quickly, perhaps based on your intuition. Try to understand or perhaps
[00:12:50] articulate what the substitute question is. Often just understanding what the substitute question is
[00:12:59] can lead us to better insight and help us prevent more costly errors and assumptions.
[00:13:07] Thank you so much for listening to today’s episode of Developer Tea. Thank you again to Linode
[00:13:11] for sponsoring today’s episode. Thank you to Linode for sponsoring today’s episode of Developer Tea.
[00:13:13] If you want to get started on Linode and get $20 worth of credit up front,
[00:13:19] head over to linode.com slash developer tea and use the code developer tea 2019 at check at checkout.
[00:13:25] That’s developer tea 2019 at checkout. Thank you again to Linode for sponsoring today’s episode.
[00:13:31] Today’s episode and every episode of Developer Tea is hosted on spec.fm. Spec.fm is the home of spec
[00:13:38] network. Spec was created for designers and developers like you.
[00:13:43] Who want to level up in their career. Go and check it out spec.fm. There’s other podcasts
[00:13:48] and content waiting there for you. Today’s episode was edited and produced by Sarah Jackson. Thank
[00:13:56] you again to Sarah. Thank you so much for listening. If you enjoyed today’s episode,
[00:14:00] make sure you subscribe in whatever podcasting app you’re using right now. Until next time,
[00:14:05] enjoy your tea.
[00:14:13] Thank you.