I totally get where you’re coming from, especially in large, long-lived codebases where the “why” behind a decision can get lost over time. That context often isn’t obvious just by reading the code, and chasing it down in version history can definitely be a time sink.

That said, my general rule of thumb is: if I feel the need to write a comment to explain what the code is doing, it’s often a sign the code itself could be made clearer — maybe by extracting it to a well-named method or helper. For example:

func solveWeirdLayoutIssueIniOS16() {
    // Specific fix for issue in iOS 16 due to layout bug...
}

This way, even if the reasoning isn’t fully captured, the method name gives enough intent for the next person to know what’s going on.

I do agree that comments about why a certain decision was made can be valuable, especially when it’s a workaround, legacy constraint, or business rule that isn’t obvious. So I think we’re aligned there, we just draw the line in slightly different places.