Use your debugger less and learn more from debugging instead

Source: Dev.to

Background

In my last project I worked on a large, complex expert system. Using a debugger to inspect bugs was difficult for several reasons. We received live data from the real system we were trying to replace, so traffic was high and following a single request was problematic.

When the bug was on the client side, debugging was even harder. The client was a custom Java frontend based on Eclipse RCP, a technology we had limited experience with. The UI logic was hidden in many layers of Java code and XML files, making it difficult to trace execution flow with a debugger.

A New Debugging Strategy

I adopted a different approach that relies on thoughtful logging rather than stepping through code with a debugger. The key is to ask yourself what you actually want to learn before you start a debugging session.

Step 1: Define What You Need

1. Identify the variables you need to inspect.
2. Determine which properties of their values are relevant.

Instead of launching a debugger with a vague “let’s have a look” mindset, I now enter a session only when I truly have no idea what the problem might be from reading the code.

Step 2: Add Targeted Log Statements

• Log the values of the identified variables.
• Choose any format that makes the information easy to read.
• Include timestamps – they are invaluable for diagnosing timing issues that are hard to see in a debugger.

Step 3: Use a Temporary Commit

Create a temp commit (a short‑lived change) that contains the new log statements. Deploy this version to a test environment, feed it real data, and then collect the logs. Once the investigation is complete, the temp commit is removed before merging into the main branch.

Analyzing the Logs

With the logs in hand you can:

• Programmatically parse and analyze the data.
• Share both the analysis results and the raw data with teammates.
• Include the analysis code itself, allowing others to reproduce or extend the work.

This approach makes the debugging knowledge persistent, unlike a debugger session that disappears once you stop stepping through code.

When a Debugger Is Still Useful

A debugger remains valuable when you don’t know the execution flow at all, such as when the code relies on generic mechanisms that are hard to understand by reading alone. In those cases I use the debugger to discover the relevant classes and control flow, then switch back to logging for deeper analysis.

Conclusion

Switching from a debugger‑centric workflow to a log‑driven one helped me understand the system’s behavior much better and reduced my reliance on interactive debugging. If you haven’t tried using logs for debugging, give this strategy a try—it may make your debugging sessions more deliberate, structured, and shareable.