Debugging by Following What Changed

I've become less interested in finding the line that looks suspicious.

That sounds backwards when debugging, but the suspicious line is often just where the failure becomes visible. The actual cause can be somewhere completely different.

When something breaks, I now try to reconstruct the recent changes before touching much code. What changed in the last commit? Did a dependency move? Did configuration change? Did some unrelated part of the system get refactored?

This doesn't mean the newest change is automatically guilty. It just gives me a useful starting point.

I've wasted plenty of time staring at a function because the error appeared there, only to discover that the function was behaving exactly as it had been designed to behave. Something upstream had changed the conditions around it.

There's also a useful side effect to looking at changes first. It forces me to think about the system as a chain instead of a collection of individual files.

A bug rarely cares which file I think looks ugly.

The other thing I've noticed is that recent changes are easier to reason about than the entire history of a codebase. If I start with "how does this whole system work?", debugging becomes archaeology. If I start with "what became different?", I usually have a much smaller search area.

This approach obviously doesn't solve every bug. Some failures are old, some are caused by external systems, and some are just wonderfully inconvenient.

But checking what changed has become one of my default first moves.

It's a lot cheaper than reading the entire repository because one line looked suspicious.