Study after study. Experience after experience. Show us that cognitive load may be the one real enemy that we have to achieving our potential. That's what we're talking about in today's episode. My name is Jonathan Cutrell, you're listening to Developer Tea. I'm going to spend at least the next two episodes talking about cognitive load and I hope to motivate you into believing that reducing cognitive load is one of the most important heuristics that you can have as a software engineer. As you begin to develop more and more complex systems throughout your career, you'll find that cognitive load is kind of the shadow enemy. It's rarely talked about directly, but it's present in almost every decision you make. And I want to talk about in these couple of episodes, some practical ways, some practical ways that you can reduce cognitive load, both in your life and in your work, directly in your code, even. We'll cover some of those. In today's episode, I want to start with the principle of least surprise. Surprise causes an increase in cognitive load. We're going to start with a good kind of surprise for a moment. Let's imagine you walk in your door on your birthday and expecting that you're going to have a calm night at home, but all of a sudden you realize that 30 of your closest friends are waiting for you. And they all jump out and scream surprise. And you're excited to see them, but also all of the plans that you had suddenly change. There's an extreme spike in your cognitive load. You may not know what to do with your hands for a few minutes. And this spike probably doesn't go down. In fact, your best option is to kind of give up and give in to the moment, which is easy to do because really you're talking about trading one fairly inconsequential set of actions, hanging out at home alone for your birthday, for another set of relatively inconsequential actions, hanging out with 30 of your closest friends for your birthday. But even if you would choose the second option, your cognitive load is still increased. Your ability to recognize what is going on, your ability to understand how whatever is happening now has occurred, all of this is reduced. It's hard to conceptualize everything that's happening. And so we experience this when we are surprised, because surprise itself doesn't really necessarily have a good or bad connotation. Surprises can be good or bad. And most often, for example, seeing a bug in our code in production is a surprise. Very different from your 30 friends showing up in your house for your birthday. But what they share in common is that they both cause that spike incognitive load. Now let's talk about how we experience this in code or in our jobs. One example of surprise in code is recognizing all of a sudden that a method that you thought worked one way actually works a different way. And then trying to figure out why it works that way, you realize that sometime in the past, you overwrote that somehow, some way, at some point, you've already forgotten this, but you changed the behavior of a built-in method. Now this is surprising for a couple of reasons. One, the first surprise is that this method doesn't work the way you expected to. And if you were to go and search for this method on Google, even your searching is producing results that are not necessarily correct because you've changed this behavior. And that's the second surprise that you are actually the one that's responsible for the frustration or the surprise that you're experiencing at the moment. This particular example outlines two things. The first is that the principle of least surprise has to kind of predict the future. You imagine what happens when somebody tries to run this custom code? Will they understand what it's doing? Will they have the memory to go back and look it up? Will they know why it's working differently than it seems like it should be working? Secondly, this example illustrates something that you've probably experienced before and that is completely and utterly forgetting something that you yourself did in the past. If you would go and look at code that you wrote a year ago, you may not be able to recognize that it came from you. In fact, most people can't. Now, why does this matter? Well, first, it matters because it helps us kind of calibrate to the intent of the principle of least surprise. And secondly, and secondly, it reinforces the fact that you can surprise your future self. Another great and practical example that has nothing to do with code. Next time you lose an object, once you find it, put it in the first place that you went looking for it. You've probably heard this trick before. It's not really that ground breaking of a trick, but if you've ever, like I have, found your remote in the refrigerator, then you understand this idea. The principle of least surprise is taking advantage of the existing pathways in our brains or of the existing documentation on the internet, of the existing patterns that we use throughout the company. This is another really important example. If you have, let's say, a boilerplate that all of the teams in your company use, and you're considering whether you should use that boilerplate or, you know, hand roll your own. There would have to be a very compelling reason why hand rolling your own is necessary over choosing the one that the other teams are using in your company. Now, I do want you to hear me very clearly that the principle of least surprise can sometimes be used as an excuse to justify just doing what we've always done because it's what we've always done. This is not at all what I'm suggesting. If there are bad defaults or bad practices, you should fix them at the core, at the source. So in that boilerplate example, if it's not doing something that you need it to do, then perhaps it's time to change the boilerplate rather than going and creating your own code. The least variation that you can introduce into a system, the more predictable the system is. This is a simple concept. Imagine that you're trying to predict what something is going to do and then build it to that prediction. We're going to talk more about reducing cognitive load in future episodes of this show. If you don't want to miss out on that, encourage you to subscribe and whatever podcasting app you're listening to right now. Thank you so much for listening to today's episode. If you enjoyed this episode, I encourage you also to go join the Developer Tea Discord head over to DeveloperTea.com slash discord. That community is totally free to join and it's entirely made for people like you. If you listen all the way to the end of this episode, then you are the target audience for that group of people and I guarantee you that the conversations that are had there will enrich your professional and personal life. I highly recommend that. And then finally, I'm going to make a simple ask of you. If you have not yet taken the time to review this podcast on iTunes or another major podcasting platform, then now is the time to do that. Specifically, if you've been listening to the show, let's say you've listened to 10 or more episodes, then one of two things must be true. Either one, you've gotten value out of the podcast and you've continued listening so that you can continue getting more value out of it. Or two, you haven't gotten value out of it and you're wasting your time. So you should take one of two actions. Either one, if you have gotten value out of it, share your review with other engineers. That's the request that I'm making here so that other people can find the show and get the same value that you have. That's a free thing for you to do and it helps other people grow and become better engineers alongside you. Or two, free up your time. Stop listening to the show. I sincerely hope that that is not the option that you choose. Hopefully you are getting value out of this if you've been listening for that long. So thank you so much for listening to today's episode and until next time, enjoy your tea.