Write Everything Twice

This is good advice, but I'm a little disappointed to see it written up as a complete novelty. The principle appeared in Martin Fowler's 1999 book Refactoring as the "rule of three", where he attributes it to programmer Don Roberts. I've heard it a zillion times in discussions about when and how to refactor.

This one seems to be this generation of newly minted senior devs' hot button issue.

Dogma in general is anethema to innovation, but that doesn't mean particular practices are wrong just because some people are dogmatic about them.

The broader concept here is that "people can tolerate a little bit of smell." Code smell is bad, but it also tells you what needs fixing and where your design is lacking. As a principle, I like to operate under the assumption that hacks and nonstandard code is ok IF they can be explained and kept in mind by someone coming into the project. Usually that means a 3 or 4 warts can pop up before I begin to refactor and remove them.

Live in the spirit of the law not the letter of the law. I never took DRY as an excuse for premature optimization or to it's logical extremity in practice. To me applying WET principles would be indistinguishable from DRY in practice. I think it's better to understand that than to redefine the law.

Its always nice to see a developer realize this concept on their own. Self discovery is a sign of acquiring experience and a great thing. Don't mind the others putting you down because you didn't reference the rule of three.

I like the WET acronym counterbalancing DRY. Nice touch.

This is a good advice, but I feel to add a few points of mine:

1. the author says "premature optmization", and it has the right context, however I prefer to use "premature abstraction" or even "speculative generalization".

2. YAGNI and DRY can be counter-principles because at times "you aint gonna need that level of abstraction/genericity".

3. Inadequately abstract and generic code hurts simplicity and readability.

While this blog post is new, I've heard this acronym used in this context for at least a couple years.

Not sure I'm on board with the premise if the article. Author presents duplication of HTML elements as a commonplace exception to DRY; This is not what DRY is.

Can't agree to overturn a tried and true best practice, in favour of the opposite, as the article suggests. While easy to play around and adhere to the dogma of DRY at all costs; namely making code difficult to reason and taking ages to do it; we just call this premature optimisation - DRY done with no critical thought about priorities.

Tldr; don't optimise for DRY too early or at the cost of what's most important or expedient. Use common sense and adopt DRY only as far as necessary for your team and to help others extend and be efficient working with your code. Not a bad article but maybe just complicating what we already have a name for.