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.
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: