(See also the discussion when I posted this on HN: https://news.ycombinator.com/item?id=25198597 ).
That's not what I intended, which is why I have this in there:
> Often you’ll jump into code to fix a bug, investigate an issue or answer a question.
> When you do so, improve it. This doesn’t mean you rewrite it, or upgrade all the libraries it depends on, or rename all the variables.
> You don’t need to transform it.
> But you should make it better. Just clean it up a bit. Doing so makes everyone’s lives just a bit better, helps the codebase in a sustainable way, and assists the business by making its supporting infrastructure more flexible.
Perhaps I need to make it super explicit that you should understand whatever changes you are making, discuss them with team members, have them code reviewed, and start with small steps (like documentation). I thought that was implied with the above, but maybe I wasn't clear enough.
> we were left with his crappy code
Seems like a horrible situation. I have so many questions!
If it was a true refactor (and not new functionality) why did you have to use the crappy code? Or did he do a rewrite in the process of adding new functionality? Who was reviewing the code? How did it get merged to the mainline?