My friend, and part time lover, Noah Stokes wrote a small little piece on codin’. He makes an interesting assertion in it.

It’s frustrating to me when we treat the symptoms of our coding problems instead of treating the problems themselves. If we took our investigation a step further we could discover the root of the problem and work to remedy that for our future selves and future developers who hop into our code.

I think a lot about writing great code versus shipping great products. I believe that the two are, at a certain point, pitted against each other. The ancient mystical dilemma of “good, cheap or fast: pick 2” and how it affects what we can do as programmers. Even working on a product for a year, where there was a little breathing room to go back and re-visit old code, it was tough to make refinements.

What Noah touches on, and what I think strikes a nerve with all of us, is the ability to spend just a little more time and look just a little deeper. Do a little more research and solve the problem. In many cases I’ve found it’s very difficult to achieve that. In even more cases, the code I’ve shipped works but looks like the aftermath of a night of binge drinking at Kappa Drinking Alpha.

I empathize with Noah, but sometimes what was going through the head of a developer was “oh Sh*t, this project’s deadline is tomorrow”. I feel our chosen line of work, as a whole, could show more empathy for even the crap code. The problem is entering with a lack of context, which most of us do on these projects. Try to remember, when reading code, that there’s a lack of context on why things work a certain way and why there are sewed-on patches everywhere.