We've talked many times on this show about learning in low stakes environments, but what happens when the stakes aren't low? What happens in high stakes environments? That's what we're talking about in today's episode. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal in this show is to help driven developers like you find clarity, perspective, and purpose in their careers. If you have ever been in a high stakes environment, you probably know it. An example of a high stakes environment that we all know about is that moment in, let's say, the Olympics. Let's say there is a high dive, and it comes down to this one last dive. It requires a nearly flawless performance from the diver in order to win. We've seen this before. The stakes are as high as they can get for this particular activity. Interestingly, there is nothing mechanically necessarily different about this dive than any other dive this particular athlete is doing. This athlete probably has executed the dive that they're getting ready to do many times before this. The main variable that has changed is the stakes. What happens as a result of this specific iteration, this specific dive? The consequences of the dives during a practice tend to be very low. This is the point of practice. And indeed, it's the point of having a low stakes learning environment for your software engineering teams. If you can reduce the stakes to learning, then you reduce the errors caused by the stress of having high stakes. Additionally, the learning process itself is accelerated by the failures. And this is true in practice as well. The failed dives are instructive for the athlete, assuming that the athlete is not injured by the failure. So what exactly is happening when we increase the stakes? We'll talk about that right after we talk about today's split. This episode of Developer Teaes brought to you by Split, the future management and experimentation platform. What if a release was exactly how it sounds, just a moment of relief? And escape from slow, painful deployments that hold back product engineers? What was split you can free your teams and your features? By attaching insightful data to feature flags, Split helps you quickly deploy, measure, and learn the impact of every feature you release. Which means you can turn up what works, turn off what doesn't, and give software innovation the room to run wild. Now you can safely deliver features up to 50 times faster and exhale. If you want your releases to be a moment of relief, go and check out Split, Feature Management and Experimentation. Head over to split.io slash Developer Tea. Get started with your first feature flag today. That's split.io slash Developer Teasplit.io slash Developer Tea. Thanks again to Split for sponsoring today's episode. What happens when the stakes are high? Let's talk about what it means for the stakes to be high. Really all this means is that there is more consequence to the actions that are being taken. For example, if the diver jumps off the platform and results in a very poor dive, the consequences are that the diver may lose their position. They may not place in the competition. The worst case scenario is the diver is somehow injured or is not invited back to continue their training process. The best case scenario in this situation, assuming that this is the highest stakes situation, would be that this diver can win the gold. They are at the top of the game and they beat everyone else out. The stakes for this specific single dive are much higher than the stakes could ever be for any of those practice dives. There are also some similar stakes at hand, for example, getting injured. That exists in both competition and in practice. If we're looking to eliminate the commonalities and look at the differences between these two things, the vast majority of the differences have very little to do with the actual performance itself. Think about this for a second. The mechanics of diving. They don't change between practice and performance. The fundamentals of good software engineering. They don't change between practice and performance. But here's the interesting thing. Often people are not choosing the proper ways to practice in the first place. It's imagine that this high diver is diving off of a platform that is half the height of the performance platform. This isn't really a good simulation. The mechanics change between the practice and the performance. So when we talk about creating low stakes environments for practice or for learning in our engineering teams, we need to do this not just for the sake of low stakes environments, but also with an eye towards what does this look like when applied in a high stakes environment? What happens to the mechanics of this process when we go to that higher stakes environment? The reason for this is because what we're doing is we're training our skills. Our skills do not change between low stakes and high stakes. This is a very important thing to understand. Just because you're in a low stakes environment does not mean that you let go of your skill. This is an excellent place to practice your skill. If you are in a low stakes environment, practice implementing the full testing and deployment framework. Practice tracing down bugs and triaging them in a constrained timeline. Create the same kind of mechanics, the same kind of motions, the same kind of actions that you would take in the high stakes environment and practice that. If the first time that you roll back a code base is in production, then it's very likely that something's going to go wrong with the rollback. You've taken a high stakes situation and increased the stakes even further. Now the process of doing a rollback doesn't change, but here is what does change. The people involved understand that this next button press, this next keystroke, has enormous potential for affecting their lives. That is what it means to have a high stakes environment. And so if you're training your skills, if you're training mechanically to operate in the low stakes environment in the same way that you're going to operate in the high stakes environment, what you've done is you've reduced some of the uncertainty. You've reduced some of the cognitive overhead. You've created a pathway, a neural pathway, if you will, that's been well established. You established this neural pathway. You know what it takes to roll back. And now in production, that is a common task. It's something that you can go and execute anytime you need to. The low stakes environment shouldn't just be pushing you to the edge of your skills. The failures that you have in a low stakes environment should be the same failures. It's very important. The same failures that you would have in the high stakes environment. You learn about those types of failures to apply it when it matters most. You may have heard the mantra, we practice how we play and we play how we practice. This is true in almost every aspect of any skill-based activity that you participate in. Often when I see learning environments that are created as low stakes learning environments, there's very little consequence for failure. The kinds of failures that are happening are a result purely of, let's say, experimentation. This would be the equivalent of cross-training. You're failing at practicing a completely different sport than what you're going to play on game day. The analogy here is simple. You might spend time developing new skills in these low stakes environments, but if your high-stake situations are not well practiced, then you're almost certainly going to experience the bad side of the high-stake situation. The pressure that it puts on, if you are in unfamiliar territory, if you haven't developed the muscle memory, if you haven't developed those neural pathways, if you haven't been there before, if you haven't pressed that button, if you haven't done that particular keystroke, that specific command in the terminal, if it feels foreign, well, now those stakes are going to seem like an impossible mountain decline. So design your low stakes to prepare you for the high-stakes environment. Not simply to provide you a broad range of experience and not simply to get you exposed to a bunch of different things that you're not doing in your, quote, real work, but instead to simulate the hard parts of your real work so that when you do fail, the learning opportunity is a very high leverage opportunity. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Split. You can get started with your first feature flag for free today at split.io slash Developer Tea. That's split dot I.O slash Developer Tea. We've had some excellent questions coming in into the Developer Tea Discord community. If you have not joined this, then I don't know what you're waiting for. It's totally free. There's other software engineers in there who are willing to answer questions from you. Everything ranging from really specific code questions, if you're dealing with a problem, you'll feel like going and digging through, you know, days worth of stack overflow links. You can bring those things into the discord, but you can also talk about something as broad as the philosophy that you're trying to follow for your career or for your personal life. All of that is fair game. This is a group of engineers or people who want to become engineers and they are all kind of pursuing and becoming better in their careers, better in their lives. Go and check it out. It's totally free developertea.com slash discord. Go and check that out. Thanks so much for listening. And until next time, enjoy your tea.