Vox

Leitura de 19 min

How We Construct Software - Part Two (Beliefs and Models)

Summary

This episode continues the series on how developers construct software, shifting focus from mechanics to the underlying cognitive processes. Host Jonathan Cottrell explores how our beliefs form mental models of the world that guide our actions and decisions in software development.

Cottrell explains that beliefs are complex, contextual, and often intermingled with emotions and experiences. They can be aspirational, contradictory, static, or dynamic, and our articulated beliefs don’t always align with how we actually behave. Humans value consistency in beliefs because it reduces cognitive dissonance and is biologically efficient, but this efficiency comes at a cost: our beliefs are often wrong or incomplete due to the sheer complexity of accurately modeling reality.

The episode examines why mental models fail, noting that all models are abstractions that compress information and cannot account for randomness or all variables. Cottrell emphasizes that models become problematic when beliefs become inflexible, preventing us from adapting to new information or changing circumstances.

To combat belief inflexibility, Cottrell offers two practical recommendations. First, reframe central questions or decisions by shifting perspective—such as imagining yourself three months in the future looking back on a decision. Second, think in probabilistic terms rather than binary “I know” statements, allowing for uncertainty and creating space to update beliefs as new information emerges.

The episode concludes by encouraging developers to cultivate better guesses rather than solid beliefs, maintaining cognitive flexibility that enables continuous learning and improvement in software construction.

Recommendations

Podcasts

  • Framework — A new podcast on the Spec network about the process of researching, planning, and building products to bring them to market, hosted by Tom Creighton and Rob Hayes.

Tools

  • Clubhouse — A project management platform for software development that balances simplicity and structure for cross-functional collaboration. The sponsor offers Developer Tea listeners two free months on top of their standard trial.

Topic Timeline

  • 00:00:00 — Introduction to software construction and beliefs — Jonathan introduces part two of the series on how we construct software, focusing on beliefs and mental models rather than mechanics. He recaps part one’s discussion about questions and substitute questions, then explains today’s focus will be on reinvigorating appreciation for the concept of belief in software development.
  • 00:01:48 — Defining beliefs and their complexity — Cottrell provides a working definition of belief as ‘something that you think is true’ and explores how beliefs form our model of the world. He discusses how beliefs can be contradictory, aspirational, or difficult to articulate, and how our actions don’t always align with stated beliefs, creating a complex cognitive landscape.
  • 00:03:49 — Human preference for consistency in beliefs — The episode examines why humans value consistency in beliefs, suggesting it may be necessary for collaboration, confidence, or historical correctness. Cottrell explains how consistency reduces cognitive dissonance and is biologically efficient, but notes this efficiency comes with drawbacks when beliefs are wrong or incomplete.
  • 00:05:51 — The problem with efficient but wrong beliefs — Cottrell discusses the dilemma developers face: maintaining consistent beliefs is efficient but often leads to incorrect models of reality. He explains that perfect modeling would require impossible amounts of information and calculation, creating what he calls ‘impossible rationality’ where we must operate with incomplete data.
  • 00:07:52 — Why mental models fail as abstractions — After the sponsor break, Cottrell explains that mental models are abstractions that compress information, making them useful but inherently limited. He distinguishes between abstraction and simulation, noting humans cannot simulate the universe perfectly due to limited information processing capabilities and incomplete data.
  • 00:10:10 — Strategies to combat belief inflexibility — Cottrell introduces two practical strategies to maintain cognitive flexibility. First, reframe central questions or decisions by shifting perspective. Second, think in probabilistic terms rather than binary certainties. He emphasizes that these approaches help developers remain open to changing beliefs when faced with new information.
  • 00:11:04 — Reframing technique with practical examples — Cottrell provides concrete examples of reframing, such as shifting time perspective when deciding whether to use a new library feature. He explains how reframing changes the available information cues and forces slower, more deliberate thinking rather than relying on heuristics, using examples from software decisions to food delivery choices.
  • 00:13:41 — Probabilistic thinking for belief flexibility — The host recommends thinking in probabilistic terms rather than binary ‘I know’ statements. He suggests imagining high stakes to gauge true confidence levels, noting that ‘I think’ statements provide space for uncertainty and allow beliefs to evolve. This approach helps cultivate better guesses rather than rigid certainties.
  • 00:15:27 — Conclusion and series context — Cottrell concludes the episode by encouraging listeners to check out part one of the series on questions and substitute questions. He promotes subscription to Developer Tea and mentions other podcasts in the Spec network, thanking the sponsor Clubhouse and the production team before signing off.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-02-11T10:00:00Z
  • Duration: 00:17:18

References

Podcast Info

Transcript

[00:00:00] This is part two in our discussion on how we construct software. Not the mechanics of how we

[00:00:11] type, not the languages that we use, or even the particular paradigms that we use, but rather a few

[00:00:17] steps before that. How we perceive problems and how we construct solutions. How we model those

[00:00:26] things in our head and then how we take those models and express them. And in part one, we

[00:00:32] discussed why questions are so important and how difficult they are to avoid. We also discussed

[00:00:39] very briefly that we often answer questions not by listening and thinking thoroughly about that

[00:00:46] question, but instead by substituting for an easier question. I hope since that episode that

[00:00:52] you’ve had a chance to think more thoroughly about some of the substitute questions,

[00:00:56] that you have used both when you’re creating software and also in general in your life.

[00:01:03] In today’s episode, we’re going to talk a little bit about belief. Often this word is used and

[00:01:11] unfortunately abused as something more than it is. In today’s episode, I want to reinvigorate

[00:01:19] your appreciation for the word belief and hopefully encourage you to use the concept

[00:01:26] of beliefs more often when you are constructing software. You’re listening to Developer Tea.

[00:01:32] My name is Jonathan Cottrell. My goal on this show is to help driven developers like you

[00:01:36] connect to your career purpose and do better work so you can have a positive influence

[00:01:41] on the people around you. I’m going to avoid the obvious question of what is a belief. We’re going

[00:01:48] to provide a very simple definition, a working definition, but it should be validated that

[00:01:54] belief is somewhat of a divisive topic. For the sake of today’s episode, we’re going to talk about

[00:02:01] belief as something that you think is true. Now, why are our beliefs important? Well, at a fundamental

[00:02:10] level, our set of beliefs is really our model of the world. We have a perception on how things

[00:02:20] interact, for example. When we act in the world in any particular way, we are using that model

[00:02:27] or those models. It’s not a clean system, though, because often we will act in ways that contradict

[00:02:36] things that we say that we believe. And so beliefs aren’t always easily articulated by the person

[00:02:44] who holds those beliefs. Sometimes our articulated beliefs are different from the beliefs that we

[00:02:50] act in. And so we have to be able to act in ways that contradict things that we say that we believe.

[00:02:50] Sometimes our beliefs are cognitive appreciations for things that we wish that we could act on more

[00:02:58] regularly. These could be considered aspirational beliefs. Sometimes our actions are abstracted from

[00:03:06] our beliefs enough that the actions don’t necessarily seem to line up with those beliefs, even though

[00:03:12] they don’t necessarily directly contradict them. Sometimes our beliefs are constructed in such a way

[00:03:19] that the beliefs themselves seem to contradict each other. Some beliefs are static and definitive.

[00:03:28] Other beliefs are dynamic and functional. They change with time, or perhaps they change with

[00:03:35] context and circumstance. The point of this is that our model of the world is incredibly complex,

[00:03:42] and it’s difficult to know exactly what one believes and how one will react to the world

[00:03:48] because of those models. So we have to be able to act in a way that contradicts each other.

[00:03:49] But what we do know is that we value consistency as humans. Perhaps because consistency is necessary

[00:04:00] for collaboration. Perhaps because consistency often means confidence, or perhaps even at some

[00:04:07] point in human history, consistency meant correctness. But this leads us to act in all

[00:04:14] sorts of ways that are not necessarily to our benefit. In order to maintain,

[00:04:19] consistency of our beliefs. For example, you are more likely to adhere to a commitment

[00:04:26] if you make it publicly. You’re also more likely to adhere to a commitment if you’ve made it multiple

[00:04:33] times. And when we use the word commitment here, we aren’t necessarily talking about something like

[00:04:38] a new year’s resolution. Perhaps we’re talking about ascribing yourself to a certain belief,

[00:04:45] or let’s say, for example, a brand.

[00:04:49] Perhaps you feel fear over changing that code for other reasons, but perhaps you feel that you need to

[00:05:19] remain consistent.

[00:05:19] Consistent with what you said was a good idea to begin with.

[00:05:23] When we have consistent beliefs, our brains are able to see the world with less dissonance.

[00:05:31] There’s less of a hurdle to jump over to make sense of things. This means that

[00:05:37] keeping the same beliefs is biologically more efficient. We don’t have to change the way that

[00:05:45] we do things, the way that we see things, the way that we operate in the world, if

[00:05:49] our beliefs stay the same.

[00:05:51] But the problem with this efficiency model of thinking is that often, our beliefs are wrong.

[00:05:59] Even if you just simply look at the complexity of all of the beliefs that you would have to have

[00:06:05] to model the world or the universe accurately, it’s nearly impossible.

[00:06:11] The amount of calculation would require too much energy. And you are faced with this dilemma of

[00:06:18] of impossible rationality because you simply don’t have all of the information.

[00:06:25] So what can we do as developers to be open to changing our beliefs without spending all of

[00:06:32] our time trying to figure out just exactly how to model the world perfectly? We’re going to talk

[00:06:38] about that right after we talk about today’s sponsor, Clubhouse. Clubhouse is the first

[00:06:43] project management platform for software development that brings everyone together

[00:06:47] so that teams can focus on what matters, creating products their customers love.

[00:06:52] Clubhouse provides the perfect balance of simplicity and structure for better

[00:06:56] cross-functional collaboration. Its fast, intuitive interface makes it easy for people

[00:07:01] on any team to focus in on their work on a specific task or a project while also being

[00:07:07] able to zoom out to see how that work is contributing towards the bigger picture.

[00:07:11] With a simple API and a

[00:07:13] robust set of integrations, Clubhouse also seamlessly integrates with the tools you use

[00:07:18] every day, getting out of your way so that you can deliver quality software on time.

[00:07:23] Listeners of Developer Tea can sign up for two free months of Clubhouse, two free months,

[00:07:31] by going to clubhouse.io slash developer tea. Go and check it out, clubhouse.io slash developer tea.

[00:07:38] By the way, this is on top of the 14-day free trial that

[00:07:43] Clubhouse offers, so you’re actually getting more like two and a half months. Go and check it out,

[00:07:47] clubhouse.io slash developer tea. Thank you again to Clubhouse for sponsoring today’s episode.

[00:07:52] So we can recognize pretty quickly that our beliefs are fairly complicated. They’re contextual.

[00:08:00] Often they are intermingled with our emotions. They’re intermingled with our experiences.

[00:08:06] They’re heavily biased in ways that we won’t ever be able to unravel completely.

[00:08:12] When we bring our beliefs to the table, we’re able to unravel them completely.

[00:08:13] When we bring our model of the world into our work, we should expect that sometimes

[00:08:21] that model is going to yield bad results. Sometimes our model of the world just simply

[00:08:28] doesn’t have enough information available. Another example of this is that even if you

[00:08:33] had a perfect model of the world, you still wouldn’t be able to account for randomness.

[00:08:39] There’s going to be failure with your model.

[00:08:42] Why is that?

[00:08:43] Why do our models fail? Why can’t we ever learn everything that we need to?

[00:08:48] At a fundamental level, a model is an abstraction. It’s an abstraction that compresses out a lot of

[00:08:55] information that we otherwise would need to be able to predict everything that would happen.

[00:09:01] Model is useful for predicting the world, but it also is often wrong in some way or another.

[00:09:09] We often believe that our models are accurate,

[00:09:13] and that they are not an abstraction, but instead a simulation.

[00:09:18] In a perfect simulation, all of the same variables that control whatever the original simulated thing

[00:09:25] is are available to the simulation. The human mind does not have the capability of simulating

[00:09:33] the universe, much less the many universes that we would need to simulate to be able to run,

[00:09:39] for example, odd scenarios. We also, quite literally,

[00:09:44] don’t have all of the information available, even simply because humans have only been

[00:09:49] recording information for a fraction of the age of the universe. So hopefully at this point,

[00:09:55] you can understand that our models are extremely limited, but still useful. But the models become

[00:10:02] less useful when our beliefs become inflexible. So how can we fight against this inflexibility

[00:10:10] of belief? I’m going to give you two recommendations. One is to use a model that is not an abstraction.

[00:10:12] The other is to use a model that is not an abstraction. The other is to use a model that is not an abstraction.

[00:10:13] And there are certainly more. I encourage you to do more thinking and studying on this topic.

[00:10:19] But two recommendations that are studied, and they actually work for helping you kind of remain

[00:10:26] more plastic in your belief systems. My first recommendation is when you’re facing

[00:10:32] some kind of decision, or when you’re facing some kind of important prediction that you need to make,

[00:10:39] and you’re trying to lay out how you expect things to happen,

[00:10:43] or perhaps you’re trying to make a decision for yourself, or for your team, or for your family,

[00:10:50] I encourage you to reframe whatever the center topic is. Sometimes that center topic is a

[00:10:57] question. Sometimes that center topic is a decision. Often reframing works best when you

[00:11:04] have a should question. For example, should I use this new feature in a library? We’ve talked about

[00:11:12] reframing recently. We’ve talked about reframing in a library. We’ve talked about reframing in a

[00:11:13] developer team. One of the ways that you can reframe a question like should I use this feature

[00:11:18] is to shift time. So for example, move forward. Imagine three months, and you’ve decided to use

[00:11:26] that feature. Now ask yourself the question, did I make the right choice to use this feature?

[00:11:34] And do the same and run the scenario without using the feature. Oftentimes, this will shift

[00:11:41] the way that you think about the argument.

[00:11:43] Re-framing is very important because our brain takes cues from whatever information

[00:11:49] is available. And so, for example, if you’re trying to predict whether you should use a

[00:11:56] particular feature, you’re going to use arguments that other people are providing

[00:12:01] for why you should or shouldn’t use that feature. If you are trying to predict how that feature has

[00:12:09] affected you, that’s a different question. And as we said in the presentation, if you’re trying to

[00:12:13] predict how that feature has affected you, that’s a different question. And so, if you’re trying to

[00:12:19] frame the topics that we are talking about, can drastically change the answers that we provide to

[00:12:27] two nearly identical questions. By the way, framing is a very important tool in communication.

[00:12:35] For example, imagine that you’re trying to convince someone to have food delivered to their house

[00:12:42] rather than going out to eat. And you’re trying to convince someone to have food delivered to their

[00:12:43] house rather than going out to eat. And you’re trying to convince someone to have food delivered to their

[00:12:49] house rather than going out to eat. And often the food itself is marked up on services that deliver

[00:12:55] the food. So how can you convince that person to pay more for the same effect? Instead of telling

[00:13:02] the person that they’re paying for delivery, you can reframe what they are paying for. For example,

[00:13:09] they may be buying their own time. Re-framing also causes us to

[00:13:13] break out of whatever our initial perspective is, and it forces us to re-evaluate. And when we

[00:13:20] re-evaluate, we do it much less based on heuristics, much more based on that slower thinking, that more

[00:13:28] deliberate thinking process. Okay, so that’s the first recommendation. Take a moment to reframe

[00:13:34] whatever the central topic is in your decision. My next recommendation is to think explicitly

[00:13:41] in probabilistic terms. So, if you’re trying to think explicitly in probabilistic terms,

[00:13:43] you’ve probably heard this, probabilistic thinking, but I encourage you to take a moment

[00:13:49] whenever you are kind of stating a belief, right? If you say that you know that X is true,

[00:13:57] or you believe that this is the best decision, then take a moment to imagine that the stakes

[00:14:06] are high, that you’ve placed a large bet on this decision. One of the signs that you’re doing this

[00:14:12] correctly is that you’re not making the right decision. You’re not making the right decision.

[00:14:13] When many of your I know statements turn into I think statements. Belief and knowing can often

[00:14:21] come across as binary statements, having 100% confidence or 0% confidence. I do know,

[00:14:29] or I don’t know. If you think something, you’re providing yourself the flexibility

[00:14:34] for a magnitude. Thinking provides space for uncertainty. It provides you the opportunity

[00:14:43] to change what you think. Perhaps you even have 20% confidence that whatever you think is right,

[00:14:50] but you don’t have any other theories. This way of thinking and approaching difficult decisions

[00:14:58] helps to disarm the sense that your beliefs need to be solid. Instead, you can constantly cultivate

[00:15:08] better guesses. You can try to figure out how to get the right answer. You can try to figure out

[00:15:13] how to get the right answer. You can try to figure out how to get the right answer. You can try to

[00:15:13] gain more confidence in the beliefs or discard them so you can choose a better one so that you

[00:15:20] are giving yourself the signals of a higher degree of confidence in the beliefs that you hold.

[00:15:27] Thank you so much for listening to today’s episode. Thank you again to Clubhouse for

[00:15:31] sponsoring the episode. Head over to clubhouse.io slash developer T to get started

[00:15:36] with two free months on Clubhouse. Thanks again to Clubhouse. Today’s episode was part

[00:15:43] two in our episode series on constructing software, how we construct software. I encourage

[00:15:49] you to go and listen to part one where we talk about questions and substitute questions. Thank

[00:15:55] you so much for listening. If you are enjoying these episodes, and if you want to hear more in

[00:15:59] this particular series, I encourage you to subscribe in whatever podcasting app you use.

[00:16:04] We’re in the 600 something number of episodes and we continue to pump out three episodes a week.

[00:16:10] So if you don’t subscribe, you end up with a new episode. If you don’t subscribe, you end up with a new episode.

[00:16:13] So if you don’t subscribe, you end up losing out on a lot of excellent content that I truly believe

[00:16:16] can help your career and help you as a developer. By the way, developer T is a part of the spec

[00:16:23] network. I helped start the spec network back in 2015 as a resource for designers and developers

[00:16:31] who are looking to level up in their careers. Go and check out all of the other amazing podcasts

[00:16:37] that are on the spec network. Head over to spec.fm. As an example, we have a brand new

[00:16:42] podcast called the Speck Network. It’s a podcast that’s going to help you level up in your career.

[00:16:43] It’s a podcast that just recently joined the Speck Network. It’s called Framework. Framework is a

[00:16:47] podcast about the process of researching, planning, and building that goes into bringing a product to

[00:16:52] market. It’s hosted by Tom Creighton and Rob Hayes. Robert Hayes. Go and check it out at

[00:16:58] speck.fm slash podcasts slash framework. Of course, you can find it on the homepage of Speck by just

[00:17:04] going to speck.fm. A huge thanks to today’s editor and producer, Sarah Jackson. Thanks so much for

[00:17:09] listening and until next time, enjoy your tea.

[00:17:13] Bye.

Visão de gráfico