Vox

Leitura de 20 min

3 Cognitive Pitfalls of Mental Models

Summary

This episode of Developer Tea delves into the essential but potentially misleading nature of mental models. Host Jonathan Cottrell explains that mental models are simplified representations we use to understand complex systems, often by applying concepts from one domain to another, like using object-oriented thinking in software engineering. While fundamental to human cognition, their intentional application in professional and personal problem-solving comes with specific risks.

The first major pitfall is overfitting, where a model becomes too specific to a single instance or dataset. An overfit model, like one defining a dog by an exact height, fails when encountering new variations. In software, this might mean incorrectly assuming all performance issues involve lost revenue. Overfitting breeds overconfidence, making us cling to a model even when its details don’t generalize to new problems, especially when using metaphorical models that don’t align with reality.

The second pitfall is resistance to updating models as environments change. A model that was once effective can become obsolete when external conditions shift, as seen with public health guidance during a pandemic. Our brains, rewarded by a model’s past success, make it difficult to retire it, leading us to apply outdated thinking to new situations in both professional and personal contexts.

The final challenge is the difficulty of composing multiple, potentially conflicting models. Since all models are inherently incomplete, different models might explain different aspects of a problem but contradict each other. For example, a product might have multiple customer archetypes that conflict. The temptation is to force a compromise model, but this average might represent no real customer at all. The key is to accept that conflicting models can coexist and be useful for different parts of a complex problem.

Cottrell concludes by emphasizing that mental models remain a fundamental tool, but we must stay vigilant, willing to experiment, and ready to accept new models, judging them solely by their current utility.

Recommendations

Communities

  • Developer Tea Discord — The show’s free Discord community where listeners can connect and discuss topics related to the podcast and developer careers.

Tools

  • LaunchDarkly — A feature management platform that allows development and operations teams to deploy code using feature flags, enabling safe testing in production and controlled releases to specific audiences like QA or beta testers.

Topic Timeline

  • 00:00:00 — Introduction to mental models and their potential pitfalls — Jonathan Cottrell introduces the episode’s focus on mental models, a favorite topic on Developer Tea. He notes that while incredibly useful, especially for software engineers, mental models can sometimes lead us astray. The episode will outline three specific cognitive pitfalls associated with their use.
  • 00:01:05 — Defining what a mental model is — Cottrell defines a mental model as applying a system from one domain to understand another. He uses the example of object-oriented programming in software, where code is modeled after physical objects or data streams, even though the underlying reality is bits on a drive. He emphasizes that we use and compose these models constantly, often unconsciously, as a fundamental brain function to catalog and predict experiences.
  • 00:05:01 — First pitfall: Overfitting your mental model — The first pitfall is overfitting, a concept from machine learning. An overfit model is too closely tailored to specific past data, making it fail on new instances. For example, a model of performance issues that includes ‘lost revenue’ as a necessary condition might incorrectly exclude issues where revenue isn’t affected. Overfitting leads to overconfidence and can cause us to overextend metaphorical models, like assuming software objects decay like physical ones, leading to irrelevant decisions.
  • 00:11:27 — Second pitfall: Resistance to changing obsolete models — The second pitfall is resisting necessary updates to models as the environment changes. A model that was once good can become obsolete, as seen with pandemic behavior guidelines. Our brains, having been rewarded by the model’s past success, make it difficult to retire it. We must recognize that changes in uncontrolled external factors require us to update our models rather than applying yesterday’s solution to today’s new reality.
  • 00:14:45 — Third pitfall: Difficulty composing conflicting models — The third pitfall is the challenge of composing multiple models that conflict. Since all models are incomplete, different models (e.g., Customer Archetype A and B) might explain different parts of a problem but directly contradict each other. The mistake is trying to create a compromised, averaged model that may represent no real scenario. Instead, we should accept that conflicting models can be simultaneously applicable to different aspects of a complex problem.
  • 00:18:16 — Conclusion and call for vigilant model application — Cottrell concludes that mental models are an unavoidable and valuable fundamental tool. He encourages continued learning and cross-domain application of models. However, we must stay vigilant against these pitfalls, remain willing to experiment with new models, and judge a model solely by its current helpfulness, not its past success.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2021-12-23T08:00:00Z
  • Duration: 00:20:05

References

Podcast Info

Transcript

[00:00:00] We love to talk about mental models on this podcast.

[00:00:10] And other podcasts also have picked up on this idea.

[00:00:13] It’s not a new idea, but it certainly is useful.

[00:00:17] And it’s particularly useful for software engineers.

[00:00:20] But there’s a catch.

[00:00:23] Sometimes mental models, like almost any other tool, can go wrong.

[00:00:29] They can trick you.

[00:00:32] And this isn’t some insidious trick.

[00:00:34] This is all well-studied and well-established science of the brain.

[00:00:40] And we don’t understand the brain completely, but we do know some of the behaviors that

[00:00:45] we have as human beings.

[00:00:47] And in today’s episode, I want to share three ways that using mental models could go wrong.

[00:00:54] My name is Jonathan Cottrell.

[00:00:55] You’re listening to Developer Tea.

[00:00:57] My goal on the show is to help driven developers like you find clarity, perspective, and purpose

[00:01:03] in their careers.

[00:01:05] Mental models.

[00:01:06] What is a mental model?

[00:01:08] The basic idea of a mental model is to take the system that you apply to one domain and

[00:01:20] apply the same kind of system to another domain.

[00:01:26] We use a mental model to understand, it’s kind of a cross-referenced understanding from

[00:01:36] one domain to another.

[00:01:40] For example, in software engineering, we use object-oriented thinking.

[00:01:47] We imagine that our code is representative of, for example, one paradigm might represent

[00:01:53] a physical object.

[00:01:56] Another paradigm might represent a stream of information.

[00:02:01] The truth is, our code is actually none of these things.

[00:02:07] Our code is represented as bits on a drive of some kind, and it’s executed by other code.

[00:02:18] The way that we construct it, we have meta-information that we use so that we can construct our code

[00:02:26] in ways that other humans can read and use that code.

[00:02:31] We can construct it in a way that we can change it and extend it.

[00:02:36] All of this is done by using mental models.

[00:02:41] The vast majority of the time that we use these, we don’t even realize we’re doing it.

[00:02:47] We don’t realize that we’re using mental models in our daily lives all the time.

[00:02:55] We’re very efficient at this as human beings.

[00:03:00] Not only are we using these models, we are composing them.

[00:03:03] We’re grabbing from our past experiences, for example, to model our future experiences.

[00:03:11] A model is a kind of representation of what you might expect given certain circumstances.

[00:03:22] It’s important to understand that mental models are always, always invariably incomplete,

[00:03:30] and this is important as we talk about how these things can steer us wrong.

[00:03:34] I want to give you three ways that mental models can steer you wrong, but now that we

[00:03:40] have a picture of what this tool is, you can start to recognize that this really is

[00:03:47] beyond just a tool.

[00:03:50] This is kind of a fundamental function of our brains.

[00:03:52] We use models to try to understand things.

[00:03:56] Our brain is building a model of various types of objects from the time that we’re born.

[00:04:05] If we can see an object or if we can hear something, our brain is cataloging that information,

[00:04:11] creating models that we say, okay, this sounds like, or this looks like, this feels like

[00:04:17] X, Y, or Z.

[00:04:20] You can see how this is not only useful to understand, but it’s also useful to do this

[00:04:28] intentionally.

[00:04:29] Rather than just going through our lives every day, kind of unintentionally composing and

[00:04:34] pulling from these models that we have kind of naturally stored in our brains, we can

[00:04:38] intentionally pull models to understand complex scenarios.

[00:04:44] But when we do this intentionally, and sometimes even when we’re doing it unintentionally,

[00:04:49] but especially when we’re doing this as an explicit practice where we’re applying a model

[00:04:55] that we know about, some parts of that can go wrong, and that’s what we’re talking about

[00:05:00] today.

[00:05:01] The first thing that can go wrong with your models is an overfit, an overfit.

[00:05:10] You probably are familiar with this term.

[00:05:13] If you’ve ever done any kind of forecasting work, any kind of machine learning, modeling,

[00:05:20] and that kind of thing, overfitting means that your model in some instance too closely

[00:05:27] represents the thing that you’re trying to model.

[00:05:32] How can this be possible?

[00:05:33] It seems like it would be a great thing to have a model that perfectly fits the thing

[00:05:38] that we’re trying to model.

[00:05:39] But the truth is that each instance of that thing, let’s say that we’re going to make

[00:05:45] it a very simple example that has no actual application in real life, but let’s say you’re

[00:05:49] modeling a dog.

[00:05:52] An overfit on a model for a dog might include the height or the color of the dog.

[00:06:00] Instead of including a range, it might be explicit about those heights, for example.

[00:06:06] This causes obvious problems if you encounter a dog that is one inch taller than that other

[00:06:11] dog that you paste your model on, then your overfit model is going to classify that second

[00:06:19] dog as not a dog.

[00:06:22] Now this matters not just in machine learning, of course it applies there, but it matters

[00:06:27] in our daily modeling, in our problem solving modeling.

[00:06:31] When we see a problem and we’ve created a model in our minds that, for example, let’s

[00:06:37] say we’re trying to solve a performance issue and we take an experience that we had with

[00:06:44] issue and we try to extrapolate every single detail about that performance issue into all

[00:06:52] performance issues.

[00:06:53] Now our model of performance issues, performance problems is going to be overfit.

[00:07:00] Now here’s what’s interesting.

[00:07:02] That model might be so fit to a specific problem that you gain an extraordinary amount of confidence.

[00:07:11] In fact, it becomes overconfidence, which makes you more attached to the model.

[00:07:18] We’re likely to imagine that the model itself, if it’s overfit, that all of the parts of

[00:07:26] that model are going to extend to all parts of the problem that we’re trying to solve

[00:07:30] as well.

[00:07:31] So, for example, let’s say one of your criteria in your model for a performance issue is that

[00:07:37] you’re losing revenue.

[00:07:38] Well, it’s very possible that you have a performance issue where you don’t lose revenue, but you’ve

[00:07:44] created this overextension based on the overfitting model that all performance issues come with

[00:07:51] lost revenue and that’s not necessarily true.

[00:07:54] There’s another kind of subtle point here about overfitting models, specifically with

[00:08:00] relation to kind of metaphorical models, where you apply a metaphor of some system

[00:08:07] as a model to kind of drive your principles in a different system entirely.

[00:08:13] Going back to our previous idea of object-oriented programming and the object model, we might

[00:08:19] imagine, for example, that objects grow old over time and that they begin to decay.

[00:08:26] Well, this may not necessarily line up with our software objects because they don’t have

[00:08:30] the same boundaries or physical constraints that physical objects have.

[00:08:36] And so, if we overextend our kind of metaphorical model, then we might make decisions that are

[00:08:42] irrelevant to the reality of the problem that we’re trying to solve.

[00:08:48] We’re going to take a quick sponsor break and then I’m going to come back and talk to

[00:08:51] you about the two other downsides or potential pitfalls of mental models.

[00:09:14] This episode is brought to you by LaunchDarkly.

[00:09:18] LaunchDarkly is helping you create feature management for the modern enterprise, fundamentally

[00:09:24] changing how you deliver software.

[00:09:27] Here’s how it works.

[00:09:29] LaunchDarkly enables development and operations teams to deploy code at any time, even if

[00:09:34] a feature isn’t ready to be released to users.

[00:09:37] Wrapping code with feature flags gives you the safety to test new features and infrastructure

[00:09:43] in your production environments without impacting the wrong end users.

[00:09:47] When you’re ready to release more widely, you can update the flag and the changes are

[00:09:52] made instantaneously thanks to their real-time streaming architecture.

[00:09:56] Here’s the reality about feature flags.

[00:09:59] There’s been so many projects that I’ve worked on where it was either cost prohibitive or

[00:10:03] nearly impossible to actually replicate what was happening on production, whether it’s

[00:10:07] because you can’t really replicate the stresses that are put on the production environment

[00:10:12] or you can’t replicate the data because it’s sensitive data.

[00:10:16] There’s a lot of tricks that you might be able to pull to make your staging look like

[00:10:21] production, but at the end of the day, there’s going to be something different happening

[00:10:23] in production than is happening in your staging environments.

[00:10:27] You can’t replicate those one-to-one, almost never.

[00:10:30] So especially for features that you are developing that you’re trying to release either to a

[00:10:35] partial audience or maybe you’re just trying to QA those in a production environment without

[00:10:41] actually releasing to the production environment, you don’t have to do crazy, weird hours releases

[00:10:45] where somebody might see the release if they log on at a particular time, but your QA team

[00:10:52] is having to stay up all hours of the night to finish this testing.

[00:10:55] That stuff is over.

[00:10:57] With LaunchDarkly, you can release to just your QA folks, or you can release to a beta

[00:11:03] testing audience, or you can release to the wider public with a single flag change.

[00:11:08] Go and check it out.

[00:11:09] Head over to LaunchDarkly.com to get started for free today.

[00:11:12] That’s LaunchDarkly.com.

[00:11:15] Thanks again to LaunchDarkly for their support of Developer Team.

[00:11:27] We’re talking about the potential downsides or pitfalls of using mental models, ways that

[00:11:33] they can bite you, or ways more specifically that we misuse or kind of misunderstand how

[00:11:43] models are supposed to be used.

[00:11:45] We talked about the first one, having an overfit in your model.

[00:11:48] The second one is resistance to changing, and this one, by the way, is kind of related

[00:11:53] to the first one, resistance to changing or updating models as time makes them obsolete.

[00:12:01] We had an overfit in the beginning that made us resistant to changing it, which is kind

[00:12:06] of a common theme here that we need to be open to changing and adjusting what models

[00:12:12] we’re using.

[00:12:13] The second one is resistance to changing or updating models, our models that we’re using

[00:12:19] as time makes them obsolete.

[00:12:21] This is very possible that you had a good model applied.

[00:12:26] At some point in time, you had picked a model that wasn’t overfit, it was generalizable

[00:12:31] to multiple kind of problem areas that you’re solving and the model is working well and

[00:12:36] performing well, and then something changes.

[00:12:42] This is happening with the global pandemic, for example.

[00:12:47] The environment is always changing, so our behaviors or our health official kind of recommendations

[00:12:54] are going to change with it, and we don’t necessarily intuitively guess that the behaviors

[00:13:01] that we had yesterday or last week or last month are no longer good behaviors.

[00:13:09] In other words, our model that we used to determine what is good behavior in a pandemic

[00:13:15] a month ago is out of date, and the change in the environment has made that model obsolete.

[00:13:25] The same is true in our professional work and in our personal lives as time goes on.

[00:13:32] As the environment changes, it doesn’t really even require a lot of time necessarily.

[00:13:36] If something that you are not in control of is changing around you, then using the same

[00:13:43] model that you used yesterday or at a previous time that’s obsolete now, that is a temptation

[00:13:51] because the model was good.

[00:13:55] This is our brain kind of playing tricks on us again to make us believe that the model

[00:14:00] that we had before is going to continue being good indefinitely regardless of the situation

[00:14:07] that the model is applied under.

[00:14:10] This is a trap that we can fall into because mental models are so useful.

[00:14:16] The moment that we kind of get the reward of applying a useful model or doing that for

[00:14:24] the tenth time, it makes it very difficult to reverse that.

[00:14:28] It makes it difficult to say this model once served us well, but now we have to retire

[00:14:34] it, we have to move on to a new model.

[00:14:38] The third and final pitfall that you might find as you are trying to apply mental models

[00:14:45] is that composition of models can be difficult, especially when the models don’t necessarily

[00:14:50] align.

[00:14:53] We’ve already said that every model that you use is incomplete and this is by definition.

[00:15:00] If the model was complete, then it would actually become the problem.

[00:15:06] The model is a representation of some of the principles of the problem and the problem

[00:15:11] itself might vary or it will vary from the model by some amount.

[00:15:17] If the problem varies kind of drastically from the model, then the model is not a very good

[00:15:22] fit for the problem.

[00:15:26] We’re looking for models that are incomplete on purpose.

[00:15:31] This again avoids that overfitting issue, but if we find a model that is relatively

[00:15:40] good and then we find another model that explains a different part of the problem, let’s say

[00:15:47] that model number one or model A explains the first 60 to 70 percent of the behavior

[00:15:54] that we’re seeing and then model B explains the last 20 or 30 percent of the behavior

[00:16:00] that we’re seeing, but then if we’re looking at model A and model B next to each other,

[00:16:06] they collide, they don’t agree with each other.

[00:16:09] How can this be possible?

[00:16:11] Well, again, this is because our models are not complete representations.

[00:16:17] So a perfect example of this is that we might have archetypes of customers for a given product

[00:16:23] that we have and we might be prone to reject the second or third archetype that we’re seeing

[00:16:28] in our data based on our confidence that the first archetype that we’ve selected is representative

[00:16:34] of more of the target audience than it actually is.

[00:16:37] Let me say this again.

[00:16:40] The idea that we have multiple types of people that we build a product for may intuitively

[00:16:47] be difficult to accept.

[00:16:49] We might have in our minds a single archetype for a person that might use our product.

[00:16:56] And that is a type of model.

[00:16:58] This archetype is a kind of model, a customer model, but the customer model may not be complete.

[00:17:05] And so what we might be tempted to do is instead of trying to compose these conflicting models,

[00:17:13] customer type A and customer type B, we might try to create a middle ground model, something

[00:17:20] that is more lossy, right, more incomplete than model A or B is and tries to strike a

[00:17:28] balance between model A and model B. The problem being that somewhere in the middle could be

[00:17:35] a non-customer, right, somebody who averages these things out might be the incorrect estimation

[00:17:45] for a customer altogether.

[00:17:47] And so when you are picking your models intentionally, keep in mind that it’s okay for two models

[00:17:54] to be applicable to your scenario, even if those models collide and even if they disagree

[00:18:01] with each other, even if the kind of concept of model A doesn’t line up with the concept

[00:18:09] of model B. Ultimately, mental models are still a fundamental tool.

[00:18:16] I don’t even have to tell you to keep using them because you naturally will.

[00:18:20] And you could learn more models and apply more kind of cross-domain thinking and benefit

[00:18:28] from it.

[00:18:29] I highly recommend that you do that.

[00:18:30] But as you continue learning and applying models, keep in mind that some of these same

[00:18:36] pitfalls that we find in other techniques and other tools are going to show up here

[00:18:40] as well.

[00:18:42] And just because we’re applying a model doesn’t mean that we’ve kind of sheltered ourselves

[00:18:46] from those problems.

[00:18:48] Instead, we should stay vigilant and willing to accept new models and try things out, right.

[00:18:54] We should be willing to experiment and consider the model only as useful as it is helpful.

[00:19:02] Thanks so much for listening to today’s episode of Developer Tea.

[00:19:05] Thank you again to today’s sponsor, LaunchDarkly.

[00:19:07] You can get started with enterprise-grade feature flagging, and you can avoid accidentally

[00:19:14] launching all of the code that you’ve been working on to a larger audience than you intended.

[00:19:20] Head over to LaunchDarkly.com to get started today.

[00:19:23] Hey, if you are enjoying Developer Tea, if you’ve enjoyed Developer Tea for years and

[00:19:29] you have held out and you haven’t joined our Discord community, now is a great time to

[00:19:33] do that.

[00:19:34] Really any time is a great time to do that.

[00:19:36] We’re not going to pressure you into joining this community.

[00:19:38] There’s no plans ever, not just plans.

[00:19:43] There’s never going to be a charge to join this community.

[00:19:47] Everyone is welcome.

[00:19:48] If you’re listening to this show, head over to DeveloperTea.com slash Discord to get started

[00:19:53] today.

[00:19:54] Thanks so much for listening, and until next time, enjoy your tea.

Visão de gráfico