Hey, everyone, and welcome to developer team. My name is Jonathan Cottrell. And in today's episode, we're going to be talking about the great developer mindset. This is one in a series of episodes. If you have missed any of the previous great developer mindset episodes, I encourage you to go back and listen to them. Although you can listen to this one first, they are not in any particular order. But in today's episode, we're going to be focusing on becoming acquainted with the great developer mindset. Acquainted with failure. Acquainted with failure. This series is dedicated to guiding you, the listener, the developer, towards the mindset of the great developer. I'm not talking about any anybody in particular, but the great developer. There have been many great developers, perhaps some of them you've never heard their names, because the work they did went relatively unnoticed. But that does not make you a mediocre developer by any stretch. There is a ton of work that developers are doing every single day that may never be known by the general public or even by the general development audience. So that is not what defines greatness. What defines greatness is your mindset. And that is my job on this podcast to help provide you with the tools, the insights, and the inspiration that you need to shape your career as a developer and become truly great at what you do. So in today's episode, we're going to be talking about the great developer mindset. In today's episode, I want to talk to you about getting acquainted with failure. We've talked about failure being an essential part of the learning process in the past on Developer Tea. Of course, that episode will be in the show notes along with all the other great developer mindset episodes. But today, I want to talk to you about getting acquainted with failure. And when I say getting acquainted, I mean becoming intimately familiar with the shape of failure. When you become familiar with something, truly, habitually familiar. If you're a beginner, you often develop what we like to call muscle memory, or maybe you want to call it intuition. This part of your brain is the short-cutting part. When you force yourself to respond to a particular stimuli in a particular way enough times, your brain starts treating that thing less like new stimuli and more like a switch. For example, when you sit down in your car, if you own a car, when you sit down in your car, you can almost touch all of the primary controls in that car. with your eyes closed. You know how to turn up the radio. You know how to turn up the air, maybe. You know exactly how to shift the gears and where the pedals are, where the steering wheel should be. But that's not true in a car you've never driven, even though you can still drive pretty much any other car that is relatively similar to yours, right? In fact, I drove on the opposite side of the road when I visited Europe this past year. It wasn't immediate, but I did gradually get used to it. So some of those things switched over, but the reality is when I sit in my car, I can close my eyes and touch all of those primary control surfaces. I know where those things are in my car because I've done it so many times. And in fact, when I change cars, my hands often go to those places where the controls normally would be in my car, because I have triggers in my brain that tell me how things should look, what actions are next, what route is fastest based on current traffic, for example, on my way to work in the morning, things like that. And so the most common case we experience as developers is either mild bugs or success. This is kind of our car, right? We're used to that. We have muscle memory for those things. We know how to push our code pretty quickly, right? We know get commit, and we can push our code pretty quickly because we're used to being ready to push our code because the code is working. This is why, especially for young developers who haven't had a lot of experience with failure, when failure occurs, it feels like the next action step is impossible to find, right? Think about it. If you got into a totally different vehicle, let's say you got into a semi truck, right? For those of you who don't know how to drive a semi, you decided that you want to drive it, but you don't know how to start it. You don't even know how to start the truck. You have no idea where the controls are. The only thing that is even close to familiar to you is the steering wheel and maybe the pedals. So what do you do next? Well, it's really quite difficult to know because you haven't developed the muscle memory to understand that system, right? If you don't have the muscle memory, it's hard to understand what to do next without going to some sort of manual or asking someone for help. It's really quite difficult to know when you haven't developed that muscle memory. So developing intuition comes from being able to understand what you're doing. So what do you do next? Well, it's really quite difficult becoming familiar with a subject. Luckily, failure isn't difficult to achieve, right? It's pretty easy to fail. In fact, you can practice failure by simply going and looking at another person's issues on Stack Overflow and trying to solve them. In particular, issues that you may be familiar with the underlying technology. So a good exercise is to find the issues that have already been solved, right? Things that already have answers to this question, that have been somewhat validated by whoever was experiencing the problem to begin with, but don't look at the answer. Instead, go and try to solve the problem yourself and then compare your solution to the correct answer. That's an easy way to practice failure, but in all reality, the most valuable failures are the ones you experience in the course of your own true real work, your day in and day out work, right? Those are the failures you will learn the most from. So if you're a failure, you're going to have to practice failure. So if you're a failure, you're going to have to practice failure. So if you're a failure, you're going to have to practice failure. So if you're a failure, you're going to have to practice failure. So if you're a failure, those are the ones that you never see coming. You have no idea what is causing it most likely when it first occurs. And when you experience this kind of failure, I want you to become so familiar with it that you know exactly what is happening the next time it occurs. When you experience that failure, I want you to become familiar with it at a new level. Don't just run to Google. We've talked about running to Google on the show before. Don't run to Stack Overflow. Don't go for the quick way out. Force yourself to struggle a little bit. And this is why you want to do this. By the way, this may be a little bit difficult to convince your employer that it's worth doing. So if you want to truly practice this, it may be worthwhile to do it on your personal projects first. And then once you get the hang of responding to failure a little bit quicker, then you can start doing it at work as well. You will eventually become a better developer, and that's going to... your company a larger profit in the long run, right? So it's not a lost cause. You aren't wasting time when you do this. That's a common misconception. When you don't run straight to Google, you're not wasting time. But when you allow yourself to struggle, you're putting yourself in a position where you don't have that switch flip in your brain. You don't have a next action step. You are intentionally forcing your brain to treat the situation as new stimuli. Right? It's a brand new experience for your brain. So your brain is trying to wrap itself around this experience and understand it. Not only that, but you're creating intuition for future problems that you will very likely experience again. So if you've seen the same problem, or even if you've seen similar problems, problems that look kind of the same shape as problems that you've experienced in the past, if you've seen those over and over, you will have much better understanding of what to do. When that situation occurs. And when you see that problem for the hundredth or the 200th or the 300th time, it's going to flip that switch in your brain. And not only will you be able to understand what to do next to fix that problem, but you might also know a lot about other potential weaknesses in that software, because the path that you followed to get to that particular problem may have other things associated with it, right? Only comes with getting intimately familiar with failure. When you are able to recognize some of the signals around a particular failure, perhaps some of the environmental factors in those pieces of code that you're seeing, you might be able to identify larger systematic problems with that code and increase the quality of the code base at a more holistic level than simply fixing a bug. And that is where really the problem is. And that's where you're going to be able to understand the real value comes in. That is what makes you not only a good debugger, but a great developer. Get familiar with failure, practice it as much as you can and help others through their failures in your job. This has the added benefit that helping other people typically has a profound positive effect on your relational equity in your job as well. So beyond that simple benefit that you should already know about, you will learn how other people think in the process and perhaps find a new and interesting method to problem solving that you wouldn't have been able to figure out on your own. So the next time you experience a bug or you find a problem with your code, or perhaps you fail even with a relationship, don't run to the easy way out. Spend some time getting familiar with the failure. What happened before it? What is happening once you fixed it? What are the other parts of the code? What does the system look like? What is your test coverage right now? Who has been working on the code? A great developer doesn't allow a failure to be simple, right? A great developer knows that failure is only an expression of a larger system. A great developer doesn't allow failure to be the end of the line, but instead a great developer uses failure to become better. Thank you so much for listening to Developer Tea. I hope this has been a useful video. If you have any questions or questions, please feel free to ask them in the comments. I'll see you next time. Enjoy your tea.