[BossingAround]

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.

Not only has it been written by a human, but one should also remember that they're missing the context in which the code was written. Was the author stressed about their latest children being born? Fearful of possible layoffs? Under time pressure? Tired?

I've definitely written code myself that came to bite me later, and I marveled at how badly written that was.

We're all human, which, among others, means that we're all inconsistent to a large degree.

[fragmede]

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.

[j45]

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.

[HeyLaughingBoy]

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.