Programmers Are Lazy

I’m one of those people who really loves to program. There is just something, almost exhilarating, about writing a bit of code and having it do something. I’m sure it is the same for any one doing something creative, but I think programmers get a bad rap at times because … well … I don’t really know why. Programming is done in dark dank areas, far removed from anyone. Usually the programmer is head down in their code, only taking a moment to get another slice of pizza, or open a new can of pop.

As I’ve gotten older, I’ve come to realize something about the next generation of programmers; many of these greatest programmers are down right lazy!

Let me explain. I love working through my programs and making sure I account for everything that a user could possibly do. And, I have to admit, I do a good job of predicting what new oddity a user might try that I didn’t design the software to handle. To me, that is good programming.

You can write the best notes, have the cleanest and most efficient code, and you can spit out that code in record time, beating all deadlines. If your software does what it is supposed too, you still need to make sure you predict and plan for every single error possible as part of your design. Basically, you have planned for everything that a non-programmer might do or try. It might seem like a lot, and it is, but if done right, no one is every left scratching their head when an “error” does appear.

Now days, many programs will generate a message saying there has been a problem, maybe even output some magical code, yet the user is left scratching their head. Like any good end user, we see those messages of doom and immediately hop on the current search engine of choice and start investigating a fix. Almost 80% of the software out there (a number I feel captures my experience as an end user) using that magical error message leads you back to people who have also ran into the problem and about just as many possible solutions to fix that error.

After researching several solutions, none apply to you. For those of you who are an end user, I’m sure you know how that feels. Page 13 of search results still don’t fix your problem. You’ve been here for over an hour. You just need to get this fixed and done. Insert screams, and that desire to throw your computer out the window.

In several program languages, the language itself has error capture mechanism so that if something does go unexpected, the program will be able to recover. The problem is, these mechanisms to capture an error are very generic, meant to protect the program, and the programmers hard work, so that the user can move on. They do not provide much useful information to the normal end user when these routines are encountered. It is up to the programmer to provide an explanation of why the error was triggered and to some, that is simple done by spitting out a message to indicate where in the code the error occurred, or, if your lucky, tidbits of other details that really aren’t telling you anything about the specific error, just there was an error.

Some of us, who are programmers, can look at the strange gobble-gook on the screen and piece together what might have happened, for example, a null reference was discovered. Programmers all know what that means and some of us might even be able to figure out what to do to get around it. But the typical end user, the programmer might as well have told them a duck is in the trunk and rabbits are on the cord. Huh? What the?!?!

A good programmer, they will work to make sure those routines NEVER get triggered. That means they write code with as many probably error reasons as possible and if an end users does trigger the error, the messages at that point almost always pinpoint exactly what happened and how to fix it. Or using your favorite search engine, has end users being answered by them ending on the bug report that someone submitted about that error. This is rare, super rare in fact.

Look at Windows. The Blue Screen of Death. You always get some codes, numbers, even text with stuff in it. But if you go search for that error message, you are always going to find thousands of possible fixes. Again, instead of trying to out think users, the programmers of this software rely on those built in error capture routines. Those routines could capture an error that was done by the programmer, by the hardware, even by the user. You just don’t know. And though, yes, there are ways to get more details on that error, to an end users who isn’t a programmer, they just want to know what to do, if it can be fixed, and how to move on. Almost 80% of the time, the users is stuck and ends up calling their stand by programmer friend who’s locked up in the basement and asking them to help figure out why their computer has died on them.

To me, if you are going to write software or scripts, use the built in tools to catch errors but when you do, put in some reasons as to why those routines might be triggered. Don’t just put in a simple “an error has occurred, please try again” messages. Put something that helps the user such as “during the save process the file failed to be written” or “a value that may have been required is blank, please try again”. Anything other than just a number or some odd code — especially in those dang Try-Catch routines. Think ahead. What happens if the user finds a way to not input a value in this location? Sure the error routines will halt the program or work around it, but what about the user, what do they do? Ask yourself, what should you check for so the program doesn’t crash or ever show an error message.

Programming is one-quarter creation, three-quarter error prevention. Kind of like writing. A good writer can blast out a chapter in a book in an hour, but proofing it, checking it, making sure references are correct, that takes days, weeks, sometimes months to finish. Heck, just writing one of these posts takes me about 10 minutes, but it can take me a week to proof it and even then, I miss things.

Leave a Reply