One of the skills that you will always need to get better at is debugging. No matter how good of a programmer you are, the most difficult bugs that you face will always be your biggest learning opportunities as a developer. And in today's episode, we're going to talk about some strategies for debugging stubborn bugs. This particular episode is actually inspired by a few debugging sessions that I've had recently. And I realized that I was doing a few things kind of instinctively that I've learned over the years that I feel like are worth kind of formalizing in today's episode. My name is Jonathan Cottrell, and you're listening to Developer Tea. My goal on the show is to help driven developers connect to their career purpose and help them do better work so they can have a positive influence on the people around them. And in today's episode, we're getting extremely practical. We're talking about debugging. It doesn't get much more hands-on than that. Of course, this show is not always about hard work. It's not always about hard work. It's not always about hard skills. For example, in the last episode of Developer Tea, we talked about thinking about the future and thinking about your place in the future and your purpose and how it took you to that place into the future. And I encourage you to go listen to that episode, but we're kind of doing a 180 in terms of style today. So I'm really excited to talk about this because I think that debugging is really an incredibly complex thing that evolution has taken evolution from evolution to evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution totally different kind of bug. And so it doesn't really help us to think about debugging as just a mistake that we make. A lot of the time it is a misunderstanding, a blind spot, or it's some kind of consequence that we weren't able to fully evaluate. So it's not so much about writing bad code. Usually it's about investigating how your reasonably formed okay code is causing a problem. Now of course that's not to say that we don't make silly mistakes. Like for example, I was writing some code yesterday and I made a spelling error. And of course that caused all of the entire application to fail. And these things happen. You're going to miss a semicolon here or a comma, a trailing comma, and some JSON somewhere. And it'll break the whole system. Or it'll break half of the system. And you have to go and find that. So there are things that can help us with those kinds of mistakes. But a lot of the time the mistakes that we make as developers are the ones that we make the most. And that's why we're so much more likely to make mistakes. Have less to do with syntax and more to do with some kind of information flow. So we're going to talk about how we can debug these things. And sometimes, by the way, those bugs also, and this is driven by a recent experience I had, those bugs are also because of an interaction with an external system. Your internal system may be written perfectly fine, but because of some interaction with an external system, something goes wrong. So we're going to talk about two specific strategies. And they're really complementary strategies. You kind of do one and then you do the other. We're going to talk about those in today's episode. But before we do that, we're going to talk about today's sponsor, SkySilk Cloud Services. SkySilk is a new cloud hosting platform looking to shake up how businesses and developers approach cloud computing. You can spin up a virtual private server in just a few seconds. You can choose between popular Linux operating systems like Ubuntu, CentOS, and Debian, as well as 40 different services. You can also choose between a virtual private server and a virtual cloud operating system. You can also choose between a virtual private server and a virtual cloud operating system. You can also choose between a virtual private server and a virtual cloud operating system. You can also choose software applications like WordPress, Magento, and MySQL, among many others. You can create and host your own website. You can have a blog or an application or script. All of this is super simple with SkySilk. They're currently beta testing their new cloud platform, which means that everything is completely free of charge in exchange for feedback and testing. So it's a great time to get in on the ground floor and try out their brand new service. One of the really interesting things about SkySilk is that they offer a rewards points system. Now this sounds like something from a totally different industry, but as it turns out, when you sign up and use their platform, you can use the points that you accrue with a SkySilk account credit, right? So in other words, you can pay for your SkySilk services with your points, or you can redeem them for real rewards like Visa prepaid gift cards, for example, or Amazon gift cards. And they have more reward options coming. Now, developer T listeners can use the code T time, all one word, all caps T time to redeem a thousand sky points, which is equivalent to $10 cash back or account credit available for redemption when the SkySilk platform goes live later this summer. Head over to SkySilk.com to sign up for the free beta. That's totally free and use the code T time. That's all one word, all caps T time to redeem those 1000 sky points. Thank you again. SkySilk for sponsoring today's episode of developer T. So we're talking about two strategies, two real quick strategies to use when you're debugging. And since some people may be listening to this and you need to get to the debugging session, we're going to keep this episode short today. The two strategies, and they go back to back. You're going to do one before you do the other. Number one, isolate your problem. Isolate your problem. This is something that very often developers wait far too long to do. If you have a bug in a system, if you can isolate whatever's creating that bug, or if you can take the code that you believe is responsible for the bug and remove it from the system, right, or delete the other code around it somehow. Typically, you can spin up a quick instance, maybe a interpreter of some kind, or if you're doing something like a React project, for example, have a test React project that you can delete, all the components except for the one that is causing you trouble. Once you pull out the code, if you can isolate the problem and it still exists, then now you have a little bit more of a clean space to actually work on the problem, to figure out what exactly is causing that problem. And typically, when you pull the problem out of its context, you either change the problem, in other words, the problem is either no longer there or it's different in some way, or you find that the code that you thought was responsible for the problem isn't actually responsible for the problem. So this helps you take another step towards the code that actually is responsible. And once you find the code that is responsible, I still believe you should pull that out and isolate it. Now, if you're an experienced developer, then you know that this can be hard sometimes. But what this will require you to do, and this is a good thing, this will require you to write your code, to design your code in such a way that you can pull. pieces of that code out that you can take a component, for example, and plug it into another place. If you're developing your code in a sufficiently modular way, such that, you know, your classes or your components or your functions or whatever it is that you're writing, whatever style you're writing in, if you're developing your code modularly enough, you should be able to take that piece of code out of your code base and put it into a test scenario. And if you're doing that, you're going to have to do a lot of work. So if you're developing your code in a too reliant upon other pieces of your system, then this process of debugging will necessarily require some refactoring. And again, this is a good thing, because very often in the process of refactoring, you uncover what the bug was. So once again, the first strategy, the first step that you need to take is to isolate the bug, isolate the bug. Now, at this point, you're going to walk down the normal strategy. You're going to walk down the normal strategy, and you're going to walk down the normal strategy. You're going to walk down the normal strategy. You're going to walk down the normal strategy. You're going to walk down the normal strategy. You're going to typically would use to debug. For example, duck debugging. You can talk through your code, explain exactly what it's doing. Walk through every step. If there's a loop, count how many times that loop happens. If there's a conditional, explain that conditional in as clear language as you can. And don't take anything for granted in this process, right? Use your normal debugging skills. If you have a lint or use a lint, you're going to walk through every step. If you have a So we're not going to talk about all of the specifics of the isolated debugging that you'll do, although there's plenty of really cool strategies that you can use. But if you pull that code out and you see that the system that you've pulled that code out from works when that code is gone, and in your isolated scenario the bug is gone, then something about the interaction between that code and your system, the rest of the code, something about that interaction is causing a bug. So the next strategy is integration. Integrating your code back in from the isolated scenario, integrating whatever that solution is, back into your original code base. And quite often what will happen is instead of integrating it all at once, all wholesale, you can use a strategy like a piecemeal integration. So integrate one piece at a time. Or, if you're like me, you can use kind of a divide and conquer method. So first start with the whole thing. If that doesn't work, then try the first half, right, the first half of the code. And if that doesn't work, try the second half of the code. And of course, keep in mind that you can't put in half of a method. You can't cut a class in half and expect that to work. So that's not what we're talking about. When I say divide and conquer, what I mean by this is taking the logical pieces that can work, and run sequentially that don't have dependencies above it, and integrate those. Integrate the pieces that work so that you can isolate, further isolate the pieces that don't work. This strategy is particularly useful when you're working with external platforms that are causing bugs and you can't seem to track them down. Unexpected sources of bugs, for example, you may find a bug in a library or an interaction between two libraries. As a result, you can't track down the bugs. You can't track down the bugs. You can't track down the bugs. You can't track down the bugs. This is a very common scenario. You have one library that is doing some work, then you have another library that does some work. And when you put them together, there's a naming conflict or some kind of interaction, some system level conflict. And unless you were particularly familiar with that conflict, it may be very difficult to find that bug. So quite literally deleting code out until you don't have the bug, and then reintroducing that code back again, in piecemeal parts or in small half sections until you find the piece of the code that is causing the bug. Of course, this totally ignores the opportunity of using debugging tools to help you along the way. There are plenty of excellent tools that could help you along the way or give you warnings, for example, when you're using two libraries that aren't necessarily compatible, that have known compatibility issues, especially. But really, this process is not only about debugging, but it's also about software design. If you think about all of your software in terms of its modularity, if you can make a piece of code work on its own in an isolated environment and then plug it back in. In other words, now that it works on its own in an isolated environment, you can put it into your code base with much more confidence. And if you do this for all of your code, if you pull out most of the pieces of your code and make them so that they are modular, so that they can be composed together, then you're much more likely to be able to isolate and fix the bugs that you encounter. All of this is based on the same principle that we've talked about over and over and over again on DeveloperT. And that is, when you have a problem, try to break it down into the smallest version, or smallest pieces of that problem, the sub-problems. The smaller the problem, the more easy it will be to solve, and the more powerful the solution will be in the long run. So when in doubt, make things smaller. Make things smaller. Thank you so much for listening to today's episode of DeveloperT. Thank you again to SkySilk for sponsoring today's episode. Head over to skysilk.com. Don't forget the coupon code TTIME for the $1000. Thank you. The $1000 sky points that are redeemable whenever their full service launches later this summer. Thank you so much for listening. And if you haven't subscribed yet in whatever podcasting app you're using, then it's very possible that you will miss out on future episodes. And I don't want that to happen. Hopefully you don't want that to happen either. Go ahead and subscribe so you don't miss out. Thanks so much for listening. And until next time, enjoy your tea.