Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell 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 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 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. That is not what defines greatness. What defines greatness is your mindset. 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. 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 development. Of course, that episode will be in the show notes along with all the other great developer mindset episodes. Today I want to talk to you about getting acquainted with failure. When I say getting acquainted, I mean becoming intimately familiar with the shape of failure. When you become familiar with something truly, habitually familiar, 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. 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 services. I know where those things are in my car because I've done it so many times. 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. So the most common case we experience as developers is either mild bugs or success. This is our car. We're used to that. We have muscle memory for those things. We know how to push our code pretty quickly. 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. Think about it. If you got into a totally different vehicle, let's say you got into a semi-truck. 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. What do you do next? It's really quite difficult to know because you haven't developed the muscle memory to understand that system. 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. Developing intuition comes from becoming familiar with a subject. Slightly failure isn't difficult to achieve. 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. A good exercise is to find the issues that have already been solved, things that already have answers to those questions 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. 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. Those are the failures you will learn the most from because those are the ones that you never see coming. You have no idea what is causing it most likely when it first occurs. 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. Don't run to Stack Overflow. Don't go for the quick way out. Force yourself to struggle a little bit. 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. 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 net your company a larger profit in the long run. 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. 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 an next action step. You are intentionally forcing your brain to treat this situation as new stimuli. It's a brand new experience for your brain. 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. If you've seen the same problem or even if you've seen similar problems, problems that look 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 next when that situation occurs. When you see that problem for the 100 or the 300 or the 300 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. This 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 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? It is happening once you've 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 encouraged you to begin looking at failure not as simply as fast as possible, but instead to spend some time understanding what failure looks like, what causes it, and what happens around that failure. This is going to make you truly a great developer if you spend time getting familiar, getting acquainted with failure. Thank you so much for listening to Developer Tea today. We did not have a sponsor for today's episode, but we have only a few slots remaining for the later parts of this year, so if you are interested in becoming a sponsor of Developer Teaor the other great shows on the spec network, head over to spec.fm slash sponsors. Thank you so much for listening and until next time, enjoy your tea.