32. Don't Assume It. Prove It!

One of the most dangerous things you can do as a developer is think you fixed a problem when you do not actually know what was wrong.

I once saw a perfect example of that. We had a strange bug in a project, and a colleague said he had "fixed" it. Great, I thought. So I asked what exactly was going on and how he solved it.

The answer was: "I have no idea, but I changed a 3 to a 4 somewhere and then everything started working again." 😅

That may sound nice, but of course that is not a real fix. Because how do you know that 3 was actually the problem? And why did 4 work? Maybe it was pure coincidence. Maybe the real cause was somewhere else. Maybe the bug will come back tomorrow and then you will have to change it to 5. As long as you do not know exactly what the problem was, why it happened, and why your change seemed to help, you do not actually know whether you solved it.

That is why this is a principle I strongly believe in: Don't Assume It. Prove It. ✅

When debugging, an assumption is not enough. You do not just need a theory, you need evidence. Do not start by randomly changing things until it "works again." First, investigate what is really happening. Where does the behavior start? What data is going in? Which code paths are being hit? What assumptions are being made? And most importantly: does your hypothesis actually hold up?

A lot of developers stop searching too early. They find the place where something breaks and think: found it. But the place where the problem becomes visible is often not the place where the real cause lives. In many cases, the issue starts much earlier.

For example:

• incorrect state
• unexpected input
• a broken mapping
• a timing issue
• an edge case nobody accounted for

Good debugging is therefore not just about knowing where something goes wrong, but especially why. 🎯

That difference is essential. Only when you understand the why can you confidently say you made a real fix. It not only helps you prevent the same bug from coming back, it also gives you a better understanding of how your system works and where its weak spots are.

Not every change that makes the problem disappear is actually a solution. Sometimes you only make the symptom less visible. Sometimes you move the problem. Sometimes you hide the real cause. And sometimes you create a new problem that will only surface later. Just because something works again does not mean you understand why it works. ⚠️

When you truly understand the problem, you can:

• create a durable fix
• prevent the same bug from returning
• refactor with more confidence
• clearly explain to colleagues what went wrong
• learn from the issue instead of merely suppressing it

And that is exactly where things often go wrong. If you do not make that distinction clearly enough, you slowly build a codebase full of doubt. A codebase where nobody really understands anymore why certain things are the way they are. That is technical debt in one of its most deceptive forms.

That is why debugging well is one of the hardest, but also one of the most important parts of software development. It requires you to truly understand how a system fits together. How data flows. How components interact. Which dependencies exist. Which parts influence each other, and which do not.

This is not about trying a few things until it feels right. This is about going deep into the code. Observing. Reasoning. Testing. Eliminating. Proving. 🛠️ And that is often where you see the difference between someone who only writes code and someone who truly practices software engineering.

So the next time you investigate a bug, do not just ask yourself: How do I make it work again? Also ask yourself: what is actually broken here, where does it really start, why is this happening, and how can I prove that my explanation is correct? Only when you can answer those questions are you no longer guessing. That is when you are actually solving the problem. 💪

Have you seen fixes like this before, where nobody really knew why they worked? We have all been there at some point. 💬

And if you are looking for someone who does not just try random things, but actually gets to the root cause and builds strong, durable solutions for web applications, feel free to reach out. 🚀