Vox

Leitura de 12 min

Lower Cognitive Load - Principle of Least Surprise

Summary

Jonathan Cattralli introduces cognitive load as the “shadow enemy” in software engineering, rarely discussed directly but present in almost every decision. He explains that reducing cognitive load is one of the most important heuristics for engineers working with increasingly complex systems throughout their careers.

The episode focuses specifically on the principle of least surprise, which states that surprise causes an immediate spike in cognitive load. Cattralli illustrates this with examples ranging from a surprise birthday party (positive surprise) to discovering bugs in production code (negative surprise). Both scenarios share the common effect of increasing mental strain and reducing one’s ability to understand what’s happening.

Practical examples from software development include discovering that a method works differently than expected because someone (possibly yourself) overwrote its behavior in the past. This creates multiple layers of surprise: first that the method behaves unexpectedly, and second that you might be responsible for your own frustration. The principle requires predicting how future developers (including your future self) will interact with code, since people often forget what they wrote themselves.

Beyond code, Cattralli discusses applying the principle of least surprise to everyday situations like placing lost items where you first looked for them, and to organizational decisions like using established company boilerplates rather than creating custom solutions. He cautions that the principle shouldn’t be used to justify bad practices, but rather to minimize unnecessary variation while fixing problems at their source.

The episode concludes by emphasizing that reducing cognitive load through the principle of least surprise makes systems more predictable and manageable, setting the stage for future discussions on additional strategies for minimizing mental strain in software engineering work.

Recommendations

Communities

  • Developer Tea Discord — Cattralli recommends joining the Developer Tea Discord community at developert.com/Discord, describing it as free and made for listeners who want to enrich their professional and personal lives through conversations with like-minded people.

Topic Timeline

  • 00:00:00 — Introduction to cognitive load as the enemy of potential — Jonathan Cattralli introduces the episode’s focus on cognitive load, describing it as the “shadow enemy” in software engineering that’s rarely discussed directly but present in almost every decision. He announces this will be the first of at least two episodes on practical ways to reduce cognitive load in life, work, and code.
  • 00:01:23 — Introducing the principle of least surprise — Cattralli introduces the principle of least surprise as today’s specific focus, explaining that surprise causes an increase in cognitive load regardless of whether it’s positive or negative. He begins with an example of a surprise birthday party to illustrate how even positive surprises create mental strain by forcing sudden changes to expectations and plans.
  • 00:03:22 — Surprise in software development contexts — The discussion shifts to surprise in software development, using the example of discovering a bug in production code. Cattralli explains that while this is very different from a birthday party surprise, both share the common effect of spiking cognitive load and reducing one’s ability to understand what’s happening.
  • 00:03:38 — Example of surprising code behavior — Cattralli provides a concrete code example: discovering that a method works differently than expected because its behavior was overwritten in the past. This creates multiple surprises - first that the method behaves unexpectedly, and second that you might be responsible for your own frustration if you were the one who made the change.
  • 00:05:29 — Why surprising yourself matters — Cattralli explains why forgetting your own past code matters: it helps calibrate the intent of the principle of least surprise and reinforces that you can surprise your future self. This understanding is crucial for applying the principle effectively in development work.
  • 00:05:49 — Non-code example: placing lost items — A practical non-code example is discussed: placing lost items where you first looked for them. Cattralli relates this to taking advantage of existing mental pathways, similar to how the principle of least surprise leverages existing documentation, internet resources, and company patterns.
  • 00:06:26 — Organizational example: company boilerplates — Cattralli discusses using established company boilerplates versus creating custom solutions as an organizational application of the principle. He explains there should be compelling reasons to deviate from existing patterns, as minimizing variation makes systems more predictable.
  • 00:06:53 — Caution against misusing the principle — Cattralli cautions that the principle of least surprise shouldn’t be used to justify doing things just because they’ve always been done. If there are bad defaults or practices, they should be fixed at the source rather than perpetuated under the guise of reducing surprise.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2022-07-20T07:00:00Z
  • Duration: 00:09:37

References

Podcast Info

Transcript

[00:00:00] Study after study, experience after experience, show us that cognitive load may be the one

[00:00:20] real enemy that we have to achieving our potential.

[00:00:26] That’s what we’re talking about in today’s episode.

[00:00:27] My name is Jonathan Cattralli.

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

[00:00:32] I’m going to spend at least the next two episodes talking about cognitive load, and I hope to

[00:00:40] motivate you into believing that reducing cognitive load is one of the most important

[00:00:47] heuristics that you can have as a software engineer.

[00:00:51] As you begin to develop more and more complex systems throughout your career, you’ll find

[00:00:57] that cognitive load is kind of the shadow enemy.

[00:01:02] It’s rarely talked about directly, but it’s present in almost every decision you make.

[00:01:09] And I want to talk about in these couple of episodes some practical ways, some practical

[00:01:14] ways that you can reduce cognitive load both in your life and in your work, directly in

[00:01:19] your code even.

[00:01:21] We’ll cover some of those.

[00:01:23] But in today’s episode, I want to start with the principle of least surprise.

[00:01:29] Surprise causes an increase in cognitive load.

[00:01:35] We’re going to start with a good kind of surprise for a moment.

[00:01:38] Let’s imagine you walk in your door on your birthday and expecting that you’re going to

[00:01:45] have a calm night at home, but all of a sudden you realize that 30 of your closest friends

[00:01:50] are waiting for you.

[00:01:53] And they all jump out and scream surprise, and you’re excited to see them, but also all

[00:01:59] of the plans that you had suddenly change.

[00:02:04] There’s an extreme spike in your cognitive load.

[00:02:07] You may not know what to do with your hands for a few minutes, and this spike probably

[00:02:12] doesn’t go down.

[00:02:14] In fact, your best option is to kind of give up and give in to the moment, which is easy

[00:02:20] to do because really you’re talking about trading one fairly inconsequential set of

[00:02:25] actions, hanging out at home alone for your birthday, for another set of relatively inconsequential

[00:02:33] actions, hanging out with 30 of your closest friends for your birthday.

[00:02:38] But even if you would choose the second option, your cognitive load is still increased.

[00:02:46] Your ability to recognize what is going on, your ability to understand how whatever is

[00:02:53] happening now has occurred, all of this is reduced.

[00:02:58] It’s hard to conceptualize everything that’s happening.

[00:03:02] And so we experience this when we are surprised because surprise itself doesn’t really necessarily

[00:03:08] have a good or bad connotation.

[00:03:12] Surprises can be good or bad.

[00:03:14] But most often, for example, seeing a bug in our code in production is a surprise.

[00:03:22] Very different from your 30 friends showing up in your house for your birthday.

[00:03:27] But what they share in common is that they both cause that spike in cognitive load.

[00:03:32] Now let’s talk about how we experience this in code or in our jobs.

[00:03:38] One example of surprise in code is recognizing all of a sudden that a method that you thought

[00:03:44] worked one way actually works a different way.

[00:03:48] And then, trying to figure out why it works that way, you realize that sometime in the

[00:03:54] past you overwrote that.

[00:03:58] Somehow, someway, at some point, you’ve already forgotten this, but you changed the behavior

[00:04:05] of a built-in method.

[00:04:08] Now this is surprising for a couple of reasons.

[00:04:11] The first surprise is that this method doesn’t work the way you expect it to.

[00:04:17] And if you were to go and search for this method on Google, even your searching is producing

[00:04:23] results that are not necessarily correct because you’ve changed this behavior.

[00:04:29] And that’s the second surprise, that you are actually the one that’s responsible for the

[00:04:34] frustration or the surprise that you’re experiencing at the moment.

[00:04:38] This particular example outlines two things.

[00:04:42] The first is that the principle of least surprise has to kind of predict the future.

[00:04:48] You imagine what happens when somebody tries to run this custom code.

[00:04:54] Will they understand what it’s doing?

[00:04:56] Will they have the memory to go back and look it up?

[00:05:00] Will they know why it’s working differently than it seems like it should be working?

[00:05:06] Secondly, this example illustrates something that you’ve probably experienced before, and

[00:05:11] that is completely and utterly forgetting something that you, yourself, did in the past.

[00:05:19] If you were to go and look at code that you wrote a year ago, you may not be able to recognize

[00:05:24] that it came from you.

[00:05:25] In fact, most people can’t.

[00:05:28] Why does this matter?

[00:05:29] Well, first, it matters because it helps us kind of calibrate to the intent of the principle

[00:05:35] of least surprise.

[00:05:37] And secondly, it reinforces the fact that you can surprise your future self.

[00:05:44] Another great and practical example that has nothing to do with code.

[00:05:49] Next time you lose an object, once you find it, put it in the first place that you went

[00:05:55] looking for it.

[00:05:57] You’ve probably heard this trick before.

[00:05:58] It’s not really that groundbreaking of a trick, but if you’ve ever, like I have, found your

[00:06:05] remote in the refrigerator, then you understand this idea.

[00:06:09] The principle of least surprise is taking advantage of the existing pathways in our

[00:06:15] brains or of the existing documentation on the internet, of the existing patterns that

[00:06:21] we use throughout the company.

[00:06:22] This is another really important example.

[00:06:26] If you have, let’s say, a boilerplate that all of the teams in your company use and you’re

[00:06:33] considering whether you should use that boilerplate or hand roll your own, there would have to

[00:06:38] be a very compelling reason why hand rolling your own is necessary over choosing the one

[00:06:45] that the other teams are using in your company.

[00:06:47] Now, I do want you to hear me very clearly that the principle of least surprise can sometimes

[00:06:53] be used as an excuse to justify just doing what we’ve always done because it’s what we’ve

[00:07:02] always done.

[00:07:04] This is not at all what I’m suggesting.

[00:07:06] If there are bad defaults or bad practices, you should fix them at the core, at the source.

[00:07:13] So in that boilerplate example, if it’s not doing something that you need it to do, then

[00:07:18] perhaps it’s time to change the boilerplate rather than going and creating your own code.

[00:07:25] The least variation that you can introduce into a system, the more predictable the system

[00:07:31] is.

[00:07:33] This is a simple concept.

[00:07:35] Imagine that you’re trying to predict what something is going to do and then build it

[00:07:40] to that prediction.

[00:07:41] We’re going to talk more about reducing cognitive load in future episodes of the show.

[00:07:46] If you don’t want to miss out on that, I encourage you to subscribe and whatever podcasting

[00:07:50] app you’re listening to right now.

[00:07:52] Thank you so much for listening to today’s episode.

[00:07:55] If you enjoyed this episode, I encourage you also to go join the Developer T Discord, head

[00:07:59] over to developert.com slash Discord.

[00:08:02] That community is totally free to join and it’s entirely made for people like you.

[00:08:07] If you listen all the way to the end of this episode, then you are the target audience

[00:08:11] for that group of people and I guarantee you that the conversations that are had there

[00:08:16] will enrich your professional and personal life.

[00:08:19] Highly recommend that.

[00:08:20] And then finally, I’m going to make a simple ask of you if you have not yet taken the time

[00:08:24] to review this podcast on iTunes or another major podcasting platform, then now is the

[00:08:31] time to do that.

[00:08:32] Specifically, if you’ve been listening to the show, let’s say you’ve listened to 10

[00:08:36] or more episodes, then one of two things must be true.

[00:08:40] Either one, you’ve gotten value out of the podcast and you’ve continued listening so

[00:08:44] that you can continue getting more value out of it.

[00:08:47] Or two, you haven’t gotten value out of it and you’re wasting your time.

[00:08:51] So you should take one of two actions.

[00:08:53] Either one, if you have gotten value out of it, share your review with other engineers.

[00:08:59] That’s the request that I’m making here so that other people can find the show and get

[00:09:02] the same value that you have.

[00:09:04] That’s a free thing for you to do and it helps other people grow and become better engineers

[00:09:08] alongside you.

[00:09:10] Or two, free up your time.

[00:09:12] Stop listening to the show.

[00:09:13] I sincerely hope that that is not the option that you choose.

[00:09:17] Hopefully you are getting value out of this if you’ve been listening for that long.

[00:09:20] So thank you so much for listening to today’s episode and until next time, enjoy your team.

Visão de gráfico