Mistakes and Learning from Them

Welcome to Building Better Developers, the Developer Nord 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 where we're talking about mistakes and learning from. This episode, we are going to talk about time that I am probably evil Knievel did a little too much. This again, we're going to talk about some few childish mistakes, childhood mistakes, and try to figure out where we can learn a few lessons from it. This particular mistake was again, probably about 12 to 14 years old, which as I think about it seems to be a very common age for making a lot of mistakes that are a bit memorable, to say the least. In this situation, we were out as kids do, or at least did back in the day. And this was for, right, you didn't have a license or anything like that for cars. So you would ride your bike around. And I had a little dirt bike kind of thing so I could off road it. I could ride around the neighborhood and do all those kinds of things. And it was one of those nice days out where we decided we've got a couple of us, we've got our bikes and we decided to make a ramp. Actually, I believe it was two ramps is what we initially started with. It was one of those where we're going to have a nice little ramp on one side and jump and land on a landing ramp on the other side. So it was not super tall. I bet it was maybe two feet off the ground at the at the the launching point on the ramp and then a little shorter on the other side. And there was a gap. I don't remember. It's probably maybe a yard, maybe three to four feet, something like that. The gap was not huge, but it was on level ground basically. So it was something where we could get some speed up and it was a is it basically it was like some sort of a three quarter inch plow or three quarter inch board. And we had some like some two by fours, four by fours, things like that underneath it to support it. So it was a ramp that was sturdy enough and you could hit it at a pretty good speed and you're going to be OK with it. And we proved that by numerous times and get a good run, take it, hit the ramp, do a nice little jump, land on the landing pad. And then we are the landing ramp there and cruise down. Now, we've been doing this for a while. So we at this point, we had removed our landing pad and we were just trying to do funky little things, try to get a little bit of air, as they call it, get off of the leave the ramp, have a little bit of hang time before we hit the ground again. And we were just, you know, putzing around doing different things, trying to see what really just what we could do. What did what were we capable of? And we were not this is way before bike helmets were cool and stuff like that. I mean, we had I remember at that age, particularly if we went skating, skateboarding or something, there were knee pads, elbow pads. And we did have helmets for some of the stuff that we did. But this day, none. Didn't have any, you know, no knee pads, no elbow pads, no helmet, nothing. We just put our ramp together and we were out playing around. That may be a bit of foreshadowing there. And so at one point I decided I got this brilliant idea that I was just going to see if I got as much speed as possible and hit the ramp, how far would I travel without giving it any help? So instead of our typical approach on a on the ramp as you would get some speed, you hit the ramp and you would sort of jump on while you're on the bike, your feet are on the pedals and everything. But you get to the launching point and you would basically jump holding the bike with you so you could get more distance. There's some other things that come into play in that, which we will probably find out. There's two probably challenges I made to this one as I went and ran, you know, hit the ramp at a high speed is that I was pedaling all the way, which caused a little bit of a problem because when the front wheel left the ramp, I was still pedaling. So there was still extra force being applied on that second wheel. Also, I was just sitting in the bike so I didn't, there was no lift, which to explain a little bit of physics, I guess, or whatever means that if you can picture it as the first wheel leaves the ramp, there was nothing to keep it really to continue rising. So it wasn't going to be, you know, now it doesn't have anything holding it up on that ramp. So that front wheel in a natural sense would start to fall, would start to lower while the back wheel was not lowering. And if you add a little extra force to that back wheel via the pedaling, that means even more so the back wheel is still accelerating up while the front wheel is starting to move down and effectively accelerating the difference between the back wheel and the front wheel. So by the time the back wheel leaves, the front wheel is a good deal lower than the back wheel. That does not lead to good consequences. So as I'm sitting there pedaling along, apparently this was one of the funniest things to watch ever. And you may be able to imagine a little bit because basically what happened is I ended up just pedaling in a way that the back tire was not in my body on top of the bike, completely flipped over the front tire. Now it's a sort of amusing kind of picture to see sort of, you know, I think I didn't see it because I was riding the bike, but I think if you picture a nice two wheel bicycle goes up a hill and then the front tire leaves the ramp and then the back almost spins around the front. So it's almost like the front tire stops completely freezes in motion while the bike essentially rotates around that. So it's a neat little effect. They found it pretty amusing. I did not because the problem with this is when the bike rotates around that front tire, the rider effectively gets slammed into the concrete, which is effectively what happened to me is that I ended up, luckily it was not head first. The way I was set up with my head was sort of tucked in. So it was my shoulders and back took the brunt of the hit and actually continued that rotational momentum. So it sort of rolled onto my back and bounced effectively and almost, I guess, you know, it was one of those almost rolled around and ended up back on the bike in a proper, you know, the proper way I should have been with the two wheels underneath me. I didn't go that far because when I hit the bike, I let go. So the bike did continue its rotation and I think it actually ended up landing on the two wheels minus me because I was on the ground hurting more than I was on the ground hurting more than a little bit at that point because hit my back and I think elbows as well. And so there were some nice scratches and road rash effectively from that. So not all in all a fun thing for me. The good news is nothing broken, no major damage, no concussion or anything like that, which it could have been much, much worse. I was very blessed to be able to walk away from that one, albeit slowly and tenderly because I was hurting a tad and it also turned out to be very amusing to my friends. So I was also a source of fun and laughter for them at my expense. Now, all that being said, consider you could say, well, there's a couple of things like, you know, we could learn from this, like just don't be stupid. But there's a couple of other things that because of my mindset at this time, there are some things to think about. I think, and this again is some lessons learned. One is experimentation is okay. You can go out and you can do experiments, you can do stuff. But as we've learned a little bit, be aware of the risks of such thing. If you are going to go in and you're going to go have fun and experiment with something, make sure you do so in a safe fashion, in a way that you have proper protective gear. Like in this case, if I'm going to be doing that kind of stuff, I should have been wearing like knee pads, elbow pads, a helmet, those kinds of things that protect you in such a situation. You know, that say you say, okay, I'm going to take some extra risks. Well, maybe you should have some extra protection in case the risks doesn't work out. The aforementioned evil Knievel would be an example of this. Now he didn't have a ton of stuff, but he always had his helmet. And I'm sure he had some knee pads and hip protection and chest protection, all that kind of stuff. And more importantly, if you look at the BMX bikers and other situations, race car drivers and stuff like that, a race car driver may not wear a ton of stuff, but they do have like, I think they always have like a flame retardant suit on. And of course the car itself is built so that if, hey, if you want to go run around a track at 250 miles an hour and something goes wrong, the car is built to help protect you as much as can be in that situation. So that's a good lesson learned there is, hey, we take risks. And when we are in that risk taking mode, it's a perfect time to take that step back and say, okay, what if this goes wrong? Because I am upping my acceptance of risk levels. So I also need to make sure that I am upping my safety precautions in this case. Another thing is the, which we've talked about before, is sort of the bull in a china shop or the rushing ahead. In this situation, I just like hit it 100% said, hey, I'm going to try this thing versus like ratcheting up to it. If I had instead just done like a very simple, you know, sort of slow motion, maybe not super slow, but done something at a much slower speed, I probably would have particularly given the heights and stuff like that would have had a situation where I would have realized what was going on, what was likely to happen and been able to predict the end result way before it was something that was done at a speed or at a level or at a scale where it caused that problem. In the IT world, this is something that I think we miss way too often. I've come across this way too often as a developer, as an implementer, where we are working with something and we work with the whole thing or go all out as opposed to finding a subset that we can work in. Data is the best example of this. I don't know how many times I've run into situations where there are queries or applications that are working with like a whole data set, maybe millions and millions of records, when instead that same work could be effectively tested on one record or only a few records. Now you do eventually want to, you know, you want to make sure that you're checking so that your solution scales, but you want to know that your solution works at least for the small subset before you start running it on the large subset. If nothing else, it saves you time because it's going to take longer to progress through a long subset than it is the entire set and then it is a subset of whatever your data is. And in the case of modifying data, if something goes wrong, then it's easier to correct it when you, you know, you messed up, quote, messed up or, you know, somehow corrupted three or four records versus millions of records. Also goes back the idea of having a test environment or a staging environment so that you can test out your solution. Even if you're very confident in it, you can test it out before you get into the real world or production data that can be much more costly to correct. Or in some cases like data, there are cases where you can corrupt data in a way that you really can't go back to the pre-corruption state without having a really good backup. And in the production world, that may not be possible. You may not have the ability to restore to a point in time. You know, you may have something where you messed stuff up and you've lost, you know, some number of sales or transactions. So we need to consider the idea of stepping up to our solution, to our approach, find ways to do it in the small before we try to do it in the whole. Because when we do that, it gives us maybe a little more buffer or wiggle room or grace for a mistake than it does when it's full blown. And it allows us to also cycle through stuff. If we're trying stuff out, if we're checking stuff out, then it's going to be a lot better if we can do that every few seconds or every couple of minutes versus kicking something off and having to wait for hours for it to complete, only to find out that we made some mistakes, we've got to make some adjustments, and we've got to reset it. Now in the modern world, it is not as often that we run into situations where we're like, running a program or something like that, and it takes long minutes or hours for it to run. And maybe that's something we've lost a little bit. Those of us that, you know, some of us can remember not that long ago, and I guess now it's probably 10, 15 years ago. And beyond that, we're just doing a build, you know, changing some code, doing all your compilation, doing your build, running it could take easily, could take 45 minutes to an hour per cycle. Or maybe more. That makes it really tough to make progress, to make timely progress, because you're sitting around waiting a lot. Same thing here is maybe it doesn't happen as often, but still, there's a big difference of being able to tweak stuff and run samples and verify things when it takes, you know, a couple of minutes versus even five to 10 minutes. The number of iterations changes dramatically when you start cutting down your time. So when you can cut down your time by cutting down your result set, taking a subset of it, then we need to take advantage of that. And we don't often enough. It is way too often that I run into stuff where people are doing these you know, test runs and stuff like that, and they're doing it for a data set that is way beyond what is needed to actually validate the solution. So think about, you know, maybe that story will help you consider the pain that can come when you try to go all out as opposed to a stepwise kind of approach to your solution. You know, do a little, do a little more, do a little more so that you're fairly confident of the solution before you go full blown. And really by that point, you're really testing scalability over whether it's successful or not, whether it's correct or not. So get another one mistake to share. And I think we'll wrap it up this time. So we will be back. Not done yet. That is far from all the mistakes that have been made that I can share. But we'll wrap it up for now. So 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 to develop a new 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 developer 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 developer.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.