Mel was a Moron

Real Programmers everywhere know the story of Mel.  Mel and his macho programming skills that put all those pansy pascal programmers to shame.  Mel who knew the intricate details about the memory cycles of the hardware he was programming on, programmed in hexadecimal, and hated compilers (well at least compilers that couldn't write themselves).  And all those lesser, non-elite programmers and hackers awed at his awesome skills.

And the story's been passed around the underlayers of the internet world for some time.  I remember when I first read it and thought to myself, wow, that guy was a real wizard, something to aspire to.

Then I met the real world where programming is done and software is made and systems are designed.  And I realized that Mel was a moron.

Oh I get it, Mel had a brain for getting into the details of how each part of the hardware worked together.  Of course that's commendable. But let's look at the bigger picture, the story being told by the narrator about the guy he worked with, Mel, and what was really happening.

When Mel left the company, nobody could work on his code.  Because he wrote it in assembly, a step above machine code, which most other humans don't actually read (at least not on purpose).  It couldn't be commented (he actually wrote in hexidecimal, not some assembly editor like we use today, and binary assembly can't take comments).  You can't explain to other humans what the program is doing or why.  This is part of the reason for creating a compiler - to abstract the instructions you're writing another level from pure machine code.

That by itself isn't terrible.  Just step back and imagine you're paying Mel to work for you.  You give him a task to write a simple card playing program.  He writes it in assembly.  You need him to change it a little.  He now has to (nearly) rewrite the entire thing (as assembly is fairly non-abstracted - it's non-trivial to modify).  And again and again, you need little changes.  Then one day you have a slightly different platform for him to write it on.  Wait .. oh, Mel doesn't know the underlying ins-and-outs of this new platform, he writes in assembly so he'll spend a long time learning the new system then writing another program.  Oh yeah, and nobody else can read the code without becoming experts themselves on his code.  One day you realize you're paying Mel way too much to maintain some code for you, so you let him go, and now the code you've paid so much for is going to become abandoned, as nobody's going to want to have to deal with that mess (which is pretty much what happened in the story).

My personal definition for a moron is someone who can be really really smart while doing something ultimately stupid.  Like building an atomic bomb, or carefully analyzing the issues and then picking one of the two candidates for president.

Real Programmers use the tools they have to get the job done, to avoid ever having to repeat any work they've already accomplished.  Any person with decent intelligence (or who values the fact that their lifespan is going to be a very, very finite number of years) doesn't want to spend all their time cleaning up code that they wrote more than a week ago (who remembers what they wrote more than a week ago?), or that someone else wrote, or becoming experts on the details that other people are paid to be experts on (as Einstein was quoted as saying, "Never memorize something that you can look up").  Anyone concerned with Getting Things Done isn't going to want to micromanage anything. 

This is why we build computers - to do the little tasks for us.  We build small tools, abstract them so we don't care how they do the job, and combine them into large tools, which we again abstract, and build into larger tools.  Any child can understand this - when we go and buy a pizza, we tell the pizza place if we want pepperoni or not (we tell them what kind of pizza we want).  We don't detail for them what strain of wheat crop they should use, who they should buy it from, who the farm should hire to harvest it, when they should plant it, when they should harvest it, what machines they should use to do so, how they should store it, how they should process it, how the dairy should keep the cows, what they should feed them, when the pizza place should open and close, who they should hire and how much they should pay them, etc, etc, etc.  Someone details that for them, and in some way we make decisions about things like 'are they using organic?' and such.


Of course if it's your job to know what time the workers show up to harvest the grain, you should know that.  But not if it's your job to deliver the pizza (or rather, your job shouldn't depend on knowing what time the grain workers show up - that's my point, that that kind of system is unsustainable, and doesn't work).