pesky problems that take an inordinate amount of time to fix

This is building better developers, the developer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge and embracing life. Let's dive into the next episode. Hello and welcome back. We're continuing our season where we're looking at positives. We're looking at the things that challenge us and trying to take a bright side, look at them, trying to get some things out there that, you know, maybe they bother you a little, maybe a lot of the things that sometimes make our day a challenge, maybe make it drag a little bit. But there's also some good amongst all of these things today. Maybe one of the more challenging ones, the we'll call them pesky problems. These are the problems that take, we'll say, an inordinate amount of time to fix by inordinate amount of time. I mean, something that's substantial, something that is not one of these things that takes us maybe seconds, minutes, and maybe an hour or two. These are the ones that take days, sometimes weeks for us to get through. That may not be that we're working on the same problem during this whole time, but there are large, large ish kinds of problems that we run into that potentially have, maybe they've got several steps, several things that have to be addressed to get there, but these are the things that just, they cause us to lose sleep. You know, these are kinds of things where it just, you come in day after day and you know, that's the thing you're working on. In my experience, a lot of times it has been like initial setups, configurations, deployments, where you're trying to get all these things together and you're trying to get configurations and maybe the documentation isn't what it's supposed to be, setting up an initial development environment may do this. If you pick up a project from somebody else and it's not maintained very well, then even the simplest change may send you down this rabbit hole. These are the things that, as I said, I think easiest way to look at them are the things that make us lose sleep. These are the problems that we just, we beat on it and beat on it and beat on it. And eventually we get there. And that's, I guess, a bright side is that all that work eventually does get us there in all the cases I've been at sooner or later, you get there. It may take that later, maybe a lot more time than you wanted to spend, and it may really throw off the rest of your schedule. However, we find ways to make this stuff work. And so therein is a positive, particularly after you've done this a couple of times is the, uh, the past success factor. When you walk into something like this and you've done it before, maybe it's probably by definition, it's not something you've exactly done before because then you would just fix it like you did the last time, but you run into a situation like this where you've been in this situation before it, it harkens to the, the hero type things that are out there in movies and superheroes and all that where you've got the, the hero was faced death for the thousandth time and they're okay with it because they faced death before and they've beaten it and you know, all that kind of a heroic, you know, dialogue and stuff that they'll throw out there because, Hey, we've been here before. Well, we have the same thing. It may not be as impressive as saving the universe or something like that, but it is something where we have had a problem that just seems, I will say on the face of it, unsolvable before. And yet we found ways to step back, take a look at it. And eventually probably in a very, in a very, very, very, very, very, very probably in a very, you know, probably had some sort of a process, some sort of a logical approach to step through that thing and make it work. And it is at its core. That is a problem solving skill, taking a problem, assessing it, finding a way to get to a solution. And as we've mentioned before, problem solving is really the core of what good developers do. A better developer is actually just a better problem solver in some extent, if you want to get down to the brass tacks. And so when we have these situations that are very challenging, that really are, you know, like having no safety net, the kind of stuff where you just, maybe you don't have the documentation. Maybe it's something that's new that nobody else has done. So you can't really reach out to people, maybe as you normally would, or just actually in general, eliminates your normal steps that you would take to solve the problem. Then there is something very positive to say the least. It comes out of solving that problem of working through it and getting the job done, whatever it costs it took. And like I said, it could be very costly, but at the end of the day, you have that solution. And so the next time you run into a problem that can't be solved, you'll say, okay, well maybe it can't. And you'll be a little more, hopefully a little more positive and optimistic about your chances as you move forward into it. And that alone is a big strength. There's a huge difference between somebody trying to get something done when they essentially assume, assume it can't be done. And when somebody tries to get something done and they essentially assume that it can be done, the level of effort, the effectiveness of the work they do, all of that kind of stuff is greatly impacted by attitude. It's, it is, I guess, the power of positive thinking, but there's definitely a lot of strong facts you can put behind that to say, this is how a person will approach things. This is the kind of effort they'll put in. This is the ability they have to, you know, maybe go the extra yard or two that they need to, to get the thing done because they have the confidence that they will get to a solution. So that's the first big positive of a big problem. Another one is, it's very similar, but it's the, it's really focused on the journey of going from, we have this problem to, we have this problem solved. It is a, it is a challenge to us, how we, to our normal approach, our normal methods or methodology that we use to problem solving, almost by definition, if our normal methods of problem solving work, this probably would not be such a difficult problem. We would just apply our methodology. We'd walk through the steps. We get to a solution. This is something completely different again, by definition. So we're not able to just fall back on whatever methodology or steps we've used before we have to essentially craft a whole new approach or methodology in order to solve this problem. Now crafting an all new methodology may seem, it may be more than really is what happening is happening. Maybe what we're doing is we're actually refining or customizing approaches that we've taken in the past. But nevertheless, we are expanding and improving upon our toolset for solving problems. We are either adding a whole new approach or methodology, or we are expanding the universe of things that are current process or methodology will apply to. Think about puzzles. There are variations of puzzles as far as methodologies that are used to solve them. Sometimes, and this is, and by puzzles, I'm leaving this very general speaking, not like necessarily jigsaw, not necessarily physical. It could be a math problem or puzzle. It could be a linguistic puzzle. It could be a riddle. Yeah. It could be a, like a crossword puzzle. It could be Sudoku, anything like that. You just, any puzzle. Well, there are things, there are approaches that are used to solve those. I mean, sometimes there are things like, you know, maybe you use a process of elimination to move forward. Sometimes you use a, like a pattern matching kind of methodology to get to it. I mean, there's always brute force as well, but not necessarily brute force as, as far as sometimes we use a, a very, maybe simplistic, we'll say step, step wise approach to solving a puzzle. Yeah. You just, you sort of go for the low hanging fruit and then you move your way up. Sometimes it's built on areas of knowledge. Sometimes we use, we try to find hints within the problem itself. And if you go out and look at the puzzles that are out there, the types of puzzles, you'll see that there are, that different puzzles lend themselves to different approaches. And usually, especially the advanced puzzles, they end up actually combining, you know, multiple approaches to getting to it. A Sudoku is a, is a great one, one, because I have no idea if that's actually the way to pronounce it. But it has a, when you think of there's multiple passes, I guess, that you will make as you're trying to fill out a, fill out the nine, whatever it is, a nine by nine grid. You will go through and, you know, maybe you will look at rows and trying to see if you've got, you know, where you've got openings within rows, where you're missing a number within a row and then you've got columns and then you've got each of the individual boxes. And then you can also look at it within, there's maybe, you know, it's basically it's, it's horizontal diagonal or sorry, horizontal vertical or within that box. But you may be doing, maybe you do some, do like combinations. So there are some ways that you know, for example, that within these three rows, then I have to have each number appear three times. You know, there's some things like that where it expands instead of just row by row, it's actually multiple row by row that you do. And do the same thing with columns. And so each of those is a, in itself, like a little bit of a methodology. And so usually somebody going through will be, they'll repeat those things several times. If you look at the logic problems that are out there, then people will usually read through all of the clues the first time and they'll take an approach. Maybe they'll, they'll look for the most, you know, the, the a is equal to three kinds of things. Some things are very direct. Sometimes you'll have a clue. There's not so much a clue as it just directly gives you an answer or at least a piece of an answer. So sometimes they'll work on that and then they'll work on, well, if this, then that and, and pass through multiple times. And this is not to try to teach you how to solve those problems, but to note that when we solve problems, puzzles or problems of any kind, we have a process. We may not realize it, but we do have a process. Each of us, I think individually, I mean, there's, there are things taught so that there are going to be people that have a, I don't want to group think sounds bad, but there there'll be groups that have a same, because of the way they were taught, they'll have the same approach to writing, you know, to writing code, to solving a problem, to how they do design. And some of it is it, are the methodologies out there. I mean, if you think of test-driven development, that would be, you know, an approach to solving the problem is that you put together requirements and then you decide what the tests are going to be first, and then you code to those tests. That would be such an approach. When we have these things that do not fit in our, we'll call it our known universe of problems. So the methodologies that we use don't work or at least don't work enough because we don't get to the solution. Then we are forced to not only craft new methodologies, but the whole skill of crafting a new methodology is something that is a, an experience that is very valuable to have. Sort of like being lost on a desert Island and having to build a, you know, some sort of shelter and find food and water and things like that from scratch. It is not often enough, I think in our careers that we're in a situation where we are in a, we'll call it from scratch situation where we just don't have much to work with. And so we have to build stuff up on our own. The internet is making this less and less an issue because we can, we can reach out to people very easily. We can find boards and FAQs and call service providers and things like that. Call support and all kinds of other things. But sometimes that's not the case. And it is very valuable for us to know that we can work on that situation, that we can survive. We can solve the problem and we can actually devise a way to solve such a problem. We can devise a methodology. We can create a process out of thin air. This is not easy. And I think this is part of why these things can take so long at times, because one, our first step is going to be to try to apply all of the methodologies, the processes that we have used in the past that have worked because why not? I mean, that just makes sense. You want to go through the things that are the known quantities so that you can essentially verify that those don't work before you go out and try to create one on your own. And then creating one on your own is, as I said, it's its own challenge because you really, you don't have a starting point. You don't have anybody to tell you, here's what you need to start with. And this is why the first time it is hugely an educational experience when you're just simply, you know, as they say, thrown into the wolves and you have to figure it out. The first time you do it is going to be very, very painful, very challenging. But once you've done it once, the next time will be easier and the next time will be easier. And that's not to say that it ever gets fun or easy, but it does become something that you recognize as something that's possible. And it does increase your optimism as you optimism, as you go over time. A third thing and sort of the last thing I want to look at from the positives of this, because I think the first two are so important, but I think the last two are so crucial and so important to think about when you get, you know, you stumbled into this situation next time. The third one is that it really, this situation really forces you to thoroughly examine the problem, a situation. There are many, many times that we can go through our jobs and our careers and our lives and have problems that we can just do like a surface level scan. And you basically, you know what it is. It's like, okay, let's start applying our patterns and we go into it and we fix it and we're done and we move on. And we may actually solve problems where we haven't really dug that deeply into them because they fall into this nice category where we don't really need to know all the details. We just apply the processes and boom, it falls out on the other end. It works. Actually having to spend time and really dig down and understand a problem is an educational experience that is really, we just, we don't have much else to compare about it. And when you think about what we did back, if, if you've got a degree, if you went through college, when you, and even going through school, you think about the topics that you've learned over time, we start from, you know, from scratch. We start with nothing and we build and build and build and build on our knowledge. And that's what we get to do in this case is we need to, we get to return to that level of figuring out all the inner workings of this problem. You know, maybe we get to a solution before we get there, but a lot of times Mike, maybe it's just me, my experience. That's not the case by the time I'm done. I know that thing inside and out, and there is a lot that can be learned by spending that kind of time on anything on a process, on a system, or dissecting a problem to get to that solution that you need the skills required to be able to dissect, you know, at that level are valuable in themselves, but actually the process and what you learn in digging into something like that is the kind of thing that can actually separate you from being just someone who knows it to someone that would be, you know, we'll call quotes a master that you have mastered that. And that itself is a valuable thing to have, you know, the more you can master, the more you have tools and environments and situations that you can jump into. And you don't have to worry about getting lost and starting from scratch. You already have the tools to avoid that problem. And that itself may be one of the main reasons why we see that new developers can be dramatically less productive than experienced developers. I think I've seen stuff where experienced developers can be, you know, 10 times as productive as, as entry level developers and programmers. And that's because all of those processes and methods and procedures have been, you know, basically ingrained into that senior developer's head to the point where they don't walk into stuff very often, or, you know, maybe at least less often where they have to start from scratch. Versus that new developer that does that on a much more regular basis, again, more or less by definition. I mean, if you haven't seen as much, then there's going to be, yeah, it's more like you're going to run into something new. If you've seen more things, it's less likely that you're going to run into something new. That being said, I think we can wrap this one up and look at the challenge of the week. The challenge of the week is to think about what you're going to do. The challenge of the week is to think back to the last time you fell into one of these holes where you had a problem that took days, weeks, maybe months to solve. And if you can remember it, if you haven't just blacked it out in your memory, think back to what that was like, as far as what did you learn? Do you think that you came out of that much more knowledgeable about that situation, that environment, that problem? I'm guessing that you did. And so it's something to hang your hat on next time when you go into another situation is to know that there may be a lot of work ahead, but there may be a big prize at the end as well. Another big win for you and more than a smiley face or a gold star. That being said, gold star, smiley face, or whatever emoji you choose, go out there and have yourself a great day, a great week, and we will talk to you next time. 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. Thank you for listening to building better developers, the developer podcast. For more episodes like this one, you can find us on Apple podcast, stitcher, Amazon, and other podcast venues, or visit our site at developer.com. Just a step forward today is still progress. So let's keep moving forward together.