Perfect Code

                In almost any industry, everyone is always looking for shortcuts for what they need to do to get the customers what they want.  This is both a good and bad thing, and you must learn recognize what is good, and what is easy. 

                For instance, building games, you have options, like selecting a previously existing game engine, or producing a new one of your own.  Another might be, Should we produce the hardware for this game, or use existing platforms or OS's?  Another might even jump further out and say should we use existing graphics processor chips, or design and build one ourselves.  The short cuts in all these would be to ultimately accept an existing engine that already works on existing hardware.

                While there are many directions I could go with this, I'm going to take another direction, and that is in our every day choices, particularly for programmers.  I've discussed the use of standards in previous articles, but once they are set, we are often faced with the decision of skipping ignoring it for speed.

                When I worked as an electrician, Dan Webster, the guy I was training under, "If you don't have the time to do it right, you certainly don't have the time to fix it."  So why do we find ourselves stepping out of our self-imposed standards when programming?  Because we have two stages of development, and we need to learn to keep them separate, those being: Practice and Perfection.

                You've probably heard this one, "Practice makes perfect".  Since perfect is a strong word, I'm not going to debate its philosophical implications.  Instead I'll offer this meaning for how I'm using it.  Perfect Code, is code that you can fully defend every line, every capitalization, every comment as to why you have used it in specific, and that you would trust this code in production. 

                While we sometimes produce Perfect Code, we often tend to produce Hack Jobs, just piecing together code in any way that gets it to work as quickly as possible, or Band-Aid code, as my wife calls it, because it may be gushing problems, but this dinky little band-aid seems to keep it together for the moment. 

                We need to face facts.  We are not as good of programmers as we think we are.  "The only true wisdom is in knowing that you know nothing" – Socrates.  Compare some of your own code.  If it was part that you have done a hundred times, you will find your code is naturally cleaner, closer to something that you consider Perfect Code.  But if it's the first time you've created it, you'll tend to find shortcuts all over the place, little hack jobs.  You often tend to find yourself going back over it to clean it up and try to bring it up to your Perfect Code standards.

                So what does this mean?  Here is a good rule of thumb: If you find that you aren't following your "Perfect Code" standards, because they are tedious while you are building this part, then forgo ALL of your "Perfect Code" standards, and call it a practice.  Once you have figured out what works in the code, go back and do it right.

                If you find yourself heading in the direction of practicing, in your real project, copy the whole solution over to a temp location to try working on it.  Once you have completed a solution once, go to your real project and rewrite it, only following all your standards.  It is impossible to follow the Perfect Standards, while your knowledge is imperfect.