Vox

Leitura de 21 min

Mental Models - Lenses for Thinking and Decisions (Part 2)

Summary

This episode continues the exploration of mental models as lenses for thinking and decision-making. Jonathan Cattralli introduces two specific models that can help developers and teams approach their work more effectively.

The first model discussed is criticality, which refers to the moment of phase change where a small additional effort creates disproportionate value. Using the analogy of water freezing at 0°C, Cattralli explains how the final step in a process often holds unique importance. In software development, this might be the difference between code that’s “almost complete” on a local machine and code that’s actually shipped and providing value. He emphasizes that many aspects of our work don’t have continuous value functions—the value often appears only after crossing that critical threshold of completion.

The second model is Gresham’s Law, which states that when given the opportunity, systems will tend to select behaviors that provide competitive advantages, even if they’re against established standards. Cattralli illustrates this with a common software development scenario: a team starts with good practices (testing, code standards) but under pressure to deliver features quickly, begins cutting corners. The short-term advantage of faster shipping gradually replaces the sustainable good practices, leading to technical debt, harder onboarding, and reduced team sanity.

Cattralli explains that both models require conscious governance. For criticality, developers should identify and prioritize those final, high-leverage steps. For Gresham’s Law, teams must create cultures that celebrate and incentivize good practices rather than allowing expedient bad practices to take over. He suggests that “what you celebrate is what you create”—focusing attention and praise on desired behaviors helps them prevail.

Throughout the episode, Cattralli connects these mental models to practical software development contexts while emphasizing their broader applicability beyond tech. He recommends additional resources like the Farnam Street blog for further exploration of mental models.

Recommendations

People

  • Charlie Munger — Mentioned as Warren Buffett’s business partner and a source of many mental models that apply beyond software development to various fields and decision-making contexts.

Websites

  • Farnam Street (fs.blog) — Recommended as an excellent resource for learning more about mental models, with extensive content on the blog and podcast featuring interviews with leaders about their thinking processes.
  • Sentry (sentry.io) — Promoted as an error monitoring tool that helps developers identify bugs before customers encounter them, providing stack traces, user impact data, and commit information for debugging.
  • Tea Break Challenge (teabreakchallenge.com) — Recommended as a daily soft skills challenge delivered via email, designed to help developers improve their careers and lives in just a few minutes per day.

Topic Timeline

  • 00:00:00 — Introduction and resource recommendation for mental models — Jonathan Cattralli introduces the episode as a continuation of the mental models discussion. He recommends the Farnam Street blog (fs.blog) as an excellent resource for learning more about mental models, mentioning its connection to Charlie Munger and Warren Buffett’s thinking. He emphasizes that these principles apply beyond software development and encourages cross-disciplinary sharing of ideas.
  • 00:01:52 — Recap of previous episode’s mental models — Cattralli briefly recaps the two mental models from the previous episode: compound interest and higher-order thinking (considering second, third, and fourth-order effects of decisions). He reiterates that mental models are lenses or vantage points, not absolute truths, and their utility depends on context.
  • 00:03:37 — Introduction to the first model: Criticality — Cattralli introduces the first mental model of this episode: criticality. He defines it as understanding the moment of phase change, using the example of water freezing at 0°C. The key insight is that the last degree of temperature change (from 1°C to 0°C) has dramatically different utility than previous degrees, as it changes the state of the matter from liquid to solid.
  • 00:05:11 — Applying criticality to real-world examples — Cattralli applies the criticality model to examples like completing a college degree (you either have it or you don’t) and software development (code isn’t valuable until it’s shipped). He explains that many things in life and work have binary outcomes rather than continuous value functions, making the final steps particularly important.
  • 00:06:50 — Practical implications of criticality for developers — Cattralli encourages developers to constantly identify those final critical steps in their work. He suggests reframing completion by considering verification as the actual final step, not just deployment. The core insight is that some actions hold more utility than others, particularly those that move work from incomplete to complete.
  • 00:08:28 — Sponsor segment: Sentry error monitoring — The episode transitions to a sponsored segment for Sentry, an error monitoring tool. Cattralli discusses the limitations of relying solely on customer bug reports or comprehensive testing, explaining how Sentry helps developers identify and fix errors before customers encounter them by providing stack traces, user impact data, and commit information.
  • 00:10:46 — Introduction to the second model: Gresham’s Law — Cattralli introduces the second mental model: Gresham’s Law. He begins by painting a picture of a software team that starts with good practices but gradually abandons them under pressure to deliver features quickly, leading to technical debt and reduced sustainability.
  • 00:12:00 — The deceptive speed of cutting corners — Cattralli describes how teams initially experience what seems like competitive advantage from cutting corners—shipping faster, pleasing customers and sales teams. However, this creates a deceptive speed that trades short-term gains for long-term sustainability, making code harder to maintain and onboard new developers to.
  • 00:13:38 — The consequences of ungoverned poor practices — Cattralli explains the downward spiral: as original developers leave, knowledge of poorly-written code disappears, making changes risky. The team agrees they should have tests but views them as a luxury rather than a necessity. This illustrates Gresham’s Law: ungoverned systems will select advantageous behaviors even if they’re against standards.
  • 00:15:08 — Governing against Gresham’s Law in teams — Cattralli discusses how to counteract Gresham’s Law through governance, particularly for engineering managers and team leaders. He emphasizes aligning incentives with sustainable practices rather than just velocity. A key principle is that ‘what you celebrate is what you create’—praising desired behaviors helps them prevail over expedient but harmful ones.
  • 00:17:00 — Recap and conclusion of both mental models — Cattralli recaps both models: criticality (the importance of phase changes and completion) and Gresham’s Law (how poor practices can drive out good ones if they provide advantages). He reiterates the need to celebrate good practices and negate the advantages of poor ones to maintain sustainable team cultures.
  • 00:17:51 — Closing recommendations and resources — Cattralli thanks Sentry again and recommends fs.blog (Farnam Street) for more mental models content. He also promotes the Tea Break Challenge (teabreakchallenge.com) for daily soft skills development. He encourages listeners to apply these lenses to improve their work and careers.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-01-16T10:00:00Z
  • Duration: 00:18:58

References

Podcast Info

Transcript

[00:00:00] We’re continuing our discussion on mental models in today’s episode, but I do want to

[00:00:09] take a moment to credit a excellent resource where you can learn more about mental models.

[00:00:16] Farnam Street, the Farnam Street blog, the podcast is also excellent.

[00:00:20] That’s F-A-R-N-A-M, but the URL is fs.blogslashmental-models.

[00:00:29] That’ll likely be in the show notes for this episode as well, fs.blog.

[00:00:33] There’s tons of excellent content on the Farnam Street blog.

[00:00:37] You can also probably Google Farnam Street mental models, and a lot of these models also

[00:00:41] can be found by doing a bit of research on Charlie Munger.

[00:00:45] That’s the business partner of the extraordinarily wealthy Warren Buffett, and a lot of these

[00:00:50] things apply, certainly apply outside of software development.

[00:00:55] So I encourage you, if you’re not a software developer, to still continue listening to

[00:01:00] this episode and share it with other non-software developers.

[00:01:04] So many careers now depend on the same kind of principles that software developers depend

[00:01:10] on, and software developers depend on principles that have long been in existence outside of

[00:01:17] software development.

[00:01:18] So certainly do some cross-training here and share these ideas and have conversations about

[00:01:23] these ideas with non-software developers in your life.

[00:01:27] You’re likely to see some very good, unique perspectives that those people have because

[00:01:35] they have different experiences than what you have in your career.

[00:01:39] My name is Jonathan Cattralli.

[00:01:40] You’re listening to Developer Tea, and my goal on the show is to help driven developers

[00:01:44] connect to their career purpose and to do better work so they can have a positive influence

[00:01:49] on the people around them.

[00:01:52] In the last episode of Developer Tea, we talked about two mental models.

[00:01:57] And just a quick reminder, mental models are a way of seeing the world.

[00:02:00] They’re a vantage point.

[00:02:02] These are not perfect.

[00:02:04] They’re not truth with a capital T. These are lenses through which you can see the world.

[00:02:13] And different lenses, different vantage points provide you with different types of leverage

[00:02:18] given your specific context.

[00:02:22] So understanding how you should spend your time is highly contextual to you, but putting

[00:02:27] on these lenses helps you see the world in new and sometimes very useful ways for accomplishing

[00:02:33] whatever it is that you’re trying to accomplish.

[00:02:35] So don’t try to see these things as hard and fast laws of the universe, right?

[00:02:42] That’s not the point of this.

[00:02:44] Instead, it’s ways that you can shift your thinking, and your thinking is really kind

[00:02:49] of where your action and decision come from.

[00:02:53] Okay, so the two models that we talked about in the last episode, first was compound interest.

[00:03:01] The second was second order, third order, fourth order thinking.

[00:03:07] You can think about this as developers in order thinking, I suppose, in plus one order

[00:03:12] thinking going beyond the initial effects of whatever your decisions are.

[00:03:17] In today’s episode, we want to continue our discussion.

[00:03:20] In today’s episode, we’re talking about two different mental models that can help you

[00:03:24] think about better ways to approach your work.

[00:03:28] And we’re going to jump straight in, we’re not going to spend any time today introducing

[00:03:32] this topic.

[00:03:33] We did plenty of that in the first episode, in the previous episode rather.

[00:03:37] The first mental model is criticality, criticality.

[00:03:42] This is a way of understanding certain types of events that you encounter, the criticality

[00:03:48] of those events.

[00:03:50] And more specifically, criticality is referring to the moment of a phase change.

[00:03:58] And one of the most commonly referred to examples of this is changing the state of a given material

[00:04:05] from, for example, a liquid to a solid that happens in a single moment.

[00:04:12] If you’ve ever seen pictures of, for example, a lake that is frozen, there is a moment in

[00:04:17] time right before that ice became solid, where it was liquid.

[00:04:24] Now the interesting reality is that as the water decreased in temperature, let’s say

[00:04:30] from five degrees Celsius down to four degrees Celsius, and from four to three and so on,

[00:04:36] this decrease was probably a linear decrease.

[00:04:40] The amount of energy that that water was holding was decreasing at a linear rate and

[00:04:45] yet the phase of the water remained the same.

[00:04:49] That is, all until that last degree.

[00:04:53] That last degree changed the phase of the water, and so the concept is that the last

[00:04:58] degree holds a particularly different meaning, a utility that is particularly different from

[00:05:05] the other degrees of change.

[00:05:08] And this is true in many other areas.

[00:05:11] One of my favorite examples of this is completing a college degree.

[00:05:17] If you’ve gone for three and a half years and you have a half year left of classes,

[00:05:24] and you get all the way to the end and you’re missing the equivalent of a single semester

[00:05:29] of a class, well, it’s easy to imagine that you essentially have a degree.

[00:05:35] In your mind, you have all of the information except for that one class.

[00:05:42] The problem is that having a degree or not having a degree is not a continuous function.

[00:05:48] In other words, you can’t really put almost a degree on your resume.

[00:05:55] It’s a binary, complete or incomplete.

[00:05:59] And a lot of things that we do as developers, this is true for.

[00:06:03] If you spend all day working on a feature and you go through the process of testing

[00:06:08] it, you have somebody look at the code over your shoulder, but it’s five o’clock and

[00:06:15] at five oh one, you have to walk out the door, but you forget to push the code.

[00:06:20] Unfortunately, this last step happens to be a critical step.

[00:06:26] Actually shipping the thing that you worked on is a very highly important step, right?

[00:06:34] It’s that last step, that phase change from not shipped or local on my computer to shipped.

[00:06:42] So as a developer, I encourage you to constantly be aware of those final critical steps.

[00:06:50] Those last pieces of the puzzle that take you from, for example, incomplete to complete.

[00:06:58] A good way of thinking about this is imagining that you actually have three steps remaining,

[00:07:05] that actually launching something, actually completing something is not the final step,

[00:07:10] but in fact, verifying that it is complete is the final step.

[00:07:15] Perhaps this can change the way that you view that timeline.

[00:07:20] Ultimately, understanding the lens of criticality is key to realizing that some of the actions

[00:07:28] that we take hold more utility than others.

[00:07:33] More specifically, not all of our work has continuous functions that describe the value

[00:07:39] of that work.

[00:07:40] The work that you’re doing may not become valuable at all until it’s public, for example.

[00:07:47] Even though you may have learned something from it, that value is much harder to recognize

[00:07:51] and much harder to justify, and the extended value that you get, the additional value,

[00:07:59] the additional utility you get for making that public far exceeds the utility of the

[00:08:05] learning that you personally had, particularly from your employer’s perspective.

[00:08:12] So that’s the first mental model for today, criticality.

[00:08:15] You can also think of this as completeness or as non-continuous value.

[00:08:20] All of these are ways of thinking about this mental model.

[00:08:22] We’re going to talk about today’s sponsor, and then we’ll get back into our discussion

[00:08:26] with our second mental model for today.

[00:08:28] Today’s episode is sponsored by Sentry.

[00:08:31] It’s very likely that you have code that is broken in your application right this second,

[00:08:38] and you may not even know where it’s going to come from.

[00:08:41] You may have no idea, and that code can go unnoticed for a long period of time, especially

[00:08:48] if only a few users are encountering it, and even worse, if users who encounter it leave

[00:08:56] your product altogether.

[00:08:58] Relying on those customers to report errors when they’re leaving, that’s a bad idea.

[00:09:04] You’re kind of treating your customers as an offsite QA team.

[00:09:08] This is not a good plan, and it’s pretty rude to those customers.

[00:09:12] Ideally, this would be solved with tests.

[00:09:15] You just cover all your code in tests, and then you’re good, right?

[00:09:19] But the problem is, you’re not going to cover every scenario with tests.

[00:09:24] Life would be perfect, but it’s not reality.

[00:09:27] Humans are actually pretty bad at writing tests, certainly bad at trying to cover your

[00:09:32] entire code base.

[00:09:33] It’s just not going to happen.

[00:09:35] So relying on tests to catch every single bug is a bad plan, too.

[00:09:40] Beyond the fact that we’re bad at writing tests that cover all of our code, we’re also

[00:09:46] bad at predicting how people will interact with our code in the future, and how external

[00:09:50] products will interact with our code in the future.

[00:09:53] This is why Sentry tells you about errors in your code before your customers have a

[00:10:00] chance to encounter them.

[00:10:02] Not only does Sentry tell you about the errors, but it also gives you all the details you’ll

[00:10:07] need to be able to fix them.

[00:10:08] For example, you can get a stack trace.

[00:10:10] You can get the number of users who have actually encountered that bug so far.

[00:10:17] You can even get the commit that the error was released as a part of, and go and collaborate

[00:10:21] with the engineer who made the decision to write the code in that particular way.

[00:10:26] You can get started with Sentry right now by going to sentry.io.

[00:10:31] It integrates with all of your existing platforms, and I’ve been using Sentry since before they

[00:10:37] became a sponsor of this show.

[00:10:40] Go and check it out.

[00:10:41] Sentry.io.

[00:10:42] Thank you again to Sentry for sponsoring today’s episode of Developer Tea.

[00:10:46] The second middle model that I’d love to talk to you about today, and as it relates to testing

[00:10:51] we were just talking about with Sentry, is Gresham’s Law.

[00:10:56] Before we talk about the law, I want to paint a picture for you, and you’ll probably understand

[00:11:02] this picture all too well.

[00:11:05] You start working on a code base with a bunch of good developers, conscientious developers.

[00:11:11] Developers who all agree that there should be tests, and we should follow a similar code

[00:11:18] style, that we should have standards for the way that we write our code, and standards

[00:11:25] for the way that we test our code, standards for the way that we deploy our code.

[00:11:31] You even go through the process of writing those standards up, and maybe even setting

[00:11:35] up some of this stuff.

[00:11:36] Some ways for people to test, and ways for people to lint their code, and you start working.

[00:11:44] You start developing features, and product people come along and they get involved, and

[00:11:50] sales people and customer service people come along and they get involved.

[00:11:53] People start using your application, and things are going well, at least at first.

[00:12:00] Not that you have real customers, and money is flowing, and you have too many things to

[00:12:08] do for the amount of time that you have available.

[00:12:12] People start to cut corners.

[00:12:15] Where they would have written four tests, now they’re writing three, and where they

[00:12:20] would have written three tests, now they’re writing one, or maybe even none.

[00:12:26] The customer service team is thanking the developers who are moving so quickly, sales

[00:12:32] are going through the roof, and even though you have a few late nights here and there

[00:12:36] because of an unexpected bug, things seem to be still pretty smooth.

[00:12:43] The problem is that all those standards that you had in the beginning, they’re starting

[00:12:48] to crack, things are starting to fall apart, and even though you’re profitable, and even

[00:12:54] though you’re shipping features, you can see the signs that you’re starting to build

[00:13:01] up tech debt.

[00:13:04] You’re starting to get into a situation where the code is a little bit harder to read.

[00:13:10] As new people come onto the team, they’re recognizing those problems, and it’s taking

[00:13:16] them longer to onboard.

[00:13:19] You and other developers begin to be a little bit afraid to change code because it doesn’t

[00:13:25] really have any coverage, you’re not really sure how it works, and you weren’t the one

[00:13:29] who wrote it in the first place, so you’re constantly having to go and ask the person

[00:13:34] who wrote that code how it works.

[00:13:38] Unfortunately, those people start leaving.

[00:13:42] They start getting different offers at other companies, and now the person who originally

[00:13:46] wrote that code is gone, and nobody knows how it works.

[00:13:51] Your company isn’t failing, but your sanity is starting to slip away, and the developers

[00:13:59] all still agree that we should have tests.

[00:14:03] The problem is everybody views it as something they wish they had rather than something they

[00:14:09] need to have.

[00:14:11] This is a picture of Gresham’s Law, or it’s similar to Gresham’s Law at the very least.

[00:14:18] Gresham’s Law states that when given the opportunity to do something bad that gives you some kind

[00:14:25] of competitive advantage, a system that is ungoverned will select the thing that gives

[00:14:31] the advantage, even if it’s against your standards.

[00:14:35] In the case of our story of the startup that is increasing their technical debt every day,

[00:14:41] the competitive advantage is, well, we’re getting things shipped.

[00:14:45] We’re able to sell to more customers because we have more features, and we’re able to be

[00:14:50] more responsive.

[00:14:52] This gives us an advantage, and at a personal level, the developers are able to complete

[00:14:58] tasks faster, able to complete more tasks.

[00:15:03] This is a deceptive speed that initially takes hold.

[00:15:08] The problem that we end up facing is that that competitive advantage in the short term

[00:15:14] is traded for sustainability in the long term.

[00:15:17] This lens is particularly important to carry as a software engineering manager, as any

[00:15:23] kind of leader role, but it’s also important for the individual developers to carry.

[00:15:29] The reason for this is recognizing that it’s very likely that if we allow poor practices

[00:15:37] to result in an advantage for too long, those poor practices will replace our less advantageous

[00:15:44] good practices.

[00:15:46] As a general rule, these poor practices need to be policed and governed.

[00:15:53] These can be governed by ourselves, but even better if they are governed by the team as

[00:15:58] a community.

[00:16:00] Incentives need to be aligned with relying on and continuing to practice the things that

[00:16:05] we know increase sustainability, rather than simply looking at velocity, for example.

[00:16:13] A very simple way to think about this is what you celebrate is what you create.

[00:16:20] The things that you praise, people will do more of them.

[00:16:24] The things that you ignore will naturally die in favor of the things that you praise.

[00:16:30] It’s critical that you create a culture where the things that you want to continue to prevail

[00:16:38] are the things that you focus on, that you applaud, that you hold up on a pedestal.

[00:16:44] You create values and then you discuss those values.

[00:16:48] You call those behaviors out in a positive way.

[00:16:52] This is one way of governing those behaviors as well.

[00:16:56] Those are two more mental models, lenses for seeing the world.

[00:17:00] I hope you enjoyed today’s episode.

[00:17:02] Once again, the first lens was criticality.

[00:17:06] The idea of moving from one phase to another and that the phase change and the changes

[00:17:14] right before the phase change have a higher value, a higher utility, a higher importance

[00:17:21] than the other moments in that phase change.

[00:17:26] The second lens is Gresham’s law, the idea that if you have a poor practice that yields

[00:17:32] an advantage over a good practice, then the good versus bad nature of those practices

[00:17:39] ends up being lost.

[00:17:41] You must find ways to celebrate the good and negating the advantages of the poor practices.

[00:17:49] Thank you so much for listening to today’s episode of Developer Tea.

[00:17:51] Thank you again to Sentry for sponsoring today’s episode.

[00:17:54] Head over to sentry.io to start finding bugs you didn’t even know you had in your code

[00:17:59] base today.

[00:18:01] If you enjoyed these two episodes on mental models, there are plenty more mental models

[00:18:05] that you can go and learn about at fs.blog.

[00:18:10] This is not my blog.

[00:18:11] This is Farnham Street.

[00:18:12] Excellent content.

[00:18:13] They also have a wonderful podcast where they do extended interviews with people about the

[00:18:18] way they think, about the things that they’re reading.

[00:18:21] These are leaders in various industries.

[00:18:23] I encourage you to go and check it out, fs.blog and Farnham Street on whatever podcast player

[00:18:29] you’re using.

[00:18:30] If you’re enjoying these kinds of topics, I encourage you to subscribe to the Tea Break

[00:18:35] Challenge.

[00:18:36] Head over to teabreakchallenge.com.

[00:18:38] This is a daily soft skills challenge that will help you improve in your career and in

[00:18:43] your life.

[00:18:44] In just a few minutes a day, it gets delivered directly to your inbox.

[00:18:47] Thank you so much for listening and until next time, enjoy your tea.

Visão de gráfico