Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking to you about destigmatizing failure and using it as a tool for learning. We talk about learning on this podcast all the time and if you are a regular listener, you are used to this phrase that it is a very important thing for Developer To be aware of. We should be experts at learning. We should be experts at the learning process. Now if you have any questions about this, I'm going to put a link in the show notes to an episode that I did that was dedicated to justifying the need and the importance of constant learning for developers especially. So look in the show notes for those which of course you can find at spec.fm. But learning, the learning process is something that we don't look at very often. One of the most important parts of the learning process is failure. When I say failure, I mean actually arriving at a point that you did not intend to arrive at. This is a very different perspective of failure because we can learn from this. Then we intentionally do something to arrive at a particular end point. And instead we arrive at a different end point. That is something that doesn't feel like failure. In fact, it feels like you just experienced something unexpected. And I think the reason for this is because we've stigmatized the word failure and we've attached a lot of negativity to it that we shouldn't attach to it. And I guess the reason for this is because failure quite often ends up translating into cost or perhaps it translates into undesirable outcomes. But the truth is when we are engaging in the learning process, we should welcome failure because it is fundamentally important to the learning process. Failure is a essential step to the learning process. We learn from history because it gives us the opportunity to look back at our past failures and to be able to look at what led to those failures. Instead of engaging in prospective prediction, instead of using our gut or using some kind of flawed model to predict the future, we create a model out of what we've done in the past. We create a model out of whatever inputs we came up with. And the measured output of those inputs, this is fundamentally important to science. We go through the scientific process of coming up with a hypothesis. And then if our hypothesis is true, then those findings have been validated or those assumptions have been validated to some level. If the hypothesis is false, then we have learned something new that we didn't know before. Our hypothesis, there's no negative outcome if our hypothesis is wrong other than maybe a hit to our pride. And so in this way, experimentation treats hypothesis and failure as ways of learning. It treats it as a way of measuring what we know and increasing our ability to craft a model and to predict in the future. And so there's nothing particularly negative about a hypothesis that is disproven. And the truth is, we can use this same concept to learn as developers and really in any other part of our lives if we view failure as a positive thing or at least as a step in the learning process. But we've got another problem when we talk about failure. And particularly we have another problem with the language that we use to talk about failure. We talk about failure as a one dimensional concept. Either we have failed or we have not. But as a Harvard Business Review article says from back in 2011, not all failures are created equal. And this is really why we've stigmatized failure because we want to place blame on someone. But not all failures are created equal. In other words, sometimes a failure doesn't necessarily have blame to be placed. So in just a minute, I'm going to talk about the spectrum between blameworthiness and praiseworthiness that that particular Harvard Business Review article outlines. But first, I want to talk about today's sponsor, hire.com. On hire.com developers and designers can get up to five or more job offers in a given week. These job offers are at major tech companies all around the world. And if you sign up on hire, and you actually get a job through hired, they provide a signing bonus. It's really interesting because these positions provide salary and equity a lot of the time. And they also have part time and full time jobs. So it's not just one type of job. It's not just full time development jobs. There are also things like part time designer jobs on hire.com. So if you are exploring options, maybe you want to try a new tech stack or maybe you want to relocate hired is a great option for you. So the bonus that I talked about, if you get a job through hire.com, they give you a $2000 signing bonus on the spot. But hired will double your signing bonus that is $4,000 of a signing bonus. If you use the code Developer Tea, of course, this will be in the show notes, but the code Developer Tea, all one word, and you can double your signing bonus if you choose a job or if you get hired through hire.com and you use the code Developer Tea, a couple of other really important facts hired is free for you. And you can see the offers before you ever talk to the company. So there's no awkward conversations about why you don't want to work at a place or why you need more money or something like that hired allows you to see the offers before you ever talk to the company. So if you're looking for a job or you know someone who is go and check out hired.com, make sure you don't forget the promo code Developer Tea. So we've been talking about failure and the importance of failure, but also about destigmatizing failure and looking at the fact that not all failures are created equal. In other words, there's a different reason for failure just about every time. Now there is a spectrum of reasons for failure that this Harvard Business Review article, which of course will be in the show notes, by the way, this article outlines the spectrum of reasons for failure. And I'm just going to reach straight through it. Just just for those of you who are interested, the most blameworthy reason for failure is deviance, which is when an individual chooses to violate a prescribed process or practice. So this is like if somebody was to literally just defy what was supposed to happen and go against the terms of their particular experiment or their job or whatever it is that they're trying to not fail at, right? The next blameworthy version of a failure is inattention. And this is pretty much when somebody isn't paying attention, right? An individual inadvertently deviates from the specifications. They do something wrong accidentally. This is a very common reason for failure. This is not as common, but inattention inadvertently deviation. That is pretty common. The next one is lack of ability. An individual doesn't have the skills, conditions, or training to execute a job. Now this one is also pretty common in development. And that's because people don't ask what is necessary for the job or maybe they don't know what is necessary for the job. For developers, this one's a little bit more excusable than this particular scale is saying that it is third on a list of nine, closer to blameworthy, but lack of ability is a very common problem. And it may be that you are not aware of what you need to be able to do to execute a particular job. Now as we go along this scale, we're going to assume that you have surpassed the previous points on the scale. In other words, at this point, you are not being defiant, you are not being inattentive, and you do not have a lack of ability, but the next most blameworthy reason for failure is process and adequacy. A competent individual adheres to a prescribed but faulty or incomplete process. This is also a very common situation in development. And part of the reason that this is true is because so much of what we do is brand new work. It's creating something that has never existed before. Now, there are certainly a lot of processes that have been tried and true. They're over and over the same things are true for one project to the next, but there's also quite a bit of process that hasn't been prescribed yet because we haven't determined what the process is for a particular application. So next on the scale, assuming that your process is adequate, is task challenge. In other words, an individual faces a task that is too difficult to be executed reliably every time. This one is very much so married to the process in adequacy. That's because our tasks are different so often. It may be very difficult to accomplish a particular task, especially if it's the first time that you are trying to accomplish that particular task. The next one on the scale is called process complexity, a process composed of many elements breaks down when it encounters novel interactions. So how does this apply to the world of development? Well, perhaps you've never used a tool in combination with another tool and you realize that they are incompatible and that creates a timeline problem or perhaps it creates unexpected bugs later on down the road. This would be process complexity, it would also be just simply complexity of the thing that you're creating. The next reason for failure is uncertainty. A lack of clarity about future events causes people to take seemingly reasonable actions that produce undesired results. And by the way, we're well on the side of praiseworthy rather than blameworthy on the spectrum. So uncertainty, the lack of clarity about future events causes people to take seemingly reasonable actions that produce undesired results. And this is very true about speculative work. This is true about most investing. You do as much research as you can and you take care of all of the other steps and you try to avoid all of the blameworthy reasons for failure. And unfortunately, you just didn't know what was going to happen in the future. You didn't have perfect clarity. You couldn't predict future events. And so what you thought was the right decision turns out to be the wrong decision. The next reason is called hypothesis testing. Now, this is not to be confused with what we talked about earlier, but hypothesis testing is an experiment conducted to prove that an idea or design will succeed fails. So this is purely experimental. And the next one is also experimental. But this idea of hypothesis testing is an experiment. It's fundamentally designed with failure as an option and failure will feed back into the process and presumably it will allow you to further refine your design in places that you don't yet know it needs to be refined. And finally on the list is exploratory testing. And this is when an experiment conducted to expand knowledge and investigate a possibility leads to an undesired result. And the idea here is that because it is completely uncharted territory and because the intention is to expand knowledge and investigate a possibility, this leads to an undesired result or perhaps a better way of putting it is it leads to a result that was not expected or predicted and wasn't necessarily hoped for. This is where we are learning where we are testing code out where we are especially when we are learning new frameworks when we are building side projects. This is where the most praiseworthy types of failure occur. So there's a very big difference in that first reason for failure, which was deviance. In other words, complete lack of attention and complete intentional defiance for what you should be doing versus exploratory testing. If you are failing because you are intending to learn. If you are failing because you are conducting an experiment or the sake of expanding your knowledge as the Harvard Business Review article puts it, well, then you are failing for a good reason. That is the positive type of failure. You shouldn't be blamed for this, right? You should talk to your managers if they are blaming you for this and determine what their intention was if you are going through the process of learning. So often we fall somewhere on the spectrum when we were supposed to do something that was totally reliable. Instead, we did something that had a lot of inherent uncertainty. We made a decision to use a framework that may be new or perhaps we were trying to engage in the learning process when our job description or that particular task or that particular project required for something that we already know to be implemented or required for something that has a very prescribed process to be implemented. This is entirely a different type of failure. Most specifically, it is the kind of failure that comes as a result of a lack of clarity in communication. What you need to do as a developer is talk to whoever is managing the project, whoever is giving you the work to do and determine what kind of work this is and how much learning versus how much prescribed process they want you to engage in. Now I would recommend that you talk to them about the importance of learning, have them listen to this podcast, have them do their own research and determine the importance of learning for themselves before you engage in this conversation so that you can discuss when and where to implement learning as a part of your regular processes as a part of your regular development cycles because we can't do this on the side. We can't make learning only on the side thing. We must be learning in our actual work because it's the most appropriate time to learn adequately, but determine what the tolerance for failure is on that particular project. It may be that particular project has a large enough budget or perhaps resources are simply available for you to engage in learning and it may be that the project is very tight. It has a very small budget perhaps or maybe it has a very low tolerance for failure because the timeline is important or something like this. These are all management problems, but if you choose to try to learn, then you have to have a higher tolerance for failure than if you were to engage in something that you already know very well that your intention isn't to learn, but rather your intention is to simply produce some kind of output that accomplishes a really specific goal. I highly recommend that you take a deeper look at the Harvard Business Review article that I'm going to include in the show notes as I think it is quite relevant to this discussion. I'd love for you to reach out to me on Twitter or via email. You can reach me on Twitter at at Developer Teaor at at Jake Trell and you can email me at Developer Tea at gmail.com to continue this discussion. I'd love to hear about times that you have failed and that you've learned from it rather than it being a negative thing. You failed and you ended up fixing something because that failure pointed out whatever it was that ended up being fixed. Thank you so much for listening to this show. I very much appreciate your time. I hope you come back next time and if you are enjoying Developer Tea, make sure you subscribe and the biggest way that you can help the show out. Believe it or not, I don't want your money. What I would prefer for you to do is to leave a review on iTunes. iTunes reviews help podcasts out the most. So if you like my show and if you like other podcasts, make sure you go and leave reviews and they are a huge help to the show. Thank you so much for listening to Developer Tea. The show notes, you can find them on spec.fm. Of course, our wonderful sponsor, hired.com. If you are looking for a job, particularly if you are a developer or if you are a designer or if you know someone who is a developer designer, please refer them to hire.com and use the code Developer Teato double your signing bonus. Now, here's another little trick for you. If you are the person that refers them, you can actually get a $137 bonus just for referring someone. If they end up getting the job, you get a bonus as well. So make sure you refer your friends to hire.com. Make sure they use the code Developer Teato double their signing bonus. Thank you so much for listening to Developer Tea. Check out spec.fm. And until next time, enjoy your tea.