178 What Are The Steps To Quickly Debugging An Application?

How do I quickly debug an application? What are the steps to take to find and fix a problem in my code? These are the questions we will answer in today's episode of Dev Questions. 

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator Tim Corey.

SPEAKER_00 0:25

What are the steps to quickly debugging an application? This is a question asked on the suggestion site, and it's one I thought would be a great question to answer in today's episode of DevQuestions. Now, every bug is a learning opportunity. So let's start here. Don't waste it. Don't waste the opportunity to learn something from this bug. So trying to escape early, trying to just get somebody else to fix it for you. These are ways to keep your growth stunted as a developer. The way to grow as a developer is to learn how to debug by working through the tough stuff. If you always try to escape the tough stuff, you'll never be strong enough to stay on your own. So you want to make sure that you work this list in order. Okay? So don't just waste the debugging and stunt your growth. Instead, I'm gonna go over the six steps you should take to quickly debug an application. If you do them in order, you'll have a lot of success and you'll note that getting help doesn't come in till the end. Okay, there's lots of things that you can do regardless of your skill level. There's lots of things you can do to learn how to debug earlier and more quickly. Okay? So you're gonna struggle through this. This is going to be a struggle. It almost always is a debugging. Debugging is just, it's one of the things that developers have to do. It's the thing that I struggle with because you're always gonna have these weird bugs that you don't understand, you don't know why they're working the way they are. And it seems like you know, you never get simple bugs. It's gonna happen, and what's gonna happen is you're gonna figure out how to solve those, and then that will become a simple bug after a few times. And so you never have that again because you've learned how to avoid it in the first place. You've become a better developer. Okay? So work these steps and don't skip steps. Okay. The only time you ever skip a step is if you solve the problem. Okay. If you get through step one and you solve the problem, cool. No need to move on to the next step. Okay. But otherwise, go through these one by one. This will also help you, by the way, when you get to the point of asking questions, you will have the right information to give somebody to make them not upset at you, to give them something that shows that you have put the work in yourself. Okay, number one, and here's where a lot of newer developers, especially, fall down. They fail this step and then try to go on a step two. So don't miss this. Step number one, clearly identify the issue. Don't just start trying to fix it. Identify what the problem is first. Okay? That means that when your system pops up an error message, don't just go, oh no, I got an error message, close it out, and say, now what? You've you've missed part of the first step, which is to read the error message. The error messages today actually tell you, in a lot of cases, they tell you what the problem is. Maybe not the root problem, but they tell you what their problem is. Things like uh we have a type mismatch, or we um have you know bad data, invalid data, or whatever the case may be, they tell you some type of message that gives you a clue as to what is going on. So clearly identify the issue. Read the error message, write it down, not paraphrase, get the actual message. That way, if you do end up Googling, we'll get to that later, but if you Google it, well, then you have the actual error message to put in there. So you get an actual result, not you know, no results because it's not the actual error message, it's just an approximation of the error message. Um, reading log statements. If you have logging going on, and hopefully you do, then read the logs, see what happened. Watch what happened up to that point, see what was going on, identify the state of the application. So, for instance, if you can, if you know where the error is, put a breakpoint there and then run the application again. And when it stops at that breakpoint, you hopefully know that the error is coming next. Before you get to that error, look at what are the variables holding, what information do they have, what data is in memory, what's it working with and working on to understand what was the state of the application when it broke? And then identify which action triggers the issue. So is it certain input, is it certain time, etc. Okay? So try and figure out what's causing this, what the actual issue is, where the issue is, you know, anything else you can find about the system, the state of it at the time. Now, that's step number one. And again, you may find the issue at that point. Okay. But if not, then number two, recreate the issue reliably. So this is where you might say, okay, it looks like whenever I try to insert data into this table, the application crashes. So create a little test application. The only thing it does is inserts data into your database, wherever the problem was, and see if it crashes too. And if it does, you have a simple recreation of your application. Not all the bells and whistles, not all the proprietary stuff, not all of the stuff that shouldn't matter, just the actual thing that causes the problem. Try and recreate reliably. So set up a test environment. Verify the error occurs in that environment. Because if you know where the error is and you know what's going on at the time of the error, you should be able to recreate it in another environment, in a clean project. And if not, well, then you're missing some kind of context. Like, is it that machine? Is it some kind of configuration on that computer? Is there something I'm assuming that's not the case? Like, for example, maybe you're assuming you have a connection to the SQL Server and it accidentally has a connection to the MySQL Server. And that's different. Maybe that's it. Okay? So try to recreate in a test environment. And that's going to help you down the road when it comes to talking to people as well. At least now you have an example of the problem. Now, once you have an example of the problem, or if not, once you're figuring out how to recreate in the actual environment that crashes, step through the code to observe the issue. This is where you can use breakpoints or advanced breakpoints. For example, a breakpoint just pauses your code at a certain spot. An advanced breakpoint might just count how many times the breakpoint gets hit. So we can say, hey, I've got this loop. How many times does it get hit? I'm expecting 100. And then you put a breakpoint after the loop and count the previous breakpoint and says 10,000. And you're like, ah, that's not right. Or it might say two and go, ah, that's not right. So now you use advanced breakpoints to give you more information. Use debugging log statements. So you can put debugging statements in your code to say this method was hit, this method was hit, this method was hit, and go on down a list. Or say, hey, here's a data at this spot, here's the data at this spot, and get more information about every step along the way where you may find, hey, wait, we're missing a method call in here. That method never got called, or this method got called, but then it short-circuited the process, or whatever the case may be. It helps you understand what's going on. And then this is also helpful sometimes, is to talk through what each line will do and what the inputs and outputs will be. So out loud, this may be where you bring the rubber duck in. You talk through every line what you think the compiler is going to do. This may be tedious, maybe slow, but what it helps you do is when you're talking out loud to something, even a rubber duck, that when you're talking out loud, you kind of reveal some of your assumptions. Where you go, and then the file gets loaded, and you're like, wait, wait, wait, what file? Where did that file come from? I don't have the file. Oh, we're not loading the file. There's the problem. Okay, so by talking it through, you start talking through your assumptions. Okay. Number four, break apart the system. So if you have this long, complicated process and it's breaking somewhere in there or it's it's breaking at one piece, break apart and test each section independently. So this is where unit tests can be really helpful. You validate multiple inputs and outputs for each little piece, each little unit along the way, and attempt to create the error in a specific method. So maybe you've narrowed it down to a section, now break it down even further into a specific method. So you can say, okay, when I pass in a to and a you know, test is the word, that breaks something. Let's find out why. Okay. And so then you can create a unit test to test that and say, yep, that's when it breaks. So, and then replicate that problem in a new application. Okay. Again, we're trying to pull this out into a test project. Recreate the problem in a new application, make it as simple as possible, make the code generic and non-proprietary. This is where you find out, oh, some of that proprietary code, some of that really tricky logic we created. Well, that doesn't actually work. And that's what's causing the problem. Because if you try to recreate with some generic code and you find out, well, that works, then why doesn't ours work? Maybe you've been calling your internal company DLL, and it does some things for you like truncating strings and you know doing all uppercase in your string, whatever it's doing, right? And you're calling that over and over again. Well, take that out and put in your own code in that section and just see if it still has a problem. Because then you're eliminating some issues and you've got something to recreate. And this is where step six comes in. Talk it through with someone. Start again with that rubber duck. So the overall, the problem, how you recreate it, the whole thing. Talk it through with someone, start the rubber duck, because it's, you know, you can take up as much time as you want with that rubber duck. But what'll happen is you'll start talking through what's going on and it might trigger something. Then talk to a coworker or a friend. Doesn't even have to be a developer. Just talk to someone, say, hey, this is what I'm doing. Just listen. And maybe it might ask a stupid question that triggers something. Okay. Only after all those things do you then go talk to the internet and say, hey, internet, I've got this problem, because maybe there's a bug in the system. Maybe there's a bug in.NET that's causing the problem. Now, most likely the answer is no, the problem is in your code. But by going through all those steps first, you'll have all the information about how you can recreate it, what the error was, what the log statements told you, what the process was, the actual code you could give someone, because it's generic and not proprietary, and it recreates the problem that you can show someone and they can test it and see the problem too. Because then they can say, okay, here's all the work you've done. I can see that. And it's still causing this problem. Okay, I spot the problem and I'm gonna feel you know fine about sharing it with you. You know, we all have blind spots. We all don't, no one knows everything. And so, sure, you know, I spotted a problem, I realized, oh, you didn't realize that in this case, this happens. Okay, not a problem. You've now learned something new and you fixed the problem. Or they realize, hey, I can't get this solved either. Looks like it is a problem with the overall system. We can escalate that up to, let's say, Microsoft support, and they can look at it. So, but by doing all those steps first, you have reworked the problem. You have tested things out, you've gone as far as you can go, and you have made sure that you have a full understanding of everything you can about what the problem is and how it operates. Knowing all of that will help you solve most of your problems. But if you can't solve a problem, knowing all of that will help you communicate clearly in a way that shows this is not a homework question. This is not me just trying to avoid work. This is I'm stuck, I've done all the work I can, and I just need someone to help me out. And it's much more likely that people will be willing to help you out if you do those steps. I have seen people complain about things like Stack Overflow. I have never had a problem with Stack Overflow. I have asked multiple questions on Stack Overflow. I have asked questions to Microsoft employees before. I've never had a problem. I've never had people get angry at me or downvote me. And part of the reason why is because I don't come to them until I've gone through steps one through five thoroughly. I don't go to step two until I understand fully the answers to step one. I don't go through to step three until I understand fully the answers to step two. And I go through step by step by step so that when I'm done, when I ask a question, it's thoroughly documented. I have this long list of information. Here's a system I'm on, here's the versions of everything I'm using, here is the recreation spot where I've recreated the problem. Here's the code I'm using, here's the error message I'm getting, here's the problem, here's like I summarize everything, then I have all the details so that people know this is what my problem is. And that tends to, I won't say it always will, because there's always angry people on the internet, but it will help with that process. I also talk to others first before I just go ask a random stranger on the internet. I try and ask my coworkers and my friends first for help before I go out and ask just random people. Okay? So this process will take you time. You will struggle through this process. And when you start working the process, you might not understand the whole thing. You might take a lot of time getting through steps one through five. That's okay. Take the time, don't shortcut the process. Like I said, this is how you become a much better developer. This is how you become a senior developer. Okay. This is part of the process, is understanding how to debug a system. And it's not just go ask somebody else. Okay. Learn to do it on your own. Learn to build this skill up. You will always have problems in your code because you don't write perfect code and neither does anybody else. So you're always going to have these problems. You're always going to have to work through them. But the more you can work through it yourself, the more you build up this skill, the faster you will be at debugging problems. The less you will write actual bad code because you will have seen it and you'll have learned how to fix it ahead of time. And the better you will be at moving through an application and making those fixes. Okay? So those are my six steps. I encourage you to follow them. Take the time to work through them and make sure you really understand the problem and how to recreate it before you go and get help from someone else. Thanks for listening. As always, I am Tim Corey.

SPEAKER_02 16:59

Thank you for joining us for this episode of Def Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at Iamtimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.