Also important is Chesterton's fence and the history lesson when touring existing code. What were the business requirements the first time around that were thrown out the window for version two, but there was no time for refactoring so version three has this known wart that version four tried to refactor but that wasn't complete until version five which had this new feature that needs another refactor.

Brilliant summary and the parent comment.

Too many developers remain hyper committed to shiny object syndrome, or wanting to relearn lessons of the past as if they are the first to ever lay eyes on it.

No code is perfect, and lots can be learned even from a well intentioned approach gone wrong.

It’s far easier learning from other folks and their rattlesnake bites instead of insisting of recollecting that baggage yourself, first.

Greenfield is still useful, but too often it has to do with preference and interpretation or a lack of willingness to do so.

The funny thing is when you get used to someone's coding style, you can tell if they were stressed or under time pressure or not.