If you have done any programming, you will have debugged the code. Without learning to debug, you cannot be a programmer. But have you spent hours looking at a piece of code only to find the problem is elsewhere? Have you pulled your hair searching for the offending line of code? Have you ever cursed the day you decided to learn programming as you cannot find the reason for a particular bug? We have all been there. But it doesn’t always need to happen when you are coding. There are strategies you can use to find the issue quicker. Reproduce the issue This is the first step in any debugging process when you have found a bug in existing code. It becomes very challenging to fix the issue unless you can reproduce it on your laptop. So find ways to reproduce the issue in your development environment a.k.a your laptop. This is important as then you can leverage the powers of your IDE to do quick debugging. Now, there are scenarios when this is not possible. One example is that your laptop does not have all the integrations required to reproduce the problem. This can happen when you are working in a distributed architecture. You can use remote debugging to overcome this issue. Isolate the problem To effectively debug, whether it's your own code malfunctioning or an existing bug, the key is to isolate the problem. Aim to pinpoint where the issue might lie. One effective strategy is to thoroughly test until you're confident the code operates correctly. There are several methods to achieve this goal. In most programming languages, simply logging into the console will give you an idea as to when the code is working fine. But this process is tedious. So you need to find markers that will tell you when the code is not dodgy. This could be reading the code you are debugging as it will also help you understand the flow. The other option is to take help from the existing log statements. You could also add breakpoints which I mention as the next step. But that will mean a longer debugging process. The idea is to get into the vicinity of the code where the bug might be. Use breakpoints Once you are in the vicinity of the code, use breakpoints. As you have isolated the problem in the last step, you can add a breakpoint just before the point where you think the problem code is present. This is powerful as you don’t need to g through the code one line after the other. Step through the code and inspect the variables Once you reach your breakpoint, start stepping through the code. Also, add a watch on variables that will change state during the process. This will help you understand the behavior of your code. Experiment by changing code on the fly You might already have a suspicion of where the issue could be. Advanced IDEs can help you change your code on the fly to test the outcomes of those changes. This will give you a better understanding of whether the code you think is dodgy is dodgy. Read Documentation Sometimes, you might know what a method is doing in your code. But it just helps to read the documentation one more time. It helps you re-visit your understanding. Sometimes, a re-read of a line in the docs provides you with the solution to the problem. Rubber-ducking What you do here is imagine a duck and start explaining the code you are troubleshooting to it. Logical flaws show up when you verbalize your understanding and listen to your voice. You can use this technique even to isolate the problem. Call a friend Yes, if nothing seems to work — call a friend. This is the next level of rubber-ducking. In rubber-ducking, you are talking to an inanimate object. When talking to a friend, you can get feedback and get ideas on what other options you can try. Tips to avoid getting into debugging hell-hole Write clean code. Yes, write code the way you want it when you are debugging. Other tips are: Use method names that will help you understand what the method is doing Put in log statements so that you know what’s happening in the code Use meaningful variable names Follow SOLID principles Follow the DRY principle Add unit tests Join my substack like other passionate developers where I send weekly nuggets on how to improve your developer craft 1 week at a time If you have done any programming, you will have debugged the code. Without learning to debug, you cannot be a programmer. But have you spent hours looking at a piece of code only to find the problem is elsewhere? Have you pulled your hair searching for the offending line of code? Have you ever cursed the day you decided to learn programming as you cannot find the reason for a particular bug? We have all been there. But it doesn’t always need to happen when you are coding. There are strategies you can use to find the issue quicker. Reproduce the issue This is the first step in any debugging process when you have found a bug in existing code. It becomes very challenging to fix the issue unless you can reproduce it on your laptop. So find ways to reproduce the issue in your development environment a.k.a your laptop. This is important as then you can leverage the powers of your IDE to do quick debugging. Now, there are scenarios when this is not possible. debugging One example is that your laptop does not have all the integrations required to reproduce the problem. This can happen when you are working in a distributed architecture. You can use remote debugging to overcome this issue. Isolate the problem To effectively debug, whether it's your own code malfunctioning or an existing bug, the key is to isolate the problem. Aim to pinpoint where the issue might lie. One effective strategy is to thoroughly test until you're confident the code operates correctly. There are several methods to achieve this goal. In most programming languages, simply logging into the console will give you an idea as to when the code is working fine. But this process is tedious. So you need to find markers that will tell you when the code is not dodgy. This could be reading the code you are debugging as it will also help you understand the flow. The other option is to take help from the existing log statements. You could also add breakpoints which I mention as the next step. But that will mean a longer debugging process. The idea is to get into the vicinity of the code where the bug might be. Use breakpoints Once you are in the vicinity of the code, use breakpoints. As you have isolated the problem in the last step, you can add a breakpoint just before the point where you think the problem code is present. This is powerful as you don’t need to g through the code one line after the other. Step through the code and inspect the variables Once you reach your breakpoint, start stepping through the code. Also, add a watch on variables that will change state during the process. This will help you understand the behavior of your code. Experiment by changing code on the fly You might already have a suspicion of where the issue could be. Advanced IDEs can help you change your code on the fly to test the outcomes of those changes. This will give you a better understanding of whether the code you think is dodgy is dodgy. Read Documentation Sometimes, you might know what a method is doing in your code. But it just helps to read the documentation one more time. It helps you re-visit your understanding. Sometimes, a re-read of a line in the docs provides you with the solution to the problem. Rubber-ducking What you do here is imagine a duck and start explaining the code you are troubleshooting to it. Logical flaws show up when you verbalize your understanding and listen to your voice. You can use this technique even to isolate the problem. Call a friend Yes, if nothing seems to work — call a friend. This is the next level of rubber-ducking. In rubber-ducking, you are talking to an inanimate object. When talking to a friend, you can get feedback and get ideas on what other options you can try. Tips to avoid getting into debugging hell-hole Write clean code. Write clean code. Yes, write code the way you want it when you are debugging. Other tips are: Other tips are: Use method names that will help you understand what the method is doing Put in log statements so that you know what’s happening in the code Use meaningful variable names Follow SOLID principles Follow the DRY principle Add unit tests Use method names that will help you understand what the method is doing Put in log statements so that you know what’s happening in the code Use meaningful variable names Follow SOLID principles Follow the DRY principle Add unit tests Join my substack like other passionate developers where I send weekly nuggets on how to improve your developer craft 1 week at a time Join my substack like other passionate developers where I send weekly nuggets on how to improve your developer craft 1 week at a time Join my substack like other passionate developers where I send weekly nuggets on how to improve your developer craft 1 week at a time Join my substack like other passionate developers where I send weekly nuggets on how to improve your developer craft 1 week at a time
