[quickthrower2]

The more insidious problem is the card carrying believer in X saying “!X is harmful”

See this pattern all the time in both technical and people side all the time.

“You should never estimate using time”

“Don’t start new work until all the teams sprint commitments are completed”

Etc.

In a word it is arrogance with a twist of ignorance.

Ignorance that complex systems of humans and code don’t follow perfect dogmatic rules.

It might be ok for junior devs to be a bit like this but always add a pinch of “most of the time, but when experienced you’ll know when to ignore the rule”

Ignoring some unwritten or written dogma is often what makes for a competitive advantage.

Let your competitor drown in EnumClassFactorys .

[AndrewBissell]

Every one of these language toolbox books should come with a disclaimer for new devs up front about how the mark of a good craftsmen is knowing when to use the tools, when to bend or break their rules and guidelines, etc. I know it certainly might have saved me a fair bit of grief and oddly written code.

[userbinator]

But then they wouldn't sound "authoritative" enough. The dogma-cult that keeps its leader well-fed wouldn't survive.

I think the best authoritative-sounding counter-quip is "Best practices are best not practiced."