At some organizations I'm seeing a trend where if a bug is reported, engineers will directly rewrite the offending code without knowing the root cause. In general this will fix the bug, but in my opinion it also introduces the risk of new bugs - and it doesn't allow a team to learn collectively from the mistake that caused the bug in the first place.
In general, when a bug is reported, I try to retrace the steps that the programmer took to find the root cause - or the root 'mistake' that caused it - but I'm aware that at some point in time this research efforts might accumulate to more work than if we would have rewritten is, especially if the code is particularly old.
What are some other considerations to take into account when making this decision? Here are the ones I currently have, as a list:
Method 1: Rewrite the code immediately
(+) Makes the code up to 'modern' standards that the team has set
(-) Introduces risk for new, unknown behavior and bugs
Method 2: Find the root cause and fix it
(+) Typically requires less code changes, and therefor less risk and code to review
(-) Old/outdated code doesn't get updated and may still have some errors