http://www.perlmonks.org?node_id=1172672


in reply to Don't post bad code!

Well, those posting bad code don’t know the difference. Those believing it to be sound advice are starting a journey toward discernment in a world absolutely heterogeneous in quality and value and they will have to take some lumps along the way or never break out of the inner circle of Dunning–Kruger. It’s not always in their interest to protect them. 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 can see a code post here by afoken or AnomalousMonk or Corion or, or, or… and know it to be good or, at the least, worth examining seriously and with all benefit of the doubt. New users and Anonymous Monk get a couple kilos of skepticism. I believe in best practices and would probably cite this (update: meaning your OP) post in a discussion as something worth considering. So… 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.

Replies are listed 'Best First'.
Re^2: Don't post bad code!
by afoken (Canon) on Sep 27, 2016 at 06:53 UTC
    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

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)