10 debugging cheat codes for faster bugfixing

Yesterday,

We had a company Xmas party.

Before dinner at a restaurant, we went to the escape room event.

If you are unfamiliar with escape rooms, they’re interactive puzzle experiences where you and your teammates are “locked” in a themed room and must solve clues to escape within a time limit.

It’s a fun challenge that puts you in a detective role. It tests your creativity and problem-solving skills.

(we almost solved it…)

In many cases, debugging is like being the detective in a crime movie where you are also the murderer.
But since there is a lot of existing code, you need to know how to debug it when fixing a bug.
Here are 10 tips on how to debug and resolve any mystery in your code.

1. Identify a list of reproduction steps (“Interrogate the witnesses” approach)

Before you can fix the issue, you need to know two things.

First, you need to know how to reproduce it. In some past projects I’ve worked on, the bug tickets we got contained a list of steps on how to reproduce it. Or a video containing the steps.

Obviously, not every project will have this. But it speeds up bug-solving tremendously.

Second, you need to understand what the expected behavior is. Clarify and confirm this before you start fixing the issue. So you don’t fix the wrong thing.

2. Write a test that reproduces a bug

How to make debugging less time-consuming?

When you have a scenario where a bug occurs, you can write a test for that. So you don’t have to go through the UI every time to get to the code that contains the bug.

I call this the “Peace of Mind Method”:

1. Write a test for the bug you want to fix.
2. Run the test and confirm it fails.
3. Change the code to fix the bug.
4. The test passes.

With this technique, the same bug won’t occur ever again.
You get one more test.
And one less thing to worry about.

3. Use debugging tools effectively

Using debugging tools in 2024/2025 goes beyond just stepping through the code.

It means:

• Edit and continue
• Capturing variable values
• Inspect and navigate through call stacks
• Evaluate expressions in the immediate window
• Using breakpoints in code and set breakpoint conditions

Just to name a few.

Debugging tools got powerful. Learn how to use them.
However, debugging only covers the current state of code. For more information, you need…

4. Browse through code history

Debugging, although powerful, will only help you understand the current state of the code.

Another useful method for identifying the bug is going through the Git history and checking how the code has evolved.

If the bug is fairly recent, you can inspect only the commits between now and the last version that didn’t have a bug to identify the issue.

5. Use the divide and conquer approach

The divide and conquer approach is a method for identifying the root cause of a bug by breaking down the problem into smaller parts.
And narrowing the scope of the investigation step by step.
This technique is useful when you can’t exactly debug the whole execution flow line-by-line.

To perform it, you do a binary search for a bug:

1. Split the code into two halves.
2. If the bug is present in the first part of the code, focus on the first part.
3. If the bug is present in the second part of the code, you focus on it instead.
4. Next, take the half where the issue is and split it again into two halves.

Using this approach, you can quickly identify the section of the code where the issue could be.

6. Use AI to help you

This is pretty self-explanatory. But for the sake of completeness, I’ll mention it.

Before the AI era, you usually pasted the error message in Google and searched in Stack Overflow for an answer. Nowadays, you can put the code snippet or an error in the ChatGPT and ask him to identify the potential issue.

Based on my experience, this can be a hit-and-miss.

It will pinpoint the obvious issue you have missed while investigating. But it can struggle if the code is more complex.

Either way, it’s worth trying.

Speaking of your tries….

7. Keep a list of what you have tried

If you keep the list of approaches you’ve tried, you can avoid repeating the same steps. But expect different results.

Also, when you ask a team member for help, you can tell him what you tried. So that you skip those suggestions.

8. Don’t assume the error is in 3rd party library

If you don’t fully know the 3rd party library your code is interacting with, you might assume that the bug is in the external package.

Unless you work with Xamarin.Forms, 97% of the time 3rd party code is fine.
That is, if you use only popular and well-tested packages.

But you do that, right?

9. Improve observability (Collect evidence from the crime scene)

In cases when it is hard or impossible to reproduce the bug, what you can do is improve observability.

Add more logging to your code to collect helpful information from the crime scene: your production environment.

10. Take a break

Once you get to the point where you:

• are going around in circles,
• trying the same solutions,
• and trying to force your way to the solution,

Stop.
Take a break.
Go get some water/coffee/tea, and step away from a computer for a few minutes.
Your mind will subconsciously continue to work on the solution.
But you will get the chance to clear your mind.
And calm yourself.

That’s why one of my favorite quotes about debugging is:

“Sleep is the best debugger.”

And remember:
Debugging is not just a skill. It’s a superpower. It’s a way to fix what’s wrong in the code written by a human. Or AI.

Improve your debugging skills. And you’ll improve your productivity.