3. Delete the buggy code
I don’t know about all other programmers, but I don’t dare to claim that my code is free of bugs, especially during the first several versions of the projects. After tens of rounds of iterations, I may sometimes come up with a project that has no known bugs — there is always a chance that bugs emerge beyond your control, such as a bug existing in the frameworks that you’re using.
Having virtually no hope of writing a bug-free program, let’s face the fact: our programming life is basically an ever-lasting battle with bugs in our code. Do we surrender to bugs? No, never. They are bugs, and we’re humans. I know humans can’t lose to bugs, even though sometimes, I couldn’t find the mosquitos that bit me. I would still use anti-itch gel to destruct their aftermath, so I didn’t lose, technically.
I’ve self-learned several programming languages, including Objective-C, Swift, Kotlin, and Python. However, I haven’t seen any materials from the official documentations that teach us how to debug. I bet that there must be some tutorials out there that I don’t realize on debugging.
Here, I want to use my background in a variety of languages and share ten things that we can do from a generic perspective. Please note that these ten things are not totally exclusive — certain aspects are more related than others, and there are overlaps between some points.
Having a bug in your code isn’t frustrating to most of us, because we expect that our code will have bugs here or there. What’s most frustrating is that the bug can’t be reliably reproduced. In a large project, code complexity can be enormous. Only if we can reliably reproduce the bug, we can evaluate what’s going on with our code.
This is pretty much like a doctor seeing a patient. The doctor would like to hear about the symptoms of the patient. The symptoms are something that consistently happens to that patient, such that the doctor can evaluate the possible underlying causes.
When we’re able to reproduce the bug, we should evaluate the bug. For developers who’re familiar with the codebase, it’s usually not too hard to figure out which part might be problematic.
When you’re trying to locate the issue, one assumption that you shouldn’t have is that part can’t go wrong. Instead, you should assume that every part that is related to the bug is a suspect. Review them carefully and use helpful debugging tools to study your code — as if it’s the first time that you run the code, such that you will have no biases regarding what code can have bugs.
When we identify the issue, the next step is certainly to remove the bug. Many people may have the thought that we have to “fix” the issue. This is what my first reaction was when I was a newbie in programming. However, after millions of lines of code (I just guesstimated…), I realize that in many cases, the buggy part may be unnecessary to begin with.
Thus, instead of coming up with a solution, you’ll simply delete the related functionality that has the bug. Sounds crazy? Not at all. Next time, when you have a bug, think about the possibility of dropping that part entirely.
If you decide that the code needs to be kept, it’s time to fix the issue. There are different ways that you can come up with a solution, which I’ll talk about later. However, the best approach is to generate a solution yourself by studying the code thoroughly.
Every programmer must deal with bugs throughout the development phase of any project. Particularly when a programmer is a junior, the best learning opportunity is to fix all the bugs — through these processes, your code analysis capability will be dramatically improved.
Over the decades, the internet has become a place where almost all information can be found. When you come up with a bug and don’t know how to solve it by yourself, there is a good chance that a similar issue has been reported by someone else.
The hard thing is how you can describe the issue accurately such that you can find related information. You may have to try different search phrases before you can finally find the things you need. If you use a particular framework or product, there might be dedicated discussion forums where there is a higher likelihood to find relevant discussions.
If you can’t find any existing solutions to the problem that you’re having, it’s time to consider asking for help. The easiest way to get the ball rolling is to ask the question online. The best, well-known place is Stack Overflow. Actually, when you search your issue online, it’s very likely that you may have browsed some questions posted on the Stack Overflow website.
Asking the question in the right way is essential to get help. You may want to provide as much information as you can. The more you provide, the more others can understand your question. Some people may come up with a direct solution. Even if they don’t have a ready solution, the detailed information you provide will allow them to reproduce the bug if they want, which will help others investigate the problem for you if someone really wants to help.
I hope that you’re not the only one on your development team. It’s always fun to work on a team to see how teamwork produces fascinating results (when it works…). If you’re not the most senior in your team, you can try consulting a senior developer which may have more insight into the project.
Although a bug may appear to be local, it’s very likely that it’s related to other parts. You can’t really isolate a bug that is independent of any other parts. Thus, senior developers have a better view of the project, from a higher perspective. Senior developers can provide good advice that can help you reorganize your thoughts, which may lead to a working solution.
What if you’re the most senior programmer, and you don’t have a senior co-worker to ask for help? It’s OK. You can bring it to a team meeting, when all developers attend. Even though all other developers are more junior to you, it doesn’t mean that they know less than a senior developer. Sometimes, junior developers are as good as senior developers except that they may have less experience.
When you bring the issue to the meeting, everyone can participate in the discussion. When people exchange their thoughts, with the escalation of the discussion, chemical reactions will happen, which can lead to unexpected positive outcomes.
If the bug is related to a framework or a product that you’re using, you can report the bug to the development team. However, it should be noted that you don’t bet your life on the support. Most of the time, the responses can be slow, especially if the bug is rarely reported. From their perspective, they’ll assume that it has less to do with their product.
However, because of their expertise on the related topics, if the bug is indeed due to their product, they may probably come up with a working solution.
After you try all sorts of things, you finally solve the problem and remove the bug. It’s certainly time to celebrate. Your celebration should start with a complete report. In the report, you’ll describe the bug with detailed information. For instance, who reported the bug? How was the bug reproduced? How was the bug identified and located?
All these pieces of information are important references for future development. Together with the description of the bug, you should also provide information about the fix. What’s the fix? Who came up with the fix? What does the fix change?