So what exactly is the point you are trying to make here other than that you are the smartest guy?
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.
The first step to solving a problem is admitting that there is one. I remember debugging some AJAX code once which was racing with itself. It took a lot of mental effort to work out what the existing code was meant to be doing and what it was actually doing, both of which were wrong. At it's core was a simple jQuery AJAX call with a success callback (no error callback, of course), but interleaved through it was a mess of global variables ("finished_yet", "time_last_checked", etc.), busy-loops, manual timeouts, state-rollback functions, etc. What I would call shit code.
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 approached the developer responsible for the original, to show him what I'd done and explain how Javascript's scope let each call have its own ID. His response was that I'm using obscure language hacks which nobody is going to understand when they have to maintain it, that I should stop trying to force everything into a few lines and that he doesn't need to learn about Javascript's scope because he can already program so learning anything else is a waste of time that could be spent coding.
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:
Yes. I understand the OP point about not fostering a culture of negativity - that makes a lot of sense. But I've never seen negativity take down a product, just make it a bit more unpleasant working environment. The culture of 'good enough' is far more damaging, in my experience.
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.
> So what exactly is the point you are trying to make here other than that you are the smartest guy?
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.
The point can be that the team can do it BETTER. If you run Sonar on a codebase and get 10K serious findings... then the code certainly is not optimal. There is no upper limit on how optimial it can be, but you'll certainly have an easier life and a better end product if you've followed best practices as opposed to "just getting it done" by the most junior, lowest payed code monkeys possible.
Then by all means improve or replace bad code and create an environment that will encourage devs to learn from previous mistakes and improve.
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
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.