The article is not about the existence of shit code, the amout of shit code produced per year or how much shit code the average developer will see in his career.
It is about teamwork, and what kind of culture poisons the atmosphere in a company.
Not about shit code, which by the way everyone here has produced at some point or to be more realistic about it (since usually developers look at their old code and think it is bad) - is still producing on a daily basis.
Once I finally understood what it was doing enough to refactor it I managed to delete most of the file and replace it with a "latest_id" counter which incremented on each call, with the success handler skipping if its ID wasn't the latest. Simple.
I got told a similar thing during a code review as well, since I'd used map on an array. Needless to say, I didn't stay there long.
Now that is a cultural problem, which can only be solved by pointing out shit code (although in a more polite way). Some people are so stuck in their ways that they don't care about improvement because they see their stuff as 'good enough'. In those cases, they need to be shown that no, it's not good enough, because XYZ.
I wasn't trying to gain points on anyone; I was just frustrated at the utter lack of care about the codebase we all had to work on. Whenever I spotted anything particularly WTF I'd send out a "Code of the day" email. My favourite is still this one:
blah blah blah
</td style="....." id="foo" class="bar baz">
FWIW: when I was fresh out of school my logic was sometimes pretty twisted, to put it kindly. Lots of deeply nested if statements, global variables used to maintain state (in the state machine sense) that sort of thing. That is unworkable, I recognized it, and I learned from my peers, from books, from good code, from myself (reality is a wonderful instructor. Work til midnight fighting a bad piece of code you wrote, well, you should learn something from that). That's not ego, that is learning your discipline.
This is all testable in the marketplace - not in products sold, but the marketplace inside your development lab. Are you the programmer with endless bugs, or the one that generates nearly bug free code. Are you a 10x programmer, or not? Are you the one that everyone asks questions of (to learn from you, or get your opinion on a design), or not? Do people seek you out for code reviews, or not? Do people need to come to you endlessly to try to figure out what your code is doing, or not? Does your code have a disproportionate number of bugs written against it? If there is a bug in your code, do the rest of your team members assign it to you because they can't begin to understand your code? And so on. There's no ego in any of that, but it is all reality(what I called the marketplace) telling you the quality of your code, in the measurable form of understand-ability, maintainability, bugginess, and so on.
He took the one thing he could make an easy, pedantic point about and posted it. It's easier to do that and get free karma that actually be mindful. It's low hanging fruit. Just like I could find errors in his comment that would serve no purpose.
At issue is, while his point might be technically correct, it serves nothing other than to encourage "Me too" replies. This happens frequently on HN. I encourage you to down vote such posts.
All I am saying (and I think the author tries to make that point) is that it is questionable that you are going to create such an environment by pointing fingers and treating devs bad.
My very limited experience (I am the mobile lead in a company) has taught me, having done all of that myself in the beginning, that I wont achieve anything this way.
What I saw is that people got defensive by default, protective about their work (so no one can attack them for errors they made), the company started bleeding talent (what person is going to like working in such an environment?) and so called "code monkeys" never improved, because they didn't believe that they could achieve anything meaningful by themselves.
For some companies this might work in a way that I can't understand, but I changed, because frankly I didn't like to work in such an environment myself, and it did have to some degree positive effects.
People share more information, there's less pressure generally and there is more trust in general that everyone is doing their best, and if unable to complete some task, will ask for help.
By the way, here's a Google I/O talk from 2010 about engineering leadership that covers the problems mentioned in the article - I cannot recommend it enough: http://www.youtube.com/watch?v=skD1fjxSRog