Most of the time, even when we're succeeding the steps we take on a daily basis are failures. Failure is what we're talking about in today's episode of Developer Tea
We're going to talk about preparing for failure in today's episode and provide perspective on what it means to fail and what to look out for as opposed to avoid failure.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Sentry tells you about errors in your code before your customers have a chance to encounter them.
Not only do we tell you about them, we also give you all the details you’ll need to be able to fix them. You’ll see exactly how many users have been impacted by a bug, the stack trace, the commit that the error was released as part of, the engineer who wrote the line of code that is currently busted, and a lot more.
Give it a try for yourself at Sentry.io
If you haven't heard yet, you're probably going to fail. It's almost guaranteed the likelihood of failure is much higher than the likelihood of success. And we can gain an intuition for this when we look around at even the most successful people. If you look at the number of things that they've tried that have failed, even partial failure. Some aspect of it didn't go as planned. If we see those failures as part of their successes, then we write them off as success. But most of the time, even when we are succeeding, the steps we are taking to success are failures. And there's plenty of discussion that we can have in the philosophical realm or even in the kind of physical science realm that may help us understand why that is and come to terms with that reality. But once we've accepted the likelihood of some kind of failure and once we've accepted the fact that that failure, the characteristics of that failure are difficult to predict, then what's next? What do we do with this information? How do we prepare to fail in a way that ultimately helps us? We're going to talk about preparing for failure in today's episode and hopefully give you a new perspective on what it means to prepare for failure. My name is Jonathan Cutrell and you're listening to Developer Tea. This show exists to help developers like you find clarity, perspective, and purpose in your career. So there's a lot of things that we do in our careers that end in failure. And we need to understand that failure is not a binary concept. There is very little that we do in our lives that has an absolute label like failure or success. Instead most of what we do, especially in our career, has different trade-offs. We trade off one value for another, one incentive for one cost. So this is perhaps the first perspective that we need to adopt that there are very few true, pure failures. You've probably heard this saying, that's kind of a cheesy saying, the only true failure is giving up. And in some ways this is how we should look at this. The only way to have a pure failure is to set out to do something, to achieve some kind of value-driven goal, and then subsequently accomplish nothing. We very often think that success means meeting all of our goals, optimizing every aspect of our decisions. And often success is more like a sliding scale. Instead of thinking about it as a step-wise concept where either you are successful or you aren't kind of a dual response to this situation, you can imagine that there are different levels of success and there are different dimensions of success. Inside of every kind of failed attempt is some kind of value. For example, imagine that you try to create a company from the ground up. You spend a lot of time on it and ultimately you have to close the company down. One piece of value that you get out of closing the company down is all of the time that you were spending on the company now you have available to do something else with. You can think of this as opportunity cost. And when we think about failure in these terms, what we have to do is shift the way that we label different types of resources and values in our life. So for example, time may be seen as very cheap to the person who is spending it. And so regaining all the time after a failed project is not seen as a game for that person. If instead we relabel time as a resource, very similar to money, then we realize that we're trading that resource of time back in as an opportunity to invest it in something else. The phrase that you probably hear when talking about failure and time is fail fast. The idea is that if you continue to try to make something work that seems to be failing, the opportunity cost is very high. You spend a lot of time on something that is unlikely to succeed in the end and you experience more failure than if you were to, for example, quit early and try something different. So we know failure is complex, but how can we prepare for failure? And how do we find kind of the optimistic viewpoint when we do fail? That's what we're going to talk about. Radic, we talk about today's sponsor, Century. Century has sponsored Developer Tea for a little while now and what you can do with Century is totally relevant to today's episode. With Century, you can catch these failures that you're having early and turn them into opportunities to make your code better, not only make your code better, but avoid losing customers that otherwise you would have lost. That's because Century notifies you when the error occurs rather than you waiting on your customers to let you know when the error occurs in your software. Finding bugs in production is never easy. It's always painful because we have a lot of regret. We wish we would have caught something and we feel responsible as Developer To catch these bugs before we launch the software. But the reality is this is pretty difficult to do. And the best software developers have launched with bugs in their software. So we can't expect us to become superhuman. We're not going to become so good that we catch everything. Instead we need a new strategy and that's exactly what Century provides. How do we do Century.io to get started today? And you'll get reporting whenever you have an error that gets launched to production. You can get those alerts in pretty much any format, email or Slack, for example. And then you also get things like the stack trace, the commit, and the developer who is responsible for the code where the error is occurring. This helps you triage and fix things fast. Have it to Century.io to get started today. Thanks again to Century for sponsoring today's episode of Developer Tea. So up until this point in this episode we've tried to reframe the concept of failure and success away from this binary perspective. That success at least at a personal level has many different dimensions. We're optimizing for a complex set of factors and for almost every trade off, for almost every attempt and subsequent failure or success, there's some other kind of value. And that goes for the opposite as well. For every success there may also be some kind of failure that's attached to it, some kind of negative cost. So planning for failure starts by understanding that failure is not a simple concept and neither is success. We have to think of failure and success in much more holistic and complex terms to be able to plan for it. Time for anything is about trying to understand what may happen in the future. And while this is difficult sometimes, it's not impossible to make reasonable decisions based on what you know about, for example, similar decisions. If you look at academic research, read a white paper of some sort that's trying to describe some phenomena, what causes some phenomena. And you see correlations, these are when x happens, y tends to happen more often or less often. And here's how strong that correlation is. And then often the white paper will provide a confidence interval. This is how much do we believe that this is true? And it's not just about a gut instinct. These are things that can be described in mathematical terms. Now, this isn't something that we have to do when we're planning for failure and success in our own lives to that degree. But understanding the concept and the function of a confidence interval can help us understand how to plan for failure better. For example, let's say that you are trying to make the decision of whether you're going to buy flood insurance for your home. And the flood insurance costs some amount of money, let's say, x dollars. And the likelihood that there will be a flood is somewhat determined by previous examples of similar events. You can also imagine that a flood is fairly unlikely for someone who lives on top of a hill or on a mountain ridge. But the decision may be less clear cut if you don't live on a hill or on a mountain ridge. And so you have to make the determination based on some kind of information of whether flood insurance would be useful to you. You have to predict to some degree what is my contingency plan here. What happens if there is a flood and how much do I expect there to be a flood? Now if I want to plan for that contingency, I can do a little bit of accounting in my mind. In this case, you might multiply the risk, the likelihood of the flood happening by the amount of damage that that flood would do if it did happen. And then spread that out over the course of the term of your insurance. We don't need to get too heavy into the specifics of how you may do this kind of accounting, this kind of math. But the whole idea here is to try to understand your failures, your contingency situations that are our failures in terms of their impact. But this isn't enough. It's not enough to say what are the ways that we could fail and how bad would they affect us. We also need to understand the next step, the second order and third order steps that we would take in the face of failure and the cost or maybe the benefits of those different factors. As a theoretical example, imagine building a feature that users hate so much that they decide to send you feedback. Of course, while it's not preferable to build a feature that users hate and certainly isn't a strategy I would recommend on this show, there's also an upside. When you hear from your users and in particular when you hear feedback about something bad from your users, you get a lot of valuable information that may be harder to elicit if the feature was less hated. Maybe it wasn't very good, maybe it was neutral. But you didn't elicit the feedback and therefore it's difficult to improve the product in the face of no feedback. But sometimes there may be more complex second or third order effects that could be considered. For example, let's say you own a car and you total that car and for a short while you are without transportation. One of the second order effects that you might experience is writing with other people more often. And perhaps writing with more people more often will prove to be serendipitous. Maybe you create new relationships or strengthen the ones that you have already. Or maybe if you are close enough to work that you could walk but you previously did and because you had a car and it was convenient, maybe you will experience some positive physical effects because you're exercising more often. And once again, although you wouldn't go and total your car in order to improve your relationships or your physical health, when we create plans for failure, these are the kinds of things that we may want to think about. Always imagining both the upside of the downsides and the downsides of the upsides and add even more fuel to the complexity fire. Sometimes things are not better or worse but just different. The change may adjust your life in some way and it's not necessarily a bad thing or a good thing. It would be hard to categorize as a success or failure even if you were looking at it on its own. So when we're planning for software building and we have some kind of goal in mind and we don't hit that goal. Maybe we have a goal to launch some software by a certain time. And despite any kind of arguments we may have about deadlines being good or bad for software development, we run over that deadline. Well, what can we pull from this? What are some positive effects of this? One positive effect is that in the future we may be a little bit more conservative with our estimations. Perhaps an unexpected positive effect could be that whatever your launch date, your new launch date that went past that deadline is it could be better for the market. It could be timed better for the market. Perhaps by running over the deadline the people who are working on that software become more familiar with it. They have more time between development cycles to rest and understand the software to a deeper level. So although we can make a very good argument that launching early is a better option, there's also a good argument to be made that launching late has its own benefits. We shouldn't discount these benefits and we shouldn't fake them either. We shouldn't try to overstate our positive attitude or our optimism about a given failure. We should be able to call a failure a failure, but we also need to understand that in order to succeed in the future we have to find ways of optimizing our situation in a failure or in a success. Thank you so much for listening to today's episode. Thank you again to Century for sponsoring today's episode. Head over to century.io to get started catching bugs before your users do today. Many of these episodes wouldn't be possible without spec.fm. Spek was created for designers and developers who are looking to level up in their careers. If you like the content on Developer Tea, you're going to love the other content on the spec network. Head over to spec.fm to find other shows that are built just for you. Thank you again to today's producer Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.