"It worked different three months ago...". But I agree that this is no reason to gave to wade through commented out sections[1] but to simply use the powers of <vcs-of-choice> diff.
In my day job, I sometimes get told to make changes that I suspect will cause problems in some edge case which we might not see for months. It seems like the responsible thing to do is to leave the trustworthy version of the code there for the benefit of whoever has to fix the problem when the shit hits the fan.
I understand that reality is more complex than this, but
git bisect
That should identify the/your commit in (usually) < 10 tests. At which point the previous code is still intact.
Or
git blame
and look at the problematic lines, see who changed it and when. Now look at the git log (filtered just for this file if you want) and identify the last changes to this part of code that way.
More complex than just
// timestamp, initials: Changed foo, commenting the following 100 lines out
maybe, but makes the day to day code so much more readable.
When the code was rewritten for efficiency. Whenever I read 'clever' code I wish I had an 'idiot' version that was written purely for me to understand.
So true. Whenever having to write a complicated code, I always keep a simple pseudo code in comments. That helps me both to understand later what I wanted to achieve, as well as help me focus on actual implementation details after figuring out he high level algorithm.
How is an unfamiliar developer supposed to find out that the deleted code exists?