To the average programmer in the trenches, debating the theory of computation is like discussing the chemical properties of saltpeter while in a gunfight: it may all be correct, but it doesn’t apply directly to the problem in front of them. Why waste time imagining the outcome of a deathmatch between Haskell Curry and Alan Kay when we’ve got a deadline to slap a new web UI over our legacy application? Why should we care whether we’re using a monad or an exception to return an error state? What the heck does “orthogonal” mean? Don’t give me a research paper, just give me code that works. And so runs the “get it done yesterday” logic.

From many a project manager’s point of view, programmers who dabble in computing theory pose an even greater danger than wasting time: they threaten to poison the project with new ways of doing things. This attitude is not entirely unjustified. Every new idea that promises to revolutionize software development seems to do quite a bit of damage to the industry before the hype wears off and it finds its proper place within the programmer’s arsenal of available tools. Converts to these theories try to squeeze every problem into the new mold whether it fits or not. Just as an appalling misapplication of the Theory of Evolution provided a justification for Nazi genocide, so has the misapplication of Object Orientation, for example, led to all manner of programming ugliness in the name of purism (may Godwin have mercy on my soul).

The history of programming is dotted by false starts and pendulum swings. I remember in the wake of Dijkstra’s famous Go To Statement Considered Harmful, myriads of programmers created all sorts of grotesque code contortions in order to avoid using a GOTO, even where one was badly needed. The slavish obedience to this and other rules of Structured Programming became so detrimental that once when the objection “It isn’t structured” was raised to an idea before the ANSI subcomittee on which I served, I replied “I don’t believe in Structured Programming.” The silent shock on every face made me expect to be instantly removed from membership. I might have, too, if my friend and mentor Ken Lidster hadn’t spoken up and explained that what I meant was that I objected to a legalistic interpretation of Structured Programming principles. He was right, though at the time I felt that he had watered down my bold assertion.

Nevertheless, the pursuit of programming theory does do us some good. If it weren’t for all the brainpower that’s been applied towards improving the practice of software development, we’d all be punching machine instructions on paper tape or Visual Basic on Windows. Thank goodness someone said, “There has to be a better way!” Thank goodness someone keeps on saying it.

Programming language developers aren’t the only ones whose work improves under this consideration. Despite the risk of fanaticism, journeyman programmers can also enhance their contributions (and hopefully, their careers as well) by exercising their skills in areas that lie beyond their strictly defined responsibilities. Especially where it lies just beyond their horizon, the question “How can we improve software development as a discipline?” may yield a significant payoff. The danger lies in half-learning and poor self-evaluation. As Alexander Pope famously said in his Essay on Criticism:

A little learning is a dangerous thing;

Drink deep, or taste not the Pierian spring.

The professional programmer should drink deeply. By cultivating a broad and deep understanding of our trade, accumulating a knowledge of its history, and keeping an eye on recent developments, he or she will develop the wisdom to distinguish hype from substance and to apply each tool to the purpose for which it is best suited.

Note: This post originally published on April 24, 2011.

Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.