Vviewpoints
DOI: 10.1145/1409360.1409372
Kode vicious
permanence
and change
Highlighting the importance of doing one’s best in view of code
longevity and the impermanence of the changineer.
Dear Kv,
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?
fearing and Loathing Past code
Dear fearing and Loathing
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?
Kv
Dear Kv,
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.
feeling Loopy
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
