Investigate before you fix
The most expensive bugs are the ones where you fix the wrong thing confidently. Read first, understand second, fix third.
There's a difference between debugging (you have a theory about what's wrong) and investigating (you don't know what's wrong yet). Investigation means gathering evidence before proposing solutions. Read the code, check the history, look at the errors. Only form a theory after you have evidence.
You describe the problem. Then you gather information: read relevant files, check what changed recently, look at error messages, trace how data flows through the system. You present what you found. Only then do you decide what to fix and how.
This is the opposite of 'try stuff and see what sticks.' It's slower on trivial issues and dramatically faster on real ones.
When you don't understand why something is broken, resist the urge to start changing things. Instead, spend five minutes just reading. What does the code actually do? What changed recently? What do the error messages say? The answer is usually in the evidence, not in your first guess.
When you don't understand the problem yet. If you have a clear theory, go straight to debugging. If you're confused, investigate first. The read-only constraint prevents you from making things worse while you're still learning what's happening.
Product leader shipping across enterprise SaaS, AI in production, and 0→1. Writing about what actually ships — not what sounds good in a deck.