Mistakes and Learning from Them

Welcome to Building Better Developers, the Develop and Work Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season. We're looking at mistakes and how they maybe led to other items, other steps that were successes later on or just learning from them. Now, this episode, I want to talk about the time my car was stolen or wasn't really. And this is a. This is actually an interesting lesson that I think helps us, particularly in the world of things like testing and verification. Because we have this thing called the happy path that we've talked about, which is, you know, if everything goes right, this is how it should all come together. But there are sometimes paths that we either forget about or fail to take. And that can cause that can have all kinds of bugs and issues there. So this story, big mistake I made, goes back again in my youth. So I guess we can give myself a little bit of grace there is I went to a concert with a couple of buddies of mine and. I drove, I had a little pickup truck and we piled into the pickup truck, went to the concert, had a great time, and it's a it's a it's called it was called a Coliseum. It was one of these covered places that's got parking lots, 360 degrees around it. So it's a, you know, think of a building right in the middle of a big parking lot. And it was near fairgrounds, fairgrounds. So there were also once you got further out into the parking lot, there are these other buildings that were there for exhibitions and stuff like that. And then it went to even further parking. So you think about it, it's if you think about it in a simplistic way, a big circle at the center is a building and then going out from that is parking spots. And then at somewhere between the middle and as you get towards the end, there are some buildings that are there. So this is important for the story. If you walk out of the building, you do not have a straight site line of sight all the way to the edge of the parking lot. So we went to the show, had a great time. Yeah, I don't know, it's about three hours probably because there's an opening act and the main one, so maybe four hours. When we got there, it was daylight out. You know, it was, I don't know, five, six o'clock at night, something like that. It's probably in the summer. Pretty sure it was a summer kind of thing. And it was a Sunday night. And we went there, it was daylight out. When we got out, it was dark. And so, you know, things were a little different. And of course, there were a lot more cars, you know, the parking lot, things like that. Well, we started wandering in the direction of the car and started looking around and not finding it. Or the truck, I guess, actually, they'll pick up. And so we wandered around for a while. We're like, oh, maybe it's this row. Maybe it's one more row over, maybe one more over. And couldn't find it. So after spending some amount of time, and I don't remember how much time is probably, I would say probably 20 minutes or a half hour that we wandered around looking. We said, oh, some of us have stolen the truck. And so we went back into the, you know, back to the Coliseum there, found, you know, found a security guard, basically just said, hey, you know, I need a report of stolen car. Can you help me out? And this is before we had cell phones and stuff like that. And so the guy is like, you know, hey, let me, you know, contact the right people. Can we call anybody for you? And we were able to find a phone and able to call my dad, who was home and sound asleep, because by now it's probably 11 o'clock, 1130 at night. And we called him and said, hey, can you come pick us up? Truck's been stolen. This is what happened. And of course, he was, you know, that's not the best way to wake up when you're trying to get some sleep. Hopps in his car, comes to pick us up. So it's about a half hour drive, probably from our house to the the music place. So we're hanging out. He's driving. So about a half hour later, he shows up and he pulls up. He says, hey, are you sure? Yes, your truck's missing. And I'm like, yeah, we looked all over the place. He said, well, you sure this one isn't yours? And took us out, you know, beyond one of the buildings. And sure enough, there was the truck. So it had not been stolen. We just got turned around enough or, you know, whatever it was in our search for the car. Yet we did not search far enough. We took, you know, in this sense, as I started out, so I took the happy path in that, OK, we're pretty sure this is where it's at. And we didn't expand our horizons with it. We didn't. We just assumed that we were in the right place. This is an assumption thing that we'll find in a lot of these stories. We assume we were in the right place. We were looking around. We couldn't find it. Therefore, somebody must have moved it as opposed to maybe we were wrong. Maybe we were looking in the wrong place. Now, over. The subsequent years afterwards, this is one of these stories that is sort of stuck with me one. Because it's very sad for my dad that he had to get up, had to drive an hour plus back and forth trip when he really wanted to be sleeping to deal with a child that had just, you know, not been thorough enough. But it's, you know, so sort of it's sad for him, but sort of funny that it was like, oh, yeah, it must have been stolen as opposed to maybe I was just wrong. Maybe we were looking in the wrong place. Now, you could say, yeah, that's, you know, teenagers and teenagers are never wrong and things like that. But that's that doesn't just disappear with the teen years. We do that a lot in the development world, in the IT world. It is amazing how many times that story has sort of, you know, bubbled back up in my consciousness when I've run into similar situations. One of them that I see a lot is where, you know, you write some code and you compile it or run it or whatever and you get an error. And it says this is the error. This is what you're doing wrong. And I know I've done it and I'm going to confidently say I know a lot of other people have done the same thing where you start going down the road of what change, you know, debugging it and you end up not really chasing down the thing that's described. It'll say this is a problem. This thing does not exist. And we look at that and say, wow, that can't be right. It must exist. And so you end up going down all these other paths because you say, well, that's probably just not a useful in quotes. That's not a very useful error message. Only to find out when you finally do track it all down that if you had really paid attention to the error message at the start, it would have gotten you to the solution faster. We make assumptions. And sometimes are wrong. And so it is important for us rather than sticking to our assumptions, sticking to our guns and saying, no, this is this is the way it's got to be, that we are open to the idea that, well, maybe we are in the wrong position. Maybe we're looking the wrong direction. Maybe the things that we are basing our decision on are not all 100 percent correct. And that. Having that in the back of my mind, although it has not stopped me from doing similar things, I've had those situations where it's you sit there and you go, OK, this must be it. And I go down these rabbit holes thinking something is that is not or vice versa. And it takes a while to, you know, eventually get to the point to realize that all my assumptions were incorrect. But having that in the back of my mind, I think has gotten me so that I more often will go back and question what it is that are, you know, what are my assumptions? Because, yes, you know, you don't want to assume that you're always wrong, that unless you really have a bad track record for it, I mean, you're going to figure you're right some of the time or maybe even most of the time. But it's never 100 percent. They're always going to be not always, but often enough. There are going to be differences in how we solve a problem or the value of our assumptions. Assumptions are just that. And no matter what you may think of them. There's an option. There's there's always that possibility that you're wrong or incorrect or just slightly off point of view. I will find is another that often is an issue that we we could swear up and down that something is what we saw or what we observed. Only to find out that it was not because our point of view was incorrect. We had some things that we assumed that were wrong, that we didn't understand the, you know, maybe the value of them, how much those impacted our final decision or observation. And this would be one of those cases where, you know, I had I looked at it one, it wasn't this is where if you step back, you know, in the midst of it, it would be like, hey, you know, I walked out, my car's not there. Somebody stole it. But if you step back a few minutes and think about it, it was not a highly visible vehicle. It's not like it was, you know, the one bright red in a bunch of in a sea of white or something like that. It was parked in a parking lot amidst hundreds, thousands, probably thousands of other vehicles. Maybe I don't know if it goes to tens of thousands, but it was a lot of other vehicles there. It was not something that was going to be high value. It's not like it was a diamond amidst a bunch of, you know, pebbles. And we didn't have the doors were locked. And I assume at the time and now I could easily assume that, well, maybe they weren't locked. But what are the odds of somebody wanting to run through a parking lot? Unless the keys are like in the ignition. Because there's just, you know, you got to figure there's traffic. There's people going through there. There's people walking around. There's probably some security guards to some level. Now, this maybe wasn't, you know, it's one like the most secure place ever. But. And you think about it, the odds that that was the one thing stolen out of the parking lot has pretty far odds versus. What are the odds that we were looking in the wrong place? Especially when you consider that as a couple of guys, all, you know, good friends, we were talking and just having a conversation all the way on the drive there, the walk in, all that kind of stuff. So there were plenty of reasons to say maybe we were distracted. Maybe we weren't quite right in our assumption of where we had parked. Maybe. We should have spent some more time digging around the parking lot, you know, looking through there, say, OK, well, maybe this wasn't exactly where it is. Let's range a little further. Let's be a little more methodical about it before we assume something that is probably and it's low probability. And now that's not always the case, it's not always something where we're going to be able to look at it and say, oh, wow, this. This is a situation where it's much more likely that we're incorrect than it is that that thing happened, you know, that event occurred the way that it must have for us to be correct. But this is highly important because in modern world where we have news and social media and full of people throwing opinions and this is how this should work and this is how that should work in our in our jobs. We're going to have people with strong positions depending on maybe what department they are, what how they are involved in a product or a project. And it's going to help us to be able to step back a little bit and say, OK, let's try to confirm or validate our assumptions before we go a little too far into things that are highly unlikely. Now, there's a this is like a lot of things we'll find. There is a a cost benefit analysis that we may want to make to some of these things, because sometimes for us to go through the process of validating our assumptions may be very costly. So it may be more efficient overall, just playing the odds to say, yeah, let's just go with our assumptions and then run that out. But there's going to come a point where we're running that out and it's going to we're going to look at and say, maybe we're spending too much time trying to go down this path under the assumption they're correct. Let's back it up a step and validate our assumptions first. Let's just make sure that we really are on the right path, because sometimes that's the case. Sometimes it will sometimes it will be a long journey to get through solving that problem. But sometimes you get deep into that journey and then only to find out that there's some incorrect assumptions. And rather than spending good time after bad, we back it up. And if nothing else, it doesn't hurt to sort of retrace those steps just to make sure we're on the right path. It's not always easiest thing to do. Sometimes it's going to cost us to step back. And a lot of times going to cost us to step back and analyze how we got here. But once you get to a certain point, you keep your head up, sort of, or at least occasionally pick your head up when you're solving problems and trying to chase something down. And every so often say, does this do a sanity check? Does this make sense? Is everything still pointing me down this path I'm taking or are there things that are pointing me somewhere else? And I see this, I think, I think that's the biggest thing and maybe it's because these are logic problems. I see this a lot in debugging where you assume something's wrong or I assume something's wrong for a certain reason. And you start chasing it down and looking at things and saying, no, things are not working out. They're not showing the values or acting in a way that they would. If this is the case, maybe that there's something further down and you just got to keep digging to find where it's broken. But it'd be like chasing down. If you've got a bunch of wires connecting to something, then that thing doesn't work. And then you figure, OK, one of the wires is broken. Well, if you're getting almost to the end of the wires and you still haven't found it. Then maybe you should step back and say, well, maybe it's something else. Maybe we forgot to turn on the switch or something like that. Sometimes it's something very obvious. And that can be. Frustrating as all get out, but. It is something that we can solve by not resting too strongly on our assumptions. And instead, at times saying, maybe I don't have this right. Maybe I'm not seeing this right. Maybe we have some assumptions that are incorrect. Because in so doing, we are now freeing ourselves up to chase down different options. Whenever you're making those assumptions, whenever you decide, you know, you make these decisions, you're now limiting options because you're going based on you're moving forward based on that decision or that assumption. When you loosen those, when you free yourself from those, now you have more options to pursue. And this goes into far more things than just solving a specific problem. This is where we get into the opportunity to do things like solving something better or solving more problems or a lot of other benefits. It's about removing constraints in our ability to get the job done. And if that's not a good lesson, then I don't know what is. That being said, I think it's a good time to wrap this one up and move on to whatever next painful episode that I've had in my life. But as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go, the Develop-a-Noor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great, if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you. And maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.