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 cutrella you're listening to developer t 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 but in today's episode i want to start with the principle of cognitive load and i'm going to talk about how 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 like oh 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 and you're not going to be able to do that in a few minutes 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 in cognitive 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 an 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 expect it 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're not sure if it's working or not and so you're going to have to go and search for this method and you're going to have to go and search for this method 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 and what it's doing and 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 were to 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 you're not going to be able to recognize 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 you looking for it you've probably heard this trick before it's not really that groundbreaking 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 of the principle of least surprise if you have let's say a boilerplate that all of the teams in in your company uh 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 example of a principle of least surprise and i'm going to explain that in a little bit but first let's get started with the principle of least surprise and 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 you know 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 surprise is that the principle of least surprise is the one that 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 i encourage you to subscribe on whatever podcasting app you're listening to right now thank you so much for listening to today's episode if you enjoyed this episode please subscribe to my channel and hit the bell so you don't miss out on any future episodes of this show if you enjoyed this episode i encourage you also to go join the developer t discord head over to developer t.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 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 and if you haven't yet please do so and i'll see you in the next episode so thank you so much for listening to today's episode and until next time enjoy your tea you