Most of the developers listening to the show right now are mostly responsible for their own learning efforts. You're responsible for your own growth. You're responsible for your improvement, for understanding what areas you're going to get better in. The vast majority of our careers are about improvement. Very often in podcasts or blog posts, you'll hear stories of how to be great, how to act like a superstar programmer. In this episode, I want to talk to you about how to become better, improvement as a fundamental practice. We're going to use this episode and most likely more episodes in the future talking about the process of improvement. My name is Jonathan Cutrell, and you're listening to Developer Tea and my goal on this show is to help driven developers find clarity, perspective, and purpose in their careers. It's no secret, and if you've listened to this show before, you've heard me say it probably a hundred times if not more, that failure is a fundamental part of improvement. If you can't fail and do so in a relatively safe way, in other words, failing in a way that doesn't have dire consequences for you or for your company that they might pass on to you, if you can't fail in these ways, then it's difficult for you to learn. You have to create an environment, perhaps even outside of your day job, where failure is, in fact, acceptable. This theme of decoupling your failures from your fears will recur throughout our conversations about improvement because it is fundamentally necessary for you to fail. In the last episode of Developer Tea, we talked about the idea of progressive overload of kind of pushing yourself to that failure point over and over in each time trying to go one step further. Whatever that means and whatever context you are improving in, progressive overload and failure are fundamentally necessary for growth, for improvement. This concept is not novel. This is the basis of pretty much all science related to improvement. What we need to do is study how we look at failure and more specifically how much of our failure we look at. It's easy to look at the failure directly, the thing that went wrong, the action that you took, that next time you hope not to take. And it's easy to believe that awareness of that particular action that you took that hopefully you won't take next time or maybe it's an inaction, something that you didn't do that you hope you will do next time. It's easy to believe that knowing about it is enough. That understanding that you didn't do something that you should have or you did do something that you shouldn't have, that that is enough for you to change it. But we know that this isn't true. We know that our behaviors as humans are not that simple. We try to do things and then we fail. We try to build good habits. We try to improve and we often fail. We don't hold up to our resolutions. We don't hit our goals. We don't meet our own expectations quite often. Now while this simple five minute or so podcast is not going to cover all of the reasons that we fail as humans, we are going to talk about something that is too often missed during that process of evaluation and even after evaluation, the adjustments that we make on the next iteration. Before we talk about that, I want to talk about today's sponsor, Linode. With Linode, you can deploy a server in the Linode cloud in just a few minutes. Linode offers cloud computing plans for every workload from simple web hosting to CPU intensive needs like video encoding or even machine learning. Linode offers a balance of power and price for virtually every type of customer. And if you are a new customer, you're going to get $20 worth of credit that you can use on any of their plans or services. You can deploy and maintain your infrastructure simply and cost effectively. Linode has a manager and API and a CLI and all these make it easier for you to provision, secure, monitor and back up your cloud. And coming soon to Linode, Object Storage, Linode Kubernetes Engine and GPU processors. So go get started with Linode today. If you're a new customer, you can get that $20 worth of credit by heading over to Linode.com slash Developer Tea and use the code Developer Tea2019. That's Developer Tea 2019 to get that $20 worth of credit. Thanks again to Linode for sponsoring this episode of Developer Tea. I want you to think back to the last time that you had a very clear failure. It doesn't have to be a big failure. It can be something as simple as a typo. And think about what you did in that moment. Most likely you corrected your typo. Most likely you changed the thing that you had done wrong to be better in some way. Maybe you responded to a code review by updating your code. Of course there's a lot of ways that you could have remediated whatever was wrong. And this is where most people unfortunately stop. We think about failure as a bug in the system that needs to be fixed. Something that shouldn't be there. Something that is an anomaly. But here's the shift that I want you to make. I want you to start thinking about failure as something that is produced by your environment, your behaviors, the behaviors of others. The failure is most likely not simply random. There's likely some random components to it. But ultimately if you're going to improve, you need to be able to look at failure instead of an anomaly that's unlikely to happen again as an opportunity to change your behaviors, change your environment or encourage others to change their behaviors so the same failure is not reproduced. This is the fundamental shift and it requires a different way of thinking about remediation. So in the moment that you uncover the failure, of course it's likely that the most important thing you can do is remediate it. Consider this the triage of that particular failure. But once that failure has passed and once you've remediated it, it's important to also revisit the period before the failure occurred. Understand the environment that the failure came from. Understand the behaviors that may have contributed to that failure. It's really important that you don't do this purely from a single perspective. You yourself can put on the lens of other people's perspectives and you can often ask other people for their input. This can help you reduce your blind spots and hopefully account for some of the biases that you may have. So the critical factor here is to not stop at remediation. Don't stop when you've fixed the bug, go one step further. Try to build a case for how the bug was produced in the first place and evaluate that system. Find ways of affecting that system. This is not unrelated to our discussion on the five Ys and various types of root cause analysis. But it takes a mental shift in thinking about problems as these anomalous kind of floating issues that may happen at any time to any person and instead reframing those as statistically likely to occur again if the system that produced them is still in place if it's unchanged. When you make this shift, the way you think about failure is different. You think about failure as an opportunity to shift your systems, not an opportunity to remediate behavior, but instead as an opportunity to reflect on the systems that are in place that created those behaviors. Thank you so much for listening to today's episode of Developer Tea. I hope that you can take this and apply it to your individual contributor work as well as your management work, your leadership work. Thank you again to today's sponsor, Linode. You can get started with Linode and $20 worth of credit for new customers by heading over to linode.com slash Developer Tea. Use the code Developer Tea2019 and check out that's Developer Tea.2019. Thank you so much for listening to today's episode. If you enjoyed this episode, subscribe and whatever podcasting app you're currently using. Thank you to today's producer, Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.