Failure Is Good!

August 01, 2019

Kel and Joshua talk about why we should be seeking failure, not seeing it as something to avoid at all costs. They reflect on how failure helps us grow as developers. They also touch on last week’s subject of safety and how closely tied the two are.

Be sure to check out our new Slack community to meet others who are facing the same things you are and share your journeys!

• 00:00 Joshua

  Hey folks, welcome to Getting Apps Done, a mostly non technical podcast about building software.

• 00:09 Joshua

  Today Kel and I wanted to talk about failure of all things to talk about because you know, everybody wants to talk about failure. Particularly your own failures. It's, there's a stigma around the concept of failing because failing is negative. It's a bad thing.

• 00:27 Joshua

  But what we actually want to talk about is the fact that failing isn't bad, it's not negative, it's just part of being a software developer or being human in general because we all mess up at least, you know, regularly, often all the time constantly. And it's part of just how we get through life. It's how we learn and grow.

• 00:47 Kel

  Good start. So yeah. Um.....

• 00:55 Joshua

  We have failed...

• 00:57 Kel

  Yeah, we have failed right off of the bat, which is a great thing. So failure, failure is definitely a, it's a type of feedback, right? Like you, you do a thing, it succeeds, it fails or it's, you know, inconclusive is kind of the, the three main options. Um, so in programming we see failure constantly cause our app doesn't compile. It throws an error message. We've even stop kinda like even thinking of it as a failure after a while, especially if you've been programming for a while. And I know I've mentioned before cause I was so surprised the first time somebody told me that they got, you know, anxious and scared when those types of failures happened and it's like, oh, all right. Yeah, that is uh, something that went wrong. But you have to just get used to that. That's just part of the feedback of being a programmer, being a, like you said, I person, you know, failure is a thing that will happen. You will try a thing and it will fail.

• 01:45 Joshua

  Well, even if you're not just trying it and not do, you're gonna forget things. Today I spent probably 10 minutes trying to figure out why a method wouldn't read that work and react only to find that I forgot to bind the damn thing. It was stupid, but I screwed up. It happens. It happens all the time. And for me it wasn't a big deal. It wasn't working. So I kept trying to look at things, I tweaked things, I looked around, I did some troubleshooting, figured out what it was and it just, that was normal. I didn't even think about it until afterward. And I thought, you know, we're talking about failure tonight. And actually I kind of bombed on that one. I was stupid. But it's normal. I mean,

• 02:21 Kel

  yeah, I do that all the time. I write a function out and then I wonder why it doesn't work and id bug it and then, oh, I never called this. Oh oops. And it's a lot. There's a lot in, especially in the programming world, there's a lot of things that you can do to like make the odds of failure lower. You know, we have automated testing, we have IDEs that throw messages, you know, quick and fast, fail fast. Is that the other term you hear a lot, right? Like the faster you fail, the quicker you can respond to that feedback and correct. And like this example where I had a function that I never, you know, I completely forgot to call. Well, some compilers will tell you that. They'll tell you that your function was never called and you know this, this thing has never been used and that might be a red flag for you. So yeah, being able to fail quickly is always helpful as well.

• 03:07 Joshua

  This is another reason why I hate whiteboard tests because I love my IDE. It tells me all the stupid things I do all the time because I'm telling you, it doesn't matter how long I've been programming, I still do stupid things and I mess things up and I fail.

• 03:18 Joshua

  We're not always talking.... When you're talking about failure, you're not always talking big things where you really, really, really bombed and you know the business lost money or anything like that. We fell all the time, but the difference isn't that big. I mean, yes, you're going to bomb on some things and things are going to go really, really wrong. It's just going to happen. And the only real difference is some people will learn from that and adjust and iterate and change.

• 03:43 Joshua

  We keep coming back to this iterating because it's huge. It's not just development thing. It's, well, no, it is a development thing. It's about developing your skill as a developer. It's about developing your human being that you are, because we all are constantly changing and adjusting and adapting to the things around us...

• 04:01 Kel

  Iterating is... I actually have this opinion that like software developments, like main good thing that they have added to the world is giving us like terminology to describe really simple concepts like iterating a very basic concept of respond to your feedback, make a change because of it. And we're very iterative and failures are great, you know, is a very obvious form of Oh I need to change something. I need to correct for that.

• 04:23 Joshua

  Yeah. And what's that saying about successful people that they all have failed a thousand times or something stupid like that, which is true. First off, we've all failed so many times we can't count them.

• 04:36 Kel

  But then you forget about the failures after awhile

• 04:38 Joshua

  And that's what history does as well. When you look at the big names like jobs, I mean everybody looks at him as though his career was the shining example of wonderful and he was this visionary person. He screwed up so many times. Just like everybody else and sometimes he learned from those and he adjusted and pivoted and things went well. Sometimes they just didn't and they got "disappeared" from history and ..

• 05:04 Kel

  We talked about in the last episode a lot about safety. And these are very related topics. Um, probably kind of obviously, but a lot of the things like where we say where your id catches you and you fail faster, a lot of that is safety. Like when you are failing, you need to have kind of a plan for it need to be prepared for failure. Is that the preference? Because what you want it to be is a safe thing to happen of you can do a test and it doesn't really matter if it succeeds or fails. What are, what matters is that you get that feedback and that you can correct or keep moving. And so to do that quickly and well you have to do it safely, which might require being prepared or you know, in terms of you're talking business, you know, business failures where you might actually cost loads of money. What can you do to mitigate that before it fails? What can you do to create safety nets for those types of failures

• 05:53 Joshua

  Or allow for it? Assume things are gonna fail and have backup money. Just case it's the reason and we mentioned in the last episode, some people are able to take more risks because they have that safety net of money backing them up. If you've got six months in the bank, you feel a little bit more okay with doing things that might lose you. This current contract if you've got two weeks in the bank, probably not so much.

• 06:17 Kel

  Yeah, exactly. It would, and you can do some things more directly so you have these types of failures of, especially back when I was deploying software a lot, I'm having a backout plans, having stage deployments, having ways that you can like cut your losses. If something starts to go wrong, like you pushed a 10 machines first, you don't push to all 10,000 you, you push to 10 and you wait a little bit and you make sure everything's fine. You wait for some feedback and then you push some more and you're like, you stage these things kind of strategically. So if something goes wrong it doesn't all go wrong and the failure doesn't let you know snowball and the,

• 06:55 Joshua

  You say "you do." What you should say is "you should, "because I'm fairly certain there are times that I've pushed all 10,000 and things did go completely wrong...

• 07:03 Kel

  I remember that. And I am more paranoid than that. Things go wrong. A lot around me are go, go south, go implosions and fire. Yeah. So you know, healthy paranoia I guess in some cases you react to of the feedback you learn. I learned very quickly that when things went really poorly, I should probably not do that again. And that is, that's the other half of it. You know, we, you know, fast feedback, say feedback and then what do you do when that, those two things aren't easy and your only real option is slow and steady basically. You know, you can't go high speed without a lot of risk. And so you try to mitigate that risk as best as you can, where you can still fail, where you can still take that chance. In fact, let failure happen and you know, accidentally deploy a patch poorly to a thousand machines

• 07:51 Joshua

  Or 10,000. It's okay.

• 07:54 Kel

  I think there were like 16,000 dish but only like 11,000 dovish were on at any time. So you could only break most of them, not quite all of them.

• 08:05 Joshua

  Um, so yes, we failed to and have done so for many, many years and will continue to do so for another many, many years. Absolutely. I, and I kind of look forward to it because those are the things that you learned from and sometimes you don't have a backup plan. Sometimes you don't have all these other things around it, but it's what you do with it when it does happen.

• 08:26 Kel

  I was gonna say, that's like the other half of this topic I guess for me is what happens when something fails? What happens when it is your fault that it just failed and... Fault isn't even quite the right term there, but the you are responsible for actions that cause harm or cause problems or whatever. You know it is something that you need to be able to handle. So you push to 10,000 machines and it all goes south. You're kind of responsible for that. Like that is your problem, that is something you did and you should probably take responsibility that and help fix it, help mitigate, you know correct whatever the problem is and taking that as a default like response to failure is also another way that helps you learn from those faster cause you will be, because you know you're responsible for whatever happens, you will be a little bit more prepared for "Oh crap, what could go wrong?" I should be ready for those because I'm going to be responsible for it regardless. I would rather be prepared for that failure. It really does kind of help like kind of really push into your head what the actual risks of things are. When you realize that you're responsible for those actions that could go bad.

• 09:29 Joshua

  Which is a big thing. I mean it's not just development. I stick my foot in it constantly all the time and luckily I've got people like Kel to remind me that yes, I'm being an idiot. And part of learning how to deal with failure is being able to accept that criticism and understand what it is that it's something in me that I might need to change something.

• 09:56 Kel

  Yeah, I dunno. I feel like a lot of those things just kind of happen naturally as you like. If you accept responsibility for messing up regularly, you generally quickly learn not to do that. And most people like iterate and learn from those mistakes of, oh no, I just caused myself three weeks of meetings. I don't want to do that again. I will. I will be a little more cautious next time. I will learn where I need safety nets and where I don't, you know, it's, it's very much kind of a statistical gambling thing when you talk about risk and value like it, it's kind of a numbers game and it takes a while to really get a feel for those numbers cause they're not quite as obvious as you know, roulette.

• 10:34 Kel

  But yeah, being able to take on that responsibility, fix those things and you will learn quickly because it hurts when you get hauled into a million meetings to explain to people that no you can't shut down the server room after you patch them. And then there's all these calls and screaming and,

• 10:49 Joshua

  But you can, there's that giant red button you just can't ever turn them back on ... ever.

• 10:53 Kel

  Well most of them came back on the, they described to the server room is making a *DOOOOOVE* sound like when, when they all patched and shut themselves off and then like 1 out of 10 ish didn't reboot due to power spikes and hard drive failures.

• 11:07 Joshua

  1 out of 10 yeah. It's all about the odds. The odds,

• 11:13 Kel

  it really obvious to me when we were, when we were working on scales was like 16,000 computers. It really helped me to visualize and really internalize statistics of failures because machines just broke occasionally hard drives, failed power, supplies failed, things went wrong for apparently no reason, no even fault of my own. It was just the risk, you know, roll of the fates kind of thing and that really did kind of help kinda internalize the, this is kind of like gambling and I need to be prepared for when it goes south, like it's not going to be a fate, it's not luck, it's there. It's kind of a numbers game and it's helpful to actually know what those risks and what the actual like risks are.

• 11:53 Joshua

  But even if you don't, it's just good to understand that it is a numbers game. You're going to fail, things are going to go wrong and you just have to accept that that's part of the life. And as long as you are accepting responsibility for the things that you are responsible for and you are adjusting your behavior or the way you do things and you're learning from it and you're growing and becoming a better developer, a better person, then there's absolutely nothing wrong with that then in fact, I wouldn't... It's not even that there's nothing wrong with it. That is normal. That's what it should be. If it's not like that, there's something wrong.

• 12:25 Kel

  Exactly. And we talked about like safety in the last episode and we know successful people take a lot of risks and that's kind of a, a statement in a way of like, yeah, risks are a thing you should be able to do. Like a risk will result into faster, quicker forward progress. The downside is there might be consequences to those risks. And how do you mitigate those was, you know, the entire last topic of the last episode. Um, and that is kind of an important thing, right? Like we're, we're talking about safety and the more you can add, the faster you can move and the faster you can fail. So failure is a great thing. It's just being prepared for that failure, which is where all the complexity comes from. And there is, like you said, the very beginning of that, that that stigma against failure and people will say awful things about failure. Like oh no, they messed up. That's awful. And that's not helpful.

• 13:12 Joshua

  Yeah, absolutely. And I don't try to trivialize life that often, but I quite often relate it to games when I was a kid, I remember playing games. I remember the first Diablo always pushing to the next level even though I wasn't ready for it because that was the quickest way to get to the next level when it came down to it. The quickest way to improve yourself, to move forward to whatever, the next step in life or career or whatever is for you is to put yourself outside of your current comfort zone, to make it harder on yourself, to put yourself in a position where you can fail. Because if you're not doing that, you're not moving.

• 13:50 Kel

  Absolutely. Video games is a great example too, cause that's a, a lot of where I learned a lot of my like basic strategies in life is from video games and going, oh, I need to cut my losses. This, this base has gone, the bots have over run it, it's gone. It's time to go move on and like, Ooh, I should take this risk. This is an okay risk if I don't take this risk, there's no possibility of me winning even though there's also a good possibility I'm going to fail miserably. And games though are inherently safe. Like they are. I'm not going to be overrun by bots in real reality quite yet anyway. Um, you know, no gray goo yet. Uh, but, but yeah, so again, back to the safety of move fast but also be prepared for that failure. Don't try to take, you know, there are some risks that are almost impossible to avoid, you know, consequences of those failures. But try to mitigate those as best as you can so you can keep moving forward and you can like not worry about those risks and worry about the failures, but just learn from them.

• 14:49 Joshua

  Yeah. So moral of the story go play more video games. It worked for us...

• 14:56 Kel

  I mean... sure... Oh that's... Not everything we have done works for everyone. We definitely have a bit of a like survivor bias in terms of risks we have taken that worked out that did not necessarily should have worked out. We learned from them. And I mean that's Kinda like childhood, right? Like that's 90% of the, the childhood thing of watching kids do stupid things and think, oh, that's not as safe as you think it is. And on the fifth time when you fall and you know, sprain an ankle, break a leg, you'll, you'll, it'll internalize that.

• 15:30 Joshua

  Yeah. I'm not looking forward to my boys being teenagers. I don't know how I survived being a teenager. And I know this is just gonna go, it's gonna be payback for all those stupid, stupid things I did. I'm now going to watch them do them. And I've got three of them. So it's three times all the stupid stuff I did. And so yeah, they're going to fail a lot and a, I'm going to be absolutely terrified the whole time, but they're going to learn a lot as well and hopefully they'll become better people for it.

• 16:00 Kel

  I did want to loop back around to when we talk about responsibility, I did want to loop it back around to like shared responsibility for like what happens when it's a team failure and it's kind of a shared thing that has gone wrong. Like fault is not really that important. Like you can break something and it not be your fault. Like you can do something and it be outside of your control. Everything goes south, everything has failed and it wasn't really anything anyone could blame you for. Like it wasn't anything that you can learn from. It was just a failure that happened. The only real failure was you misjudged the odds or maybe you judged them well...

• 16:32 Kel

  Um, but it's still your responsibility. But like in a team scenario, let's say there's a bunch of people that share that responsibility and that's a great thing like shared responsibility doesn't lower your own but it does help make it easier to deal with it. If there's 10 people that are responsible for your entire server room being down, then there's 10 people who can help fix it as opposed to it just being you and then it's just you and you've like prodding people on and hoping for the best but a shared responsibility. I guess the point I'm trying to go there is the shared responsibility doesn't lower your own responsibility but it does make it a lot easier to fix whatever the problem is cause there's more of you.

• 17:10 Joshua

  Yeah, it augments that... it's also going to decrease the likelihood of a failure even if you haven't planned as well as you shouldn't have just by having 10 people there with 10 different points of view, you gain a lot of immediate feedback before you push the button and screw things up.

• 17:28 Kel

  Exactly. I like when you do these things prior, there'll be have all the experiences of all the failures they've gotten into and the obstacles they've encountered and the things that worked and didn't work. And they will highlight those things quickly. And there's of course, the downside of that. If you ever been in a meeting where there's a possible risk of everyone's now a committee and trying to mitigate it down to the most boring solution possible, um, we're talking about failure at this episode. Not really risk, but that's a good example of one of those things where you should actually probably try to figure out what like the probabilities are and then have people like vote on their risk, like acceptable risk levels.

• 18:03 Joshua

  But that's part of why failure is okay. Because it teaches us about risk and without those failures, we aren't learning those things. We're not, again, we're not growing, we're not becoming better at what we do. We're just sitting exactly where we are. And I don't know about you, but I want to get better what I do.

• 18:19 Kel

  Yeah, exactly. I want to grow, learn new things, experience new things. And a lot of those things require risk and some consequence that you hope you can mitigate and you can control and you know, not break a leg.

• 18:30 Joshua

  But if not, you know what? Some of the best lessons I've learned were from breaking things. So...

• 18:37 Joshua

  I've broken a lot of bones over the years.

• 18:40 Kel

  Move fast, try not to break things. How about that?

• 18:43 Joshua

  Yeah. Learn from it if you do.

• 18:46 Kel

  Yeah, definitely learned from things when you do fail. And I wish I could think of some like more entertaining failure stories that we have done. Like I feel like all the good ones were somebody else's fault, which is probably a selective memory problem.

• 19:02 Joshua

  Well, that is actually a very good point... Because a lot of people can't remember their own failures in a lot of ways. They remember the lessons that they learned from them. Exactly. Or certain things that I know I do and I know there's a reason for it, but I'm not really certain what it is because you know, rose tinted glasses and everything else. I remember all those things as being wonderful. I remember those late nights, but I don't remember why we had late nights fixing things.

• 19:27 Kel

  Yeah, exactly. There's a lot of things where I can, sometimes when I do something I'll go, oh I remember why I did that. I did that because that one time I failed. But most of the time, yeah, all I remember are the lessons learned from that failure and it's a little, it's kinda difficult to like remember those times I really screwed up cause I probably don't want to remember them.

• 19:46 Joshua

  But that's also a reinforcing drive behind the reason why we see it as negative because nobody remembers their own failures. So when somebody else fails, it feels bad. It's not good. They shouldn't have failed. I never fail. Of course, I never fail. I'm awesome. But equally with ourselves, we see it as bad because I've never failed before. How can I fail now? But you just, you aren't remembering.

• 20:09 Kel

  Yeah. A lot of that does stem from ignorance. You see, like when people mess up and it's because they didn't know to do something well that like the definition of ignorance, it's something they did not know. They could not know. They haven't known it yet. Like they need to learn it still. Um, and we, we really are kind of mean about that like, and, and society, just, just that amount of like that's, it's such a negative thing to be ignorant of anything and that's not really a great way of going about things.

• 20:35 Kel

  Especially as our techforce actually starts aging. Like we started kind of young, we're newish and now we're getting kind of like senior-y type folks and I see a lot of new people making the same mistakes I've made a thousand times before and have long since learned from, but that everybody's gotta learn it eventually. Like that's just part of the thing too. Like you also have to learn to accept people's failures and that they're not going to know everything immediately, that they're going to make mistakes, that they're going to have to learn stuff, especially if they're new to this career.

• 21:03 Joshua

  Yeah. But it's like you're absolutely right. It's very easy to slip into that default reaction. Where the hell did you do that? You should know better. Wait a minute. Like how would they know better? No, you shouldn't know better. I'm sorry.

• 21:15 Kel

  Exactly. And being mindful of that, and you know, this might be more of a message to ourselves, but being mindful to junior folks is that yeah, there's loads of things they're not going to know. And this is a lot more obvious when you know someone's a child and you're 10 they don't know anything yet, but adults don't know everything either. There's loads of things. I don't know. I just happened to be in my little, you know, technical space where I'm pretty confident in a lot of things. But you move me out of this. I don't know anything.

• 21:41 Joshua

  Yeah, absolutely. It's not just the seniors who need to know this. Seniors who are not seniors, senior developers. If you are a newer developer and a senior developers saying, well, why did you do this? Why didn't you know this? And you honestly had no reason to know. It pointed out to them. Just say, I've never done this before. I've never been exposed to this before. Why would I know this? If somebody were to tell me that I might immediately react for things but eventually it's going to kick in. Absolutely right. There was no reason they should have known that. I know that because I've been developing software for a long, long, long time. They haven't been unfair of me.

• 22:17 Kel

  And that's really something good we needed to push. Just like in general as a society of ignorance is kind of an expected thing. Like you should strive to not be that, but at the same time not stigmatizing or not shame people for not knowing something because how can they know what they don't know?

• 22:34 Kel

  You know? You generally don't want people who are like willfully ignorant. The ones who ignore the book and ignore all the advice and ignore all of the things that they could have known. But yeah, you can't know everything.

• 22:46 Joshua

  No, and as a society and as people in business, and the best thing for us is to be reminded of it, to talk about it, to be honest with each other and just say, I don't know that I've never been exposed to that because that's how we learn that the fact that everybody's terrified of failing means that they don't ever tell anybody I screwed this up because I didn't know this. So then nobody knows that they didn't know and then it just goes round in circles and everybody's angry about everything and nobody's winning here. Just be honest about what you know, what you don't know and what you screwed up and what you didn't screw up.

• 23:19 Kel

  I've noticed it's really common for people to be afraid to show their ignorance. I, I kinda really kind of head long ran into this when talking to people about doing interviewing.

• 23:27 Joshua

  Guilty!

• 23:28 Kel

  They'll be, yeah, there'll be talking about what do I do if I don't know the answer or what do I do if they ask a question where I don't know some of the words and it's kind of like tell them. I mean they might react poorly, but that's really not your fault. That's totally on them. It's like you can't know everything.

• 23:46 Joshua

  In fact, that's a red flag right there.. Run! Run!

• 23:46 Kel

  Yeah, it really is a red flag. I mean, I don't know, I'd say run just because it's such a common problem and like we've said, we do it sometimes too. Even, you know, being mindful about it, we still end up doing those things. But like the showing your ignorance is also a very like genuine thing to do.

• 24:03 Kel

  It's a very like, I am trusting you to show you that this is what I know and I'm sorry, I don't know X. Please help. Um, and like, it's really all you can do. And I mean I gave the example of, I got a question with like a balanced binary search tree and I was like, what are those words mean? I don't know what a balance... I'm pretty sure I know what a binary tree it may be, is it 2 tree? And like I've been doing this stuff for years and so I'm comfortable with my ignorance in some areas because it's like if I don't know it, there's probably a reason. It's probably like weird, you know, off the little like niche kind of Info that I just haven't needed for whatever reason.

• 24:38 Joshua

  Or just a different name for the same thing you already know.

• 24:40 Kel

  Right? Yeah. Or something that I absolutely know what it is. I just didn't realize it had a name. But like that as a junior person, you don't really have that feel for what safe to ask. You know what it should I know yet and yeah, there's really nothing you can do about that. Like being truthful is a healthy thing to do.

• 24:57 Joshua

  And yeah, honestly, I'm constantly pushing myself in my career and as I get into new territory, it's much the same. I find that... While yes, if it's dev thing and I don't know it, I'll just say I have no idea what you're talking about because chances are if I don't know what it is, either I shouldn't know what it is or maybe I should and I'm happy to tell them because I want to know. But as I push forward, I find that other things that I'm less familiar with, I'm much less likely to say, I don't know what you're talking about. Could you please explain that one to me? Because I'm afraid that they're going to suddenly realize that I'm a complete fraud.

• 25:29 Kel

  Oh yeah. And then there'll be like, you'll stigmatize it, they'll try to shame you or whatever. Or they'll just laugh. Which is also kind of like laughing at somebody whose failures, very human and generally not great either. It's kind of the same problem, just a friendlier version of the same problem. If they're laughing with you, it's a little bit better. Um, yeah...

• 25:52 Joshua

  Yeah. So there you go. Failure is good.

• 25:56 Kel

  Failure is good. Oh. And I kind of related to all that, like owning the, you know, your ignorance, owning your failures is healthy. And this is a little bit of a, another survivor bias thing here. But I noticed being responsible and being very like honest about when I screwed up really did help me in my career. Like that was always something that highlighted me when something went wrong, I always went, oh crap, I messed this up. Here's what I'm going to do, here's, you know, here's what happened, here's what I'm going to do to fix it here. You know, it's already in progress. And like that always resonated really well with, you know, my bosses who are like, Oh cool, you've screwed up and fixed it. Neat. Good job. And like that was always a good thing to do. So like a little bit of survival bias there. I can't, I can't say that'll work for everybody, uh, but has always worked for me. Well,

• 26:42 Joshua

  I think at the very admitting to yourself that you failed is going to work for everybody because if you're not, you're not gonna learn anything. And that is a big one. I know I'm absolutely guilty of this all the time. I screw things up and I won't even admit to myself that I did it and that means I'm not learning from it because I'm going to blame somebody else or I'm going to blame something else. The machine did it, or in fact, I remember as a high schooler, I was writing some report in computer class because I had done some project and I had written this entire report about 10 pages long about how gremlins made this thing not work. It wasn't the fact that, yeah, I had no clue what I was doing because I was a teenager and yeah, but the Gremlins, ...I did get an A on that paper, but it didn't teach me anything. Oh, I guess it taught me that I could BS my way through things.

• 27:27 Kel

  It's a skill.

• 27:27 Joshua

  It's a skill, but I'd much rather admit that, yeah, I screwed that up and then go learn from it. And eventually I did admit that. Yeah, I didn't know what I was doing and I went and I learned from it. But it took me a while and I could've picked those things up a lot sooner if I had just admitted it straight away to myself.

• 27:42 Kel

  I found, I have found that the concept of shared faults and shared responsibility for me anyway has really helped me accept things that were my fault cause I can look at it and go well it was also the fault of this computer bombing. But it was my also partially my fault for not hitting save earlier. And it's like it kind of helps balance those two things of going, I should iterate and correct on that, but also not try to like accept all of the blame for the thing.

• 28:08 Kel

  Like it's not entirely... You know, it...

• 28:10 Joshua

  It leaves a little wiggle room.

• 28:10 Kel

  Right? Like yeah it's a little bit of room but also like it wasn't totally my fault. Like there were other things that like, you know, skewed to the odds against me and I didn't realize that, but it was also partially my fault. So I corrected for it. And so I find that helps to balance things a good bit of just being really honest on where all of the faults lie and accepting that you can be like, you can share those, you know, you can share that responsibility and that those shared defaults.

• 28:38 Joshua

  Alright. Accept responsibility. Failure, good. Carry on grow.

• 28:43 Kel

  Be Safe. Grow.

• 28:44 Joshua

  Be safe, yes. All right. I'll put some transcripts up at gettingappsdone.com. Please be sure to check out my website at joshuagraham.info and Kel's website at piffner.com if you have failed massively or in small ways or have learned a lesson about how to...

• 29:00 Kel

  Spectacularly?

• 29:00 Joshua

  Spectacularly. Yes, that's a good word. I like that one. Or if you've got some really great lessons about how you accept and learn from failures, we'd love to hear about them. I've seen on Twitter quite a few people put up things just to try to normalize failure a little bit and say, hey, how have you failed? And I promise I will actually participate in one of those. The next time I see one. Uh, if I can remember through my rose tinted glasses a time that I really spectacularly bombed on something. Uh, also be sure to check out our slack community at gettingappsdone.com/slack where we talk to all kinds of people about things that have gone wrong and how to deal with them and how to learn from them. And a lot of other different topics about being a developer. Otherwise, we will catch you next week. Thanks for listening.

• 29:45 Kel

  Cheers.