Mistakes, Errors, and Bad Judgment: Turning Faux Pas into Positive Learning Experiences

Welcome to Building Better Developers, the developer 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, errors, bad judgment, all those kinds of good things rolled into one, spending a season looking at ways that we can turn these faux pas essentially into something positive, something that we learned from, or maybe to see where that was a stepping stone for something greater further down the road. This episode, I'm going to get a little more technical and it's, it actually has, I've done this a couple of different ways. And in the technical sense, in the programming world, this would be if you're a Unix type person, this is when you do an RM space star or asterisk. In a simpler sense, any kind of activity you do that is sweeping, that is broad, where you put a command in that says, hey, update everything it wants and just go do it, or as the RM is, delete everything and just go do it. And sometimes that would be great if you are where you think you are, but sometimes the context is a little bit different and that can cause you problems. For example, from the RM point of view, that's basically just delete all the files. Now if you're an RM star, it's just going to delete all the files in the folder you're in. That may not matter, but if you're in a root folder, there may be some important files that are deleted. Also, which is the more prevalent way to do such thing as an RM dash RF star, that actually goes into the whole of the folders and deletes all the files there and all the folders. So effectively, if you do that from the root drive, you remove everything from your computer. Not a very good deal. Now most people learn this somewhere along the way fairly soon, that you want to be very careful with some of those kinds of features. That's why a lot of people actually don't, they're not even fans of being on a command line console. But a different way that I have used this, and it's a different mistake that I've probably made more often, is in the database world. This would be where you either delete all records matching a certain query, or update all records, or insert a bunch of records based on some process you're running. This could even be a process like for example, let's say you're doing some sort of web scraping thing and you go pull data off of one site or out of a file, and you say, okay, I'm just going to take all that stuff and shove it into this other system or into this database. Sometimes you don't want to do that because for example, mass updates, you may suddenly corrupt your data. You may be updating things and setting values that you don't want to set. And so instead of doing such a thing in a blind manner, what you want to do is test it beforehand, is do something that limits it, validates what you're doing, and then you can execute across the greater set. And this is actually something I was taught, more or less taught by a database advisor, DBA that I was working with, administrator, I'm sorry, DBA that I was working with at one point. And he had been a DBA for a while. I was in a DBA role and I had done it enough. I mean, I knew I had been doing databases for a while at that point. But we did a lot of research and we're doing a lot of tweaks to data and to scripts and performance tuning and things like that. And there was a lot of times that we were going in, we would get, I forget what they specifically called, but they're basically like, it's basically a data fix. There would be a crest that says, hey, we have X. Like for example, we have this customer that entered all these records by mistake and we need to get these records cleaned up, usually deleted. Now it varies. Sometimes it was a delete. Sometimes it was some sort of a value or status set to maybe deactivate them or maybe change a certain date on it so that they were not currently active. Now the number of records we're dealing with was not huge, but it also wasn't small. And it was not impossible for us to hit tens of thousands of records for some of the things we were doing. Usually we did not want to do that, though we didn't want to impact that many records. The work we were doing was much more precise. So it was maybe dozens or hundreds of records. And what we would do is we would sit there and put together a query and then go run that query to clean up the data because manually was just going to be too complicated or just too time consuming. And there was, I'm trying to remember if in this specific case, I think there was one where I went in, ran some query and it had a different impact than I thought. It was one of those I was looking at. I had run it, looked at the where clause, all that kind of stuff. And it may even been a typo in it that it was one of those things that it did more or incorrectly the thing that it should have done. And I was like, oh, I got to go fix this. You know, here's I just did this. I'm realizing what I did. I got to go. I did more than I wanted to. I got to clean up those other records, blah, blah, blah. So he jumped in. We were working through it and it was one of the things that's obvious. It felt like but it wasn't until he said it, I was like, oh, yeah, that makes a lot of sense was for in this case, it was an update or delete statement that I was using. And he said, you know, what you can do is you can do the same thing, basically make it a select statement, look at the data from there and then you get to see the exact data that's going to be impacted. You can even look at what it's going to look like afterwards. And then it's view only. So you're not doing any damage. So you can do that until you get the results that correct and then flip it over, you know, change it from slack to delete. Very simple. It would be, I think, pretty common sensical, but it's one of those things that sometimes just doesn't occur to you. And for me, it didn't. I was like, oh, OK, I just I go in and I do these queries, these updates, these deletes. And I was like, oh, that's an extra step. It's a very good extra step to take. And that is sort of a lead in to the idea of having like a test environment. In this case, it would be a test query, a read only query that does the work that you are intending to do such that you have a very solid way to verify it without making it do no harm, without doing making any changes while you're working on it. And that's why we have things like staging and test environments and even development environments are awesome to have because you can do whatever you want in those. It's a sandbox, sometimes even called a sandbox environment. As you to play around, allows you to make big mistakes. And usually if you've set it up right, then it's not that complicated to just reset the environment and get going again. So whatever you do, you get to verify it in a safe kind of environment and a safe place. And then you can always flip over to, you know, to do it for real. So you get to test it and then you get to go out and verify it. It's just like in sports, you'll see in particular hockey in the last few years, there's there were a lot of things. Actually, if you go back probably now five or 10 years ago, there were a lot of these little trick shots and stuff that you would see out on YouTube and places like that, that these kids or players were doing these just really interesting high skill maneuvers. And they would do it and, you know, in practice or, you know, things like that where it wasn't really for real, it wasn't a real game environment. And they did that for a while to the point that now you're starting to see some of those show up in actual games, even at the highest level, because they were able to practice it, validate it, verify it, perfect it. And now can do it for real, can go do it in a production, in a game time situation. And that's what we want to do. Really, as to become better developers, there's a lot of different areas of our work that this is an important concept to have, is to be able to create for ourselves a development of our an environment where we can test things out and not worry about doing harm to a live system. That's why you really never want to be working on a production system. If you absolutely have to, it should still just be like read only. You should be able to review what's out there and verify some things, but not make changes until you've run all of that through test systems or staging or something along those lines. It's actually one of the first things I do with whether it's a new customer, when I will get into new jobs, whatever it is, one of the first things is to set up a development environment, make sure that I have a place that I can test some ideas out of. I have a place that I can test some ideas out and execute code or run scripts or whatever it is and do it against data that is, it doesn't have to be live, but it's close enough to it that I can verify that, yeah, that's going to work. That's going to do what I want it to do. And then can always do it in a production environment. Of course, what's best is to be able to test it all, do it all through on your test environment, copy that over to production one more time. Test it from selecting all the records instead of deleting them. And then if that's correct, then you flip it over. There's so many little things we can do that are typos or little simple logic areas. It's not that uncommon for us to write a query or code that says, hey, I want to grab everything less than this value. But it's like, oh, wait, I really wanted everything greater than that value. Or off by one errors. Those happen all the time. You know, I wanted to do the first 10 items, but I put a less than 10 and it just counted, you know, one through nine instead of 10 or something like that. You know, there's, you know, I forgot that the way this is indexed is starts with a zero as opposed to one or vice versa. Those little things can sometimes be devastating. We can do a lot of damage to data. And that goes back to the original example would be like a delete star. And I have over the years, even though I've done this for a long time, there have been times, I don't know when the last time I did something like that. Probably within the last few years, I had something where I deleted something I did not want to delete. I can tire folders and subfolders or something along those lines. And there is another story about related issues where sometimes it's not, it's inadvertent. You don't realize what is looking at what's going on. But that's a different story. In this case, it was something where it's going along, cleaning some stuff up. You know, and I think it was like probably even like a typo accidentally, you know, instead of doing an up arrow or head, instead of hitting enter, it was up arrow and enter. And then last night, next thing I know, I'm in a different folder and I'm deleting the wrong thing. I'm in a different folder and I'm deleting the wrong data. That's why I have backups. I didn't have a staging environment necessarily in that case, but I do have everything backed up regularly enough that I was, you know, after saying some very choice words about myself to myself, I said, oh, all right, I got to go grab the backup and I'll go restore that stuff. That's also why we have like a trash can and, you know, all of our user interfaces, or at where you can go back and you can restore from the garbage printing, it been pretty easy. And there's most of the things out there are fairly forgivable, particularly cloud solutions. They, you know, if you delete, they're still going to hold it for, you know, usually at least a week, maybe 30 days or more. So you can go, oops, I made that mistake. And those features are there not because, you know, nobody ever uses them. They're there because that kind of stuff is actually pretty common. I don't care how long you've been in the technical world, how many times you've done it. You can fat finger something you can, you know, there's typos, there is just having your head just a little bit off. So you, you're thinking one way and then the next thing you know, you're like, oh, crud, that is not at all how that script is supposed to run or where that's supposed to run or what that is supposed to connect to. And it's just as easy to have some sort of like, you know, config files where you, you thought you were connected to production or you thought you were connected to your development machine, but you were connected to production instead. So the moral of this story is when you're working through a problem, you're putting a solution together. This is particularly when you're doing it in a high stress, maybe a firefighting type of situation, you know, everything's burning, everything's in trouble. Customers are screaming all kinds of stress and stuff like that. This is one of those times where, yes, that's important. You want to get it done as fast as possible, but it doesn't hurt to take a deep breath, validate what you're going to do before you actually do it. And this may be even back to instead of just diving in and trying to fix a problem, take an extra little bit of time, assess what the problem is, design a solution, think through it a little bit so that when you dive into it and start implementing, you do not get partway into it and realize, oh shoot, I forgot something. I've got to go back to this drawing board instead of wasting time. Take your time, think through it, take a logical approach, a clear headed approach to it, and then walk through and get it done. Because yeah, it may take you a little bit more time to do that, but you're going to be much better off when you get done that you've done it right and you've actually fixed it as opposed to, guess is probably a strong word, but more or less guessing your way through it, saying, I think this is sort of it, you know, shooting from the hip. And then the next thing you know, you're basically back at square one. People are still angry and probably now even more angry because you said, yeah, I've got an issue, I've got to fix. And then that fix ended up not working or sometimes even making things worse. So I think that's it for this one. I'm going to get on to probably making some more mistakes as we all do. But hey, at least now there's a place that I can take them and try to find a way to learn from them and show the positives out of those missteps and errors and all the other fun things that make life interesting. But that being said, we'll call it an episode. 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, the Develop-a-Nor 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, Develop-a-Nor 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-a-nor.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.