Well, those posting bad code don’t know the difference.

My meditation lacks the word "intentional": It is about intentionally posting bad code. (See Re^2: Don't post bad code!)

And I think people who manipulate the symbol tables instead of showing how to use arrays or hashes do know the difference.

Those [...] never break out of the inner circle of Dunning–Kruger. It’s not always in their interest to protect them.

Good point. I've met two or three people from the innermost circle in my life, and I should have remembered how much I wished they would do a much less harmfull job (like self-moving ballast or park bank pre-warmer) at the other end of the world. Not to mention tens of people with a little bit less of D-K.

But still: Should we feed them with bad practices?

Attempts at process, rules, or dogma to enforce quality often have unintended consequences and like most crime/“crime” the admonishments are ignored by those they would help or correct while already understood and followed by the rest.

I’m not sure I have a point except maybe: trying to prevent crap is the fount of quite a lot of crap in the end.

I don't think that allowing bad code will sort out the D-K people. The crap they produce is much too often considered "good enough", some times for years and tens of years. It's part of their job security, no one except them has even the slightest clue of what happens in their code.

<Update>

Design and code review (at peer level) are an excellent way of improving quality. Unfortunately, it requires any writer to accept a lot of critic from the peers. The most important part is to understand that critic is about improving quality, not about the person.

</Update>

Alexander