validating source, verifying assumptions

Welcome to building better developers, the developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We're continuing our season where we're looking at mistakes, missteps, errors, all those things that people could have a negative view of, but instead these are things that have been stepping stones for future success or at least not repeating those errors and those mistakes and making things work a little more smoothly at least we'll say moving forward. So there are these benefits and you've seen this in many, many situations where you can look at people that were, you know, quote, wildly successful or an overnight success, but instead actually had a lot of mistakes and learning experiences beforehand. This episode we're going to go back to a, it's really more like a research type of situation experience I had, but it points to something that we run into a lot, particularly in the world of development. I think all of you will have seen this if you've written code at some point, even if you just did something, you know, a little class in college or high school or whatever. And it really goes to the idea of like validating your source, whatever your source may be. Now this particular story experience started as a project in college and the class we were in was, it was basically, it was artificial intelligence. I think was the name of the class or something along those lines. It was about artificial intelligence, about creating learning programs and those that would store, you know, basically store experiences and use those to provide better solutions moving forward. Now the project we did or the program that we were writing was one that was aimed at essentially troubleshooting. It was an expert system for troubleshooting bugs in any language, basically. And the whole point was that you would go in, it would ask you questions and you would either say yes. And you've seen this probably this approach in if you've gone to like support sites and even working some of these like bots and stuff like that, where essentially it says it makes a recommendation, says go try this. And then you come back and either say yes, that worked or no, it didn't. And if you say it worked and it's like, great, thank you. And then if it didn't, it will move on to yet another recommendation. And the way these things work is you're going to start with what is most likely the problem or to some extent, I guess it is what is most likely to get you to a solution quickly. Now there are, there's a difference between those two because there's the old, you know, turn it off and turn it back on again for a lot of computers that will solve many problems, but only in that situation. It's really, it's more like a band-aid than an actual solution. So the way this thing worked was hopefully a little better because it wasn't, it wasn't always going to go to the, like the number one solution. It would try just through randomness and things like that. It would offer some other options. So the goal there was to have multiple entry points, multiple first questions. And then, you know, ideally over time, it would store information, which it would learn through all of those different entry points, what were the, you know, the shortest routes to get to whatever the common problems were or the most typical problems. Because you could think about it, there may be a hundred different first questions that you could ask, but maybe there's really only five problems that you ever really run into or, you know, nine times out of 10, one of those five is going to be your problem. Or that, you know, that's going to be your solution. So in doing so, you're, you're going from this big pool and you're eventually whittling it down to saying, yeah, we're probably one of these four or five problems, move forward. With all of that, you know, it's just to build the story that we went in and we built this little application and we had, I think we had like, oh, bonus to this. If it went to a certain point and couldn't solve your problem, then it would ask you what should, you know, essentially what was the solution and what would I have, should I have asked to prompt you to make that change to get to the solution. So for example, if I, if you came to me and said, I don't have today's mail on my desk, you know, the post postal mail. And the first question I ask is, well, have you checked the mailbox? And you say, yes, you know, I checked the mailbox. That would be a solution. But if you say, yes, I checked the mailbox and I say, okay, tapped out, I don't know what else I can possibly suggest. Then you would say, oh, you should have asked me if I had looked on the floor, you know, maybe fell off the desk on the floor or I should have looked in the break room, you know, or something like that. And so the next time I come through as an application, I could say, hey, did you check the mailbox? Hey, did you check the break room? So now I've got multiple questions I can work with. So this not only learned with the starter set of questions, it also grew, it would grow its knowledge. And this is not, it's not rocket science. This is not something that is, is untypical, is untypical, particularly today. There's a lot of software out there. So the way we did this one is we built it with, I think we had 20, 20 or 30 seed questions. And we had this thing run for quite a while, quite a while, I think it's a couple of weeks that we used it. And then we had other people use it and it would just sort of fed, you know, fed this information into it. And the interesting thing is when we look back, because we could look at all the data that we had in there, when we looked back after sort of going through this research period, there were about 50 questions that were leading to solutions. And out of those 50, the one that by far, like, I forget the numbers, but it was like 60%, it was over 50%. And I want to say it's like 60, maybe even 70% of the time, the one answer out of those 50 that got you to the solution the fastest was, did you save your code and verify that you are, because it's basically for like compiler errors, that the compiled code that you expect is being compiled is actually the version that you, you know, that you're working with, which is basically, you know, you go and compile some code. Did you save your changes before you did that compilation or did you need to go back and save your changes? And that is quite a lesson in what we do, particularly in, and now it's gotten better in modern software, whatever you're, whatever it is you're doing, whether you're writing code, whether you're in like a word processor, processor or spreadsheet or something like that, you can go in and make changes. And it usually has some sort of a notification or some little marker that says, Hey, by the way, you know, this hasn't been saved. Or most things now, if you try to close it, or if you're on a website and you try to go to a different page and you haven't saved or committed your changes, you'll get some sort of little warning button that comes on a window that comes up that says, Hey, do you really want to do this? Or do you want to go back and save your changes first? Or the other thing is you have sites that when you move to another page, when you move off the page, that's the thing it does is it says, okay, I'm going to save all these changes just to make sure you don't lose them. And that is because we, we so often think this is a perception thing in a sense, thinks that we are working with one version of our document or our content, and we're actually working with another. And we didn't make a change, we didn't save stuff. There was something we did that didn't, that gives a disconnect between what we think we are working with, and what we are actually working with. And there's so many examples of this over life, another example that I think people run into, probably run into on a regular enough basis is when you go to purchase something, you write a check or you use a debit card or whatever it is, and you thought you had enough money, but you didn't because maybe, maybe when you looked at what your balance was or what all the transactions were, there were some transactions that hadn't come in yet, or hadn't posted yet. And yet, you know, that's the difference from when you like, maybe even if you go to the grocery store, so you sit down at home, you look at how much money you have, you say, okay, I've got X amount of dollars. You go, you go to the grocery store, you get all your groceries, you go to checkout, and you realize you don't have as much money as you thought you had because between looking at your when you were at home and it checking it now when you're checking out, there's another transaction came in. And so you're the source that you were working with, the data, the content that you were working with, that you were basing your assumptions or decisions or budgeting on were incorrect because now things have changed. And so this is quite the lesson is to most simply, I guess, back to the old trust, but verify. But it's also it's before you make particularly big decisions. But often, also, this is something that's when you're when you're troubleshooting something when something is not working the way you think it should. Go back and validate the source, go back and look at your assumptions, review your assumptions, and make sure that those are still valid. Because if you've had content change or just other events that have occurred, then it can change your entire perspective. Sometimes there's something that you can look at and you say, Oh, you know, I was sure it was going to be this, this was going to be my solution, or this is the problem that I was solving. And you find out it's something else. It can be and it can be in any facet of life. When the the output when the end doesn't match what you expected, then one of the best ways to go in to step back and troubleshoot it is to verify that the inputs that you expected or that you thought were were there are correct. And for example, you may have like a sports team that would not there's no way they lost this latest match. And you find out after the fact that, oh, they lost that match because they're, you know, the top three players were sick or injured or didn't play or something like that. There are so many factors that go into just about anything. And all of those could potentially change from point A to point B whenever your your initial analysis was or your assumptions of analysis and when it actually occurs, when it's executed. And as developers, this is a huge, huge time, time savings actually and lost time when at least I know in my personal experience where I start chasing something down and I'm going through all kinds of different hoops and trying to figure out how on earth could this possibly be the way it is only to find that, oh, this thing that I assume this file that I thought was going to be there or this line of code that I thought was this way is actually another way, either because I didn't save my changes, which is very often the case. My changes don't either they weren't saved or they weren't committed or they weren't copied over to the right place. Something broke down in the process so that what I changed did not get to where it needed to be. Or if you're in a particularly if you're in a like a multi-user environment, you went and changed something and somebody else changed it after you did. And so there was a, you know, there was another hand in the pot and that messed up your assumption. And I've seen that frustration on many, especially in the development environment of modern development environments. We've got a lot of software and although it in some cases allows us to put developers in silos so they're not touching the same code at the same time, there's still the side effects and things like that where somebody touches some code somewhere or maybe even the same files you're working on. The change that you thought went in got stepped on or over written or changed into another direction. And now you're chasing something down working on the wrong version, the wrong copy. And there's so many stories of this that I could go into and they all end up being really a frustrating waste of time because it's the kind of stuff that if you first verified your source, verify that you were working with what you thought you were working with, you would have gotten so much faster the solution. Because instead of basically just working on the correct version, you end up questioning the changes you made. And then you realize that you didn't actually, as far as the system was concerned, those changes weren't made. And it becomes chasing your tail a little bit until you realize it, oh, the system's looking at something else or the analysis is not on the data that I expected it to be. And this, like I said, trickles into things like communication and other issues that we've talked about. But it is so simple, really. You know, it's like, hey, did you save the file? And this is back when it was like, you know, one or two files, it wasn't near as complicated as guaranteeing or verifying that all of the changes you made got to the right place for your build as a developer, as you have to do today. And yet still, that was something that happened so often, people forgot to save or forgot to, you know, they weren't working on the right version of the file. So and these, I mean, granted, these were college students, they weren't, you know, grizzled veterans that have been doing this for 30 years. Nevertheless, it does show how the fact that it was such a prevalent thing, I think does show how easy it is for us to assume one thing and reality to be just a little bit different. That being said, whatever your reality is, we're going to go ahead and send you off into it. So go out 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 developer 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. Hi, this is Rob from Building Better Developers, the developer podcast. We're excited to be on Alexa now. You can enable us by simply saying Alexa, enable Building Better Developers, and we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon now.