“传统智慧”认为，项目一旦进入编码阶段，工作主要就是机械地把设计转换为可执行的语句。我们认为，这种态度是许多程序丑陋、结构糟糕、不可维护和完全错误的最大一个原因。
编码不是机械工作。如果它是，20 世纪 80 年代初期人们寄予厚望的所有 CASE 工具早就取代了程序员。每一分钟都需要做出决策 —— 如果要让所有的程序享有永久、无误和富有生产力的“一生”，就必须对这些决策 进行仔细的思考和判断。
不主动思考他们的代码的开发者是在靠巧合编程 —— 代码也许能工作，但却没有特殊的理由说明它们为何能工作。在“靠巧合编程”中，我们提倡要更积极地参与编码过程。
尽管我们编写的大部分代码能够快速执行，我们偶尔也会开发出一些算法，可能会让最快的处理器都会陷入困境。在“算法速率”中，我们将讨论估算代码速度的方法，并且还给出一些提示，告诉你怎样在潜在问题发生之前就发现它们。
注重实效的程序员批判地思考所有代码，包括我们自己的。我们不断地在我们的程序和设计中看到改进的余地。在“重构”中，我们将讨论一些即使我们还处在项目中期，也能帮助我们修正现有代码的技术。
只要你在制作代码，你就应当记住，有一天你必须对其进行测试。要让代码易于测试，这样你将增加它实际通过测试的可能性；我们将在“易于测试的代码”中发展这一思想。
最后，在“邪恶的向导”中，我们建议你小心那些替你编写大量代码的工具，除非你理解它们在做什么。
我们大多数人都能够近乎自动地驾驶汽车——我们不用明确地命令我们的脚踏板，或是命令我们的手臂转动方向盘——我们只是想“减速并右转”。但是，可靠的好司机会不断查看周围的情况、检查潜在的问题、并且让自己在万一发生意外时处于有利的位置上。编码也是这样——它也许在很大程度上只是例行公事，但保持警觉能够很好地防止灾难的发生。