Highlighting the importance of doing one’s best in view of code longevity and the impermanence of the changineer.
When you first write a piece of code how long do you plan to maintain it for? Are you more careful in writing a significant class versus a 100-line, throwaway script? It can’t be the case that every piece of code you write has to undergo the same process and the same level of scrutiny as every other, can it? Do you ever just leave a piece of code behind and let it fade into the past?
I believe I am like other programmers in that there is plenty of code I’d like to forget. Unfortunately, although you can personally forget a piece of code, and at my age I have now forgotten more code than I’ve written—wait, is that possible? At any rate, although yes, you can forget old code, it never forgets you and thanks to the Internet many other people may be able to read what you’ve forgotten. If you’ve ever contributed to an open source project your code will probably never be lost, though perhaps it will be happily obscured by more recent checkins.
Having gro wn up with a mother who would make me redo my homework after saying, “Never time to do it right, always time to do it over.” I have more than a little bit of guilt associated with doing things right. Happily, I’ve since been able to work through some of the
guilt but there is still a thin patina of it present in my soul that makes me care for each piece of code as if it is something someone else will someday read, and I don’t want them to be disappointed. My main goal is for the code to be good enough that even if, in 10 years, when I see the code again, I won’t find it lacking. I have not always achieved this goal.
Computer programmers and engineers are in a unique position when it comes to the work we do. We are both scientists, dealing in the abstractions that help us solve problems as well as craftspersons, turning those abstractions upon our modern lathes that help make the modern world what it is. When we craft our code well it works more effectively and more beautifully, helping to create better systems. When we rush the job, and ignore the nicks and scratches, the parts fail to fit and eventually we’re left with software that looks more like that fort you built in the backyard when you were a child. Sure, it was fun to hang out in that fort, but you ran back to the house at the first sign of a real rainstorm.
My favorite word in Japanese is gan-barimasu, 頑張ります, which is a single word that takes the place of the English phrase, “Do your best.” If someone at work admonished you to do your best you’d probably think them a bit odd. The Japanese say this to each other relatively frequently, and they take the admonishment seriously, whether they
are sweeping a street, cooking food, building a house, or writing code. I admonish you to do the same with all your code.
When you make a practice of doing things right the first time, every time, it becomes easy and natural. So, yes, whether you’re writing a guidance system for an aircraft or a clean-up script for your mail folder, you should do your best. Someday someone else may need that code and you don’t want them to think your code is lacking, do you?
I was installing, or actually trying to install, some software the other day and was caught in this infinite loop of swapping software, hardware, and cables just to get one small thing to work. What a waste of time! There must be some way to avoid these types of loops.
Dear Loopy Clearly since you had time to write to me the loop wasn’t infinite, now was it? You know how to detect an infinite loop? Figure out how many times you’re willing to do the same thing without getting a different result and then stop after that many iterations! After all, insanity is often defined as doing the same thing over and over
References:
Archives