The first serious lesson in flint-knapping is that undo does not exist.
You can keep working after a bad strike. You can change the plan. You can make a smaller tool than the one you meant to make. You can sometimes use the mistake. But the removed flake is gone, and the stone is different now. Every strike changes what can happen next.
Debugging has the same problem.
When a system breaks, my first impulse is to change something. I want to restart the service, edit the config, add a log line, clear a cache, roll back the last suspicious commit, or try the fix that worked during some other failure. That impulse feels productive because movement feels productive. It is often just movement.
A change made too early can destroy information. If I restart a service before I understand why it failed, I may remove the state that would have explained the failure. If I change three things at once, I may fix the symptom while losing the ability to know which change mattered. If I add logging without a hypothesis, I may only create more output to stare at.
Flint-knapping punishes careless action quickly. Before striking, I have to inspect the piece. I check the platform angle. I check the thickness behind the edge. I look at ridges that can carry force. I look for places where the stone is already weak. I am not only asking where I can hit. I am asking what the strike will change.
That question matters in debugging. Before I touch the system, I want to know what the action is supposed to prove. If I add a log line, I should know what uncertainty it reduces. If I change an input, I should know what each possible output would imply. If I restart a process, I should know whether I am testing a theory or just trying to make the problem disappear.
There is a useful distinction in flint-knapping between percussion and pressure flaking. Percussion uses impact. It removes larger flakes and changes the piece quickly. Pressure flaking uses controlled pressure along an edge. It removes smaller flakes and is better for precise work.
Debugging has the same split. Some failures need percussion. A bad deploy may need to be rolled back. A broken dependency may need to be removed. A stuck process may need to be killed. Those are real fixes when the situation calls for them.
Most bugs need pressure flaking. They need one controlled change at a time. They need a small test, a narrow observation, and a clear comparison against the expected result. The point is not to look busy. The point is to keep the problem understandable.
The emotional part is difficult. A broken system creates pressure to act, especially when other people are waiting. Flint-knapping trains the opposite habit. I hold the piece longer. I rotate it. I inspect the ridges. I try not to strike just because I am uncomfortable.
I debug differently because of that. I still make impatient changes sometimes, but I notice the impatience faster. I try to keep the shape of the problem intact until I understand it. A system can usually survive one bad change. The real danger is when I stop knowing which change caused which result.
Next