The code culture problem

A toilet that doesn't flush correctly isn't a reason to complain if you're a plumber; it's your raison d'etre. And, although many don't want to recognize it, a good number of software developers are modern day plumbers.

For many developers, imperfect code, which is often more likely to be result of circumstances beyond the control of the person who wrote it than downright incompetence, is the gift that keeps on giving. If business and functional requirements were always well-defined and never evolved, clients/business stakeholders completely sane, deadlines realistic, resources plentiful and "scope creep" a rare phenomenon, a lot of software developers would be unemployed, and employed ones would be more frequently undervalued.

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:

    
      blah blah blah
    

60% shit removal! A review removes 60-80% shit, to remove more than 80% use compounded shit removal. Compound requirements, design and code reviews to get 99%+ shit removal. finding 60% shit is not hard, every time you spot a little shit spend 3mins thinking about how to create better next ti

That is not my experience. There is a ton of good to extremely good code out there. I'm rather dismayed by the amount of "well, what can you do" hands-thrown-up attitude here.

I've always found clean code to be faster to develop. I find that developers that produce lower quality code tend to spend their days debugging, fighting their code, reading and trying to figure out what they wrote 5 months ago, and so on. They are just not very productive. There are the outliers - people that have instant recall of all their code and elaborate mental models of really poorly structured code - but by and large I find that people that generate low quality code are quite slow performers.

I've worked in very good code bases, and very bad ones. In the good ones you can easily figure out what is going on, quickly make changes, confident that you aren't breaking 5 things because things are decoupled. You can produce new code quickly because you aren't fiddling with code nested 6 if statements deep, which is just about impossible to model correctly in your head. You aren't in endless compile/run/debug (or REPL/run/debug) cycles because your first try is usually just about right, because you can understand the surrounding code. I recently requested a simple feature, and was told it would take a week. I was dubious. Then I looked at the code, and decided that they were being conservative, if anything... for something I thought would reasonably take a few hours.

This is just an impassioned plea, not to Jach, but to the profession, to cast a critical eye on code. You can produce high quality code quickly. Not "nuclear reactor" quality, but pretty close. Bad code always costs you. Always. Don't write that way, don't allow it in your code base, or in your teammates.

I'd say most code is shit. However, I'm sure people don't deliver shit code by pure choice. Unclear function purposes, time constrains, bad days, etc. Or just the plain old, "quick hack it together" to get back to the code you where really working on. We should just not feel insulted about the fact we write shit code, this doesn't mean you are a shit programmer.