July 30, 2008

• Programmer’s Conceit [Rant]

  One
  of the things that makes me hate programming besides the fact that it
  is boring and tedious and rarely accomplishes anything meaningful in
  the world is the fact that all of you SUCK at it.  And by you I mean
  anyone who is not as brilliant a programming genius as me.
  
  I
  know a lot of you aren’t programmers. That doesn’t matter. You’re still
  a sucky programmer. The day you start programming you will suck at it.
  It’s just a fact of life I have concluded from dealing with many many
  many programmers over the years. I’ll even explain to you why you suck.
  That’s the purpose of this essay. And I promise I’ll try to make it so understandable that even sucky programmers who have never programmed in their
  entire lives can understand.
  
  I also haven’t
  slept much. So I won’t be my usual pleasant self.  That’s good cuz this
  is Rant day and this is a Rant post. Maybe I will not sleep every
  Tuesday night so that my rants can be all that much more fun for
  everyone.
  
  There is a lot of evidence that
  you suck at programming. I keep finding evidence everywhere I look. I
  see some piece of software and the design is so mind numbingly stupid I just want to hurt someone.
  And it invariably means more work for me. Almost always more work for
  me. Why me? Because I don’t suck at programming. Sure there’s lots of
  stuff I don’t know, but I don’t suck. Or at least I suck a lot less
  than most of you. Of course I despise doing this work. For as I go into
  it I find more and more sucky programming. And you should see the
  bluging vain on the top of my head as I deal with this kind of hting.
  It makes me want to kick someone so bad.
  
  Let me give you just three examples of programmer’s folly that have annoyed me of late.
  
  Example 1:
  
  Example
  one wasn’t even something I personally was involved in. Rather I was
  perusing a famous website of a fairly popular product. This website had
  various versions of its product based on language. And each page for
  each different language was pretty much identical except that the
  language names were different.
  
  And here’s the thing I went to one page for “Japanese” and in several places in the text it said “Spanish”. WTF!
  
  Now
  this bothers me for sooo many reasons. Let me just say a few.  First
  off, this is a public website for a popular product! Where the heck was
  the Quality Assurance? Somebody should have caught that!
  
  Secondly,
  this almost certainly means basically that every single nearly
  identical page on that system is a copy and paste job of another page.
  Ugh! What unnecessary redundancy! Why can’t they use one of a gazillion
  templating toolkits out there? Why can’t they put the text in a
  database or a separate file and write a script to pull it out and make
  necessary variable replacements?
  
  Thirdly,
  even if they don’t want to get that fancy and consolidate all their
  pages with the same text so that you only have to update it in one
  place, why the heck don’t they use a damned variable! I mean there’s no reason
  why the wrong word should appear in some places and not in others. Have
  a variable and set it and use that variable everywhere. It’s trivial to
  do.
  
  
  
  All of this is so exemplary of a fault I see sooo often in so many programming
  project.  Just sheer laziness. And an incomprehension of the value of
  VARIABLES!
  
  Now some of you, trained as you are in the art of being a sucky programmer, might be thinking one of two things:
  1.  It’s faster to have the duplicated pages
  2.  It’s more secure to have duplicated pages
  
  And
  you know what? Those are ALWAYS the excuse arrogant programmers use to
  excuse their shoddy programming practices.   But sooo very often these
  excuses are invalid. People make concessions for the sake of security
  without first identifying or analyzing the problem at hand. Often the
  tools that exist have *already* been designed to solve that very
  security or speed issue that is worrying you.  The people designing
  large scale programming languages and toolkits are not dumb. Chances
  are these concerns are not as big an issue as you think. Often the
  hardware you are running on is more than capable of dealing
  with the speed and you are at best buying yourself microseconds. 
  
  
  
  All this means is that as general rule you are much better off doing it the RIGHT way first and then when you identify a problem going BACK and altering your system to account for that.
  
  Furthermore
  in this particular case you can get the exact same perceived benefit
  from duplicated pages while STILL implementing a more sane less error
  prone system. It’s not hard. If the pages are all going to be the same
  except for some textual substitution write a script that takes some
  template page and then CREATES a bunch of copies of that page with text
  correctly substituted and posts those new script generated pages to the
  server. Now the customer sees supposedly secure and fast plain text
  pages but from a maintenance perspective you only have to edit one
  thing and it’s really easy to add new languages.
  
  You’d
  be surprised how often there is an easy solution like this that nobody
  has ever gotten around to implementing because programmers are lazy and
  not in the good Larry Wall way but in the sucky “I think I’m being lazy
  but in reality I’m creating way more work for myself” way.
  
  
  Example
  2: 

  This comes up for me in my jobs ALL the time. When I see it, it
  makes me want to rip someone’s guts out and feed it to them. The issue
  is poor database design.
  
  I can’t tell you how many times I’ve seen a database with some stupid table that has fields that look like this:
  blah1, blah2, blah3, blah4, blah5, blah6…… blah78353
  
  And
  each of the blah fields are in fact the same datatype, contain the same
  kind of data. And the numbers from 1 to 78353 or whatever are some sort
  of special code that distinguishes the values.
  
  And you know that table alone is not so bad but INVARIABLY you find a little later there’s another table that looks like this:
  
  bleh1, bleh2, bleh3…. bleh78353
  
  And soon enough there are like a thousand tables like this!
  
  GAH!!!!
  
  Why!?!?
  
  Again
  people will site speed as their excuse and also add in a new fun excuse
  the good old “it’s easier” excuse.  Only it’s not of course. Some minor
  programs that are just selecting out the data are easier. But write
  anything of any level of complexity and it becomes a NIGHTMARE. 
  
  Of course the obvious way you are supposed to do this is to make one table that looks like this:
  
  code    blah    bleh   ….
  1
  2
  3
  …
  78353
  
  
  
  Clean. Easy. Simple. Intuitive.
  
  
  
  And if that’s not *enough* of a reason to use this better structure
  consider a simple example. Let’s say you want to write  a script to
  update all the blah values based on some formula.
  
  
  
  If you use the first structure your code looks something like this:
  
  
  
  CASE @MyStupidVariable
  
      WHEN “BLAH1″  THEN
  
          UPDATE  dumbtable SET
  
              blah1 = @NewValue
  
       WHEN “BLAH2″ THEN
  
          UPDATE  dumbtable SET
  

              blah2 = @NewValue
  

  …
  
  
  
  ETC. 
  
  
  
  I have only one word to say about this kind of coding:
  
  YUCK!!!!
  
  
  
  Trust me you will understand once you have to write this for 78353 entries.
  
  
  
  You do have another option though you can do something like
  
  
  
  FOR EACH $dumbvarvalue (@dumblistofvalues)
  
      $mydumbsqlstring = “UPDATE dumbtable SET blah” . $dumbvarvalue  . ” = ?”;
  
      execute $mydumbsqlstring, @NewValue
  
  ENDFOR
  
  
  
  What’s wrong with that you ask?
  
  
  
  Well besides the fact that it fundamentally offends my aesthetic
  sensibilities, is exactly the same thing as the above underneath, and
  is slow, there’s also the fact that you are concatenating strings with
  variables!
  
  
  
  Don’t do that!
  
  
  
  Really, it’s bad news. I know everybody does it. I’ve done it. I’ve
  made awesome code that way. But I’m warning you now. It’s bad bad news.
  
  
  
  You see one day someone will do something totally unexpected and find a
  way to set $dumbvarvalue to something you wholly never expected and
  it’ll be something like this:
  
  
  
  “1=1; –
  
  STEAL ALL YOUR MONEY;
  
  DELETE ALL YOUR DATA;
  
  #YOU SUX0RZ
  
  #I AM L33T”
  
  
  
  And yeah most systems should give you a syntax error when some crazy
  string like this is piped in. But someone will find a way to trick you. To put something you didn’t think to check in.
  And then  guess what? They’ll have all your money, have deleted all your data, and
  told you the absolute truth about yourself: that you sux0rz. This won’t feel good. It’ll feel especially bad
  when you find out it was done by a 10 year old kid from a third world
  country who does all his programming on his specially supped up
  Nintendo DS.
  
  
  
  Have this happen to you once and I promise you you will avoid string concatenation like it’s the plague.
  
  
  
  All of this could of course be solved if you just designed your tables using the alternative method I described above.
  
  
  
  In FACT you can probably do something like this:
  
  
  
  UPDATE smarttable
  
      SET blah = (some formula in terms of code)
  
  
  
  And that will update EVERY entry in your table to the correct value in
  one trivially easy to maintain line. And it’ll be fast and efficient
  and clean and just make you feel all warm and fuzzy inside.
  
  
  
  Suddenly you’ll realize maybe all those academic boneheads who ramble
  on about the importance of “Normalization” might have actually known
  what the heck they were talking about!
  
  
  
  Oh for the non-programmers out there wondering what “normalization”
  means, it’s just a big fancy way of saying “designed in a manner that
  makes common sense”. And there’s like mathematicians who have fun
  proving that certain database designs make sense to various degrees of making sense. But you don’t need to care about that. Generally if some design makes more sense to you than another, it’s probably the more normalized design. 99 times out of a 100.
  
  
  
  This is just one example, but there are tons of examples of poor
  database design I could site. And I see them all the time. And I don’t
  get it. This is not a particularly creative idea. I think that people
  just wrote a quick table when they only had “blah1″, “blah2″, and
  “blah3″  and then they just kept adding to it as they got more. Next
  they you know they had “blah78353″  and “bleh’s” and “blugh’s” and all
  the rest. All the long people were afraid to redesign for fear of
  breaking old code. And nobody ever stopped and said ENOUGH IS ENOUGH!
  
  
  
  But more often than not sucky programmers like you will stick your
  noses up at my structure and say “normalization is stupid” and call
  people who insist upon normalization “snobs” and talk about how much
  faster and more efficient your janky table structure is than if you
  wasted all your time normalizing it.
  
  
  
  And to some extent I sympathize. I HAVE seen other sucky programmers
  who get so obsessed with normalization that they lost track of the real
  life phenomenon they were trying to solve. And the results are ugly
  indeed.
  
  
  
  But for MOST situations you are likely to come involved in you are
  almost certainly not normalized ENOUGH.  That’s far far far more
  common.
  
  
  
  Unless you are starting with one of those tried and trusted
  denormalized patterns that big data warehouses you, you should almost
  certainly design your database first to be normalized see how it works
  and THEN alter it to make it make less sense whenever necessary in
  order for efficiency. The systems you are using are designed in
  accordance with database theory. Which means they are expecting you to
  normalize your data. Really they are. It’ll probably be faster than you
  think. And it’ll be easier to maintain too. 
  
  
  
  And even if it isn’t I mean what kind of a design process is that to
  say “I think this’ll be faster so I’ll do it this way”. You want to
  have a benchmark. You need to do analysis. You should prove your way,
  your suckier way, is in FACT faster, before you force that implementation upon others.
  
  
  
  
  
  Example 3:
  
  
  
  OK so really examples 1 and 2 don’t bother me all THAT much. I mean
  sure lots of programmers never learned database theory and some people
  I guess have a grudge against variables or something. Whatever. I don’t
  care. When you suck in these ways you are only hurting yourself. Well yourself and *me* since I’ll probably end up having to maintain and extend your code. But whatever. I’ll deal.
  
  
  
  But the big way in which you programmers really and truly suck is when you exercise what I call the PROGRAMMER’S CONCEIT.
  
  
  
  Consider this scenario.  You write your beautiful baby of a program.
  It’s awesome, you think! Oh man this is gonna be so great. You tested
  it perfectly.  There are no errors. It’s a work of art. A masterpiece. 
  
  
  
  
  So you put it out there.
  
  
  
  And then some damnable user comes to you and says something like: 
  
  
  
  “This system is really stupid. I can’t do X!”
  
  
  
  And then more complaints come in:
  
  
  
  “How do I do Y?”
  
  
  
  “What happened to my Z? In the last version I could do Z so easily! You screwed it all up!”
  
  
  
  At this point, and here’s why you suck, you get your back up. You get
  pissed off. You let your pride get in the way of your professionalism.
  And you make the cardinal crime of the programmer:
  
  
  
  You blame the USER
  
  
  
  And that’s cuz you suck. You’re conceited. You think you know better than the user. After all you MADE it!
  
  
  
  How could they be so stupid? You think:  I mean there’s
  instructions for how to do X right there! And only an idiot wouldn’t be
  able to figure out Y. And why on God’s green Earth would you want to do
  Z when you can do A, B, C, and D all of which are easier and better
  than doing Z.
  
  
  
  What’s wrong with people?
  
  
  
  And then you don’t change anything. You instead yell at the users. You tell them Look right there! Do it this way! You scream in frustration!
  
  
  
  And often you get sick of doing that so you say “Bah. Screw them all.
  Hey boss hire someone to educate the users. My time is too precious to
  be wasted on idiocy like this.”
  
  
  
  And your boss, being a gullible fool will probably do that. And make
  some poor tech support guy’s life a living hell since now that poor
  soul’s entire job will resolve around trying to tell users that they
  are being “stupid” in a polite and nice way without offending anyway.
  
  
  
  How very arrogant of you!
  
  
  
  You’re conceited. It’s the classical programmer’s conceit. I see it ALL the time. Everywhere. Every project I’ve been on.
  
  
  
  Guess what though? If your users don’t know how to use your system, it isn’t their fault! It’s yours!
  
  
  
  That’s your JOB.  If your users aren’t able to *use* your system you should get off your lazy ass and FIX it.

  Your goal is to please the users. It’s not their job to measure up to your expectations of how smart and observant they need to be.  If
  some feature is unintuitive to a number of the users, that’s your
  problem. It’s your fault. And it’s your RESPONSIBILITY. You have to
  make it better. You have to make it more intuitive or you have to find
  a way to educate and/or train the users through your software so that
  they are comfortable with it. So that it serves their purposes. You
  aren’t writing this whatever it is just for yourself you know!
  
  
  
  If you don’t? If you instead try to pass the buck or abrogate responsibility out of some conceited desire to prove how good a
  programmer you are? Well guess what? You aren’t a good programmer. In
  fact you SUCK. Give it up and go do something else. I’d rather have that ten year old with his Nintendo DS on my team than you.
  
  
  
  Now I’ve noticed a lot of organizations don’t even give programmers
  immediate user feedback anymore. Instead they have it go through a bunch of
  filters. People who do user studies and blah blah blah. I can only
  assume that this whole system came into existence because business
  people got sick of dealing with the fragile ego’s of conceited
  programmers who have become so bitter and jaded that they can no longer stand making contact with their own users.

  How terrible! This just perpetuates the whole system. Why coddle the conceited programmer and let them sit on their ivory throne thinking they know “the right” way to do everything? It should be exactly the opposite! Businesses should make programmers interact with their users more and more and more until they get past their egos and start to care about the people they are trying to build their product for.
  
  
  
  
  So yeah that’s about it. You all are terrible terrible programmers. You
  need serious help.  And I can’t solve all your problems but let me give
  you three little small pieces of advice that will make you thousands of
  times less sucky a programmer in the future:
  
  
  

  
  1.  Variables are your friend
  
  
  2.  Use Common Sense
  
  
  3.  Don’t be a dick
  

  
  
  The end.
  
  
  

  • 12:56 pm
  • 13 Comments