In today's episode, I underline the importance of failure to the learning process, and then we discuss why failure should be destigmatized and looked at more in depth. Many thanks to today's sponsor, Hired.com! Head over to Hired.com/developertea and you could receive 5 or more job offers in a given week!
In today's episode, I underline the importance of failure to the learning process, and then we discuss why failure should be destigmatized and looked at more in depth.
Many thanks to today's sponsor, Hired.com! Head over to Hired.com/developertea and you could receive 5 or more job offers in a given week!
Visit hired.com/developertea today and you could receive 5 or more job offers each week!
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell 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 developers 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 speck.com. speck.fm. But 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. And when I say failure, I mean actually arriving at a point that you did not intend to arrive at. And this is a very different perspective of failure because we can learn from this when we intentionally do something to arrive at a particular point. And when we intentionally do something to arrive at a particular point, 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 an essential step to the learning process. We learn from history because it gives us the opportunity to look back at our past. And I think that's a really important part of the learning process. 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. There's no negative outcome if our hypothesis is wrong other than maybe a hit to our head. 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. There's nothing particularly negative about a hypothesis that is disproven. 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. 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, Hired.com. On Hired.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 Hired 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 Hired.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 Hired.com, they give you a $2,000 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 DEVELOPERT. Of course, this will be in the show notes, but the code DEVELOPERT, all one word, and you can double your signing bonus if you choose a job or if you get hired through Hired.com and you use the code DEVELOPERT. 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 DEVELOPERT. 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 different reason for failure just about every time. 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 read straight through it 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. And this is a very common reason for failure. Deviance is not as common, but inattention, inadvertent 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 let's get into the point of failure. So the first one is lack of ability. And the second one is 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 inadequacy, which is when a competent individual adheres to a prescribed but faulty or incomplete process. Now, 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. And this one is very much so married to the process inadequacy. And that's because our tasks are different. So, if we're going to do a task that's 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. So you're going to have to use a tool in combination with another tool. 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 other hand. 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 prove that an idea or design will succeed. 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 left with the idea that we have to learn, where we are testing code out, where we are, especially when we're 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 for 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, and 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 example, to be able to do something that was totally reliable. So we were supposed to do something that we already know to be implemented or required for something that has a very prescribed process to be implemented. And this is entirely a different type of failure. And most specifically, it is the kind of failure that comes as a result of a lack of clarity in communication. So 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 an 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. And that you've learned from it rather than it being a negative thing. Perhaps 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. 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, you can find me on Hired.com. If you are looking for a job, you can find me on Hired.com. If you are looking for a job, Or if you know someone who is a developer or designer, please refer them to Hired.com, and use the code DEVELOPERTEA to 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 $1,337 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 Hired.com. Make sure they use the code DEVELOPERTEA, because if you're going to get a job, you're going to get they use the code developer T to double their signing bonus. Thank you so much for listening to Developer T. Check out spec.fm. And until next time, enjoy your tea.