Monotony and Epiphany

Starting to work a full time job writing code for a semester has opened my eyes to many of the issues that software professionals speak of. Whenever applying myself to studies or homework assignments and projects, I’ve always done so with excitement and enthusiasm. There have always been moments of frustration, but always egging me on to find the proper solution. The wonderful opportunity I have now has introduced me to a new experience, however: the monotony of incremental progress.

In “Things You Should Never Do, Part I”, Joel Spolsky writes that programmers are naturally inclined to want to scrap old code and begin fresh, feeling that the old code is lacking too much to repair in one way or another. He offers the reason that code is harder to read than to write. While revising my own code I’ve come to the faulty (but not always false) conclusion that my code was bad because I had forgotten what certain chunks of my code were accomplishing. As if I were one of the coders in Spolsky’s blog post, I had fallen into the trap of thinking code was opaque for not having code completely memorized.

My desire to start anew was not always confined to my own project, though, as a couple of times I have thought of ways I would do things differently if I were involved in certain code building. While some of my ideas were certainly valid, this article made me come to the realization that a ground-up approach to coding with an already existing model is almost arrogant in most situations. Who am I to think that code I write will be any less buggy, or any more elegant? Am I somehow immune to forgetting about edge cases at the beginning of my implementation? This is especially true when the coder doesn’t fully understand the code he or she wishes to rework. How can you know that instability exists if you can’t understand the blueprint in the current moment? Of course, if a problem exists (agreed upon by all or most involved in the coding process) then corrections should be made, but Joel Spolsky has opened my eyes to the fact that the sometimes slow moving process of incremental iteration is entirely too important.