Be your own best friend

I often find life’s axioms can apply to coding. Today’s lesson: be your own best friend!

Not complaining, and definitely not bragging, but sometimes I experience “genius strokes” – typically while coding. Unlike a stroke of genius, they can last hours at a time and the results can be difficult to live with in the long run.

Did I just write an entire CMS framework in a couple of hours and less than 1000 lines of code? Yes! That’s great! Do I remember how it works the next day? Maybe. Will I be able to understand and modify it in a meaningful way a month from now, when I’m not stroking out? Good luck… The dev team members at infsoln always groan when I announce a project involving genius stroke code. They know it will be difficult to comprehend the logic and figure out the inevitable clever twist that makes the whole thing work. We all hate clever.

One of the things that makes this code so difficult to work with is that it isn’t documented. Whether it’s because it seemed obvious at the time or because the ideas were flowing rapidly or even if I simply didn’t want people in my code, the lack of description and explanation is a real bummer. Just a few words could save those who follow (including myself) a tremendous amount of time and headache. It may sound psychotic to wish I had left notes to myself, but I think this almost daily. This needs to be a natural part of code-writing, as automatic as semi-colons and curly brackets.

Another issue I find when coding rapidly is terrible variable names. $spa might have made perfect sense when I created it, but wtf is that, honestly. If it requires even an instant of interpretation then it isn’t a good variable name. Every distraction like this is yet another item to temporarily remember in order to hone in on whatever it was that I was in there looking for in the first place. Knowing that my virtual desktop could catch metaphorical fire at any given moment on any given day, the easier and more direct the route to a solution, the better.

And thirdly (I won’t say lastly as there are so very many more basic things I can do to set myself up for success), DON’T HACK SHIT IN. Hacked together code full of shortcuts and lazy coding is nothing more than prototype code. If it makes it to production I am guaranteed to have future headaches. I need to take a few minutes to go back and figure out the correct variable name, or put queries in a data access object, etc… my code quality will improve drastically!

The conclusion, after a long session of trying to interpret my own code-writing, is that while it is fun to run and frolic freely in the meadow of logic, if I leave myself a few signs pointing back to reality then I will enjoy visiting the place again in the future. And it is always more fun when I bring my best friend with me!

Leave a Reply

Your email address will not be published. Required fields are marked *