Sometimes I’m shocked to realize that I’ve been writing software for over 30 years — longer than some of my younger colleagues have even been alive. And people who know my code are shocked as well, that so much time could pass and my code still sucks.
But I have an excuse: programming does not come naturally to me, as it doesn’t to many. And here’s why: software is stone cold stupid.
That is, software will only and forever (at least until the singularity) do exactly what you program it to do and nothing more. I know, at this point you are saying: “Well, duh!” but bear with me for a moment. There are all kinds of implications to that that I think are worth inspecting.
Humans are capable of complicated reasoning that can leap over A + B = C to get to Y. A software program cannot. The path to Y must be spelled out in its entirety. And with some languages, a missing punctuation mark or bad spacing can make your program croak long before you get there. This is a lesson I am doomed to constantly relearn in sometimes new and often surprising (to me) ways.
So here some of the implications I think bear spelling out:
- Garbage in, garbage out (GIGO). The classic complaint about software is that if the programmer has not included some way of verifying the incoming data in the code, then garbage data can be processed without complaint and output as yet more garbage.
- Unrelenting attention to syntax is essential. In Perl, you can have the most brilliant chunk of code imaginable and it will completely barf if you forget a semicolon. Python will do the same thing based on indenting or lack thereof.
- If your program relies on a file, you’d better have a check to make sure it’s there. Many programs will not crash and burn when a needed file is not found unless you specifically put in a checkpoint that will cause the program to “die” if the file is not located.
- Beware the infinite loop. When I first started learning to program I was an aficionado of the infinite loop. I would kick off a loop with a counter and fail to increment it properly. Or, in the days of BASIC I would use the infamous GOTO command and before you knew, it WHAMMO. So if you start a loop be sure you’ve created a way for it to end without having to abort the program. You can cause streetlights to dim this way. And I have.
- Practice safe variables. Variables are awesome but they are also dangerous. Initialize them properly, keep track of them (so you don’t inadvertently create a new variable with the same name), and by god reinitialize them when necessary. Just recently I failed to reinitialize a variable when processing a huge data file line by line. Since the variable was not reinitialized to nothing, it retained the previous line until eventually the last line of my output would have contained the entire file. Sadly, I really am that careless.
So…yeah. The thing about programming is that software is stone cold stupid. We must be smart enough to know what that means and how to mitigate the problems that arise because of it. When you’re not, you program like me. Even 30 years on.
Photo courtesy Timitrius, Creative Commons Attribution-ShareAlike 2.0 Generic License
About Roy Tennant
Another thing about coding possibly to add : keep your code clean.
I would try something in the code, realize it did not work or did not work well, and I would run another method in it’s place, but I would not go back and clean out the old not so great or good at all code or references just commenting out the old chunk of code to do nothing but sit idle on standby just in case the new part broke something. The thought was If my ‘new idea’ did not work down the road due to old starnards or was not faster or more efficient, I could go back to the ‘older’ version. What happened was I’d let those sucker lines of old or sometimes badly written initial code sit the code base like bad smelly mystery dish in the work fridge no one would claim only to haunt me later on growing mold and cluttering up the good stuff.
It is a good thing I don’t code for a living either, but I sure enjoy a good coding challenge on my level here and there. And I liken a clean code base with great internal comments and documentation as to having a nice clean and well organized desk to start a project.
Great comment, Steven. I agree — I will often comment out chunks of code that eventually are just dreck. I should be better about removing it entirely.
only 30 years? you beginner. i started programming 46 years ago (1968) on an IBM 360/30 at an insurance company. now i am doing “apps” on android and ios. but boundary conditions are still my bete-noir, i almost always am “off by 1” i also have a fetish about comments. read the code, not comments. the only time to put in a comment is if you are doing something that is confusing or overly complicated. then again, why are you? good luck and happy coding.