对于一线的一般程序员来说，辩论计算理论就像讨论在枪战中的硝石的化学性质一样：其可能是正确的，但并不能直接适应于前面所面对的问题。在我们得到在遗留应用程序之上拍击获取新的网页用户界面的最后期限时，为什么要浪费时间来猜测Haskell Curry 和 Alan Kay之间的死亡竞赛的结果？为什么我们应当关心是否使用返回错误状态的单子或例外案例呢？“正交的”到底意味着什么？不要给我一份研究报告，只给我那些可以工作的代码。这运行的是“昨天已完成”的逻辑。

  从很多项目经理的立场看来，那些涉猎计算理论的程序员构成了比浪费时间更严重的危险：他们被威胁使用做事情的新方法来败坏项目。这种态度并不是完全不正当的。每一个承诺彻底改革软件开发的新理念，在其大肆宣传逐渐消失、其在程序员的可用工具兵工厂内部找准其合适位置之前，似乎都对该产业造成了相当多的损害。到这些理论的转变试图将所有问题都挤压到新的模具中，不管其合适与否。因此会产生面向对象的误用，例如，以纯粹主义（或许Godwin会怜悯我的灵魂）的名义导致各种各样的程序设计丑陋。

  程序设计历史由错误起点和不定的摇摆点缀其中。我记得随着Dijkstra著名的被认为有害的转向语句而来的是，无数的程序员创建了各种各样奇怪的代码扭曲，以避免使用GOTO，即使他们非常需要。对这个以及结构化程序设计的其它规则的奴隶式服从变得如此不利，以致于一旦出现“这不是结构化的”反对，就会在我之前服役的ANST从属委员会之前上升为一种理念，而我回复“我不信仰结构化程序设计”。在每张脸上的无声的震惊使得我期望能够立即移除成员资格。要不是我的良师益友Ken Lidster大声说出并解释我的意思是我反对对结构化程序设计原则的尊重法律式的解释，我可能也会如此。他是正确的，尽管在那时我感觉他对我的大胆断言大打折扣。

  然而，对于程序设计理论的追求确实给我们带来了一些好处。如果其不是为了所有应用于提高软件开发的实践的智囊团，我们可能全部都是在纸带上的打卡机指令或者在Windows 上的Visual Basic。谢天谢地有人说过“一定会有更好的办法！”。谢天谢地，还有人在继续这样说。

  程序设计语言开发人员并不是那些在该考虑之下工作以提高的唯一人员。尽管有盲从的危险，熟练的程序员也可以通过在超过其严格定义的职责范围的区域使用他们的技能来提高其贡献（同时有希望地提高他们的职业生涯）。尤其是在只是超过了他们的视野的地方，问题“作为一种纪律我们应当如何提高软件开发？可能会生成重大的回报。危险在于半知半解和贫乏的自我评价。正如Alexander Pope在其论批评 中有句著名的话：

  学识浅薄是件危险的事；深饮，否则尝不到甘泉。