黑客与画家
9.类似画家临摹，黑客也需要通过实践和模仿学习编程
黑客通过实践学习编程，这又是一个标志，说明黑客与科学家的区别有多大。科学家就不会通过干活来学习科学，而是通过做>实验和解题来学习。科学家研究的基础都是现有的很完美的成果，在这个意义上，他们的第一步只是在复制别人已经做过的工作。最后，他们才会从某一个点开始，进行自己的原创性工作。但是，黑客就不一样，从一幵始做的就是原创性工作，根本没有他人完美的成果可以依靠。所以，黑客的出发点是原创，最终得到一个优美的结果；而科学家的出发点是别人优美的结果，最终得到原创性。
同样地，黑客可以通过观看优秀的程序学会编程，不是看它们的执行结果，而是看它们的源代码。开源运动最鲜为人知的优点之一，就是使得学习编程变得更容易了。
10.不要过早设计，先实现功能再逐步优化
我认为黑客也应该这样工作。你不能盼望先有一个完美的规格设计，然后再动手编程，这样想是不现实的。如果你预先承认规格设计是不完美的，在编程的时候，就可以根据需要当场修改规格，最终会有一个更好的结果。眼下想必每个人都知道，过早优化（premature optimization）是一件危险的事情。我认为，我们应该对“过早设计”（premature design）也抱有同样的担忧，不要太早决定一个程序应该怎么做。
11.黑客代码的每一个细节都是精心制作的
同样地，优秀的软件也要求对美的狂热追求。如果你查看优秀软件的内部，就会发现那些预料中没有人会看见的部分也是优美的。
12.工作都有工作周期，应当适时调整
黑客就像画家，工作起来是有心理周期的。有时候，你有了一个令人兴奋的新项目，你会愿意为它一天工作16个小时。等过了这一阵，你又会觉得百无聊赖，对所有事情都提不起兴趣。
13.合作也要分工明确
我认为，这也是多人共同开发一个软件的正确模式。需要合作，但是不要“合”得过头。如果一个代码块由三四个人共同开发，就没有人真正“拥有”这块代码。最终，它就会变得像一个公用杂物间，没人管理，又脏又乱，到处堆满了冗余代码。正确的合作方法是将项目分割成严格定义的模块，每一个模块由一个人明确负责。模块与模块之间的接口经过精心设计，如果可能的话，最好把文档说明写得像编程语言规范那样清晰。
14.站在用户的角度设计
就像绘画作品一样，大多数软件是为人类用户准备的。所以，黑客必须像画家一样，时刻考虑到用户的人性需要，这样才能做出伟大的产品。你必须能够站在用户的角度思考问题，也就是说你必须学会“换位思考”。
另一条路（互联网应用是大势所趋）
1.互联网应用比桌面应用更为便捷
现在，可以有另一种方法发布软件，用户再也不会被迫当上系统管理员了。互联网软件运行在服务器上，用户界面就是网页。对于普通用户来说，使用这种新型软件将更容易、更便宜、更机动、更可靠，通常也比桌面软件更强大。
2.数据应该保存在服务器上
终端设备不应该存储数据，它们应该像电话那样。事实上，终端设备最后可能就会变成电话，或者反过来，电话变成终端设备。终端越做越小后，你可以每天把它带在身上，就更没理由把数据存储在上面了，万一遗失或者被窃就很麻烦。
3.服务器可以自由配置硬件和选择编程语言
只要你控制了硬件，就能为用户提供更多的功能。如果你的产品是桌面软件，你就只能规定硬件的最低配置，无法为了某一个功能而要求用户增加硬件。但是，如果你控制了服务器，你就能轻而易举地增加功能，使用户可以发出寻呼、发送传真、通过电话操作网站、使用信用卡付款等。你所需要做的只是安装相关的硬件。
对于互联网软件，没人规定只能使用某些语言开发，因为所有的硬件都控制在你手里，你想要用什么语言，就能用什么语言。不同的语言适合不同的任务，你应该根据不同场合，挑选最合适的工具。尤其是在竞争者存在的情况下，“可以这样做”就变成了“必须这样做”，因为如果你不利用语言的优势，那就会听任对手超过你。
4.互联网软件可以及时更新
对于互联网软件来说，大部分的变化都是细微和渐进的，所以引入bug的机会比较小。而且，在发布前测试的时候，你知道应该最仔细地测试哪个部分——显然就是你修改过的部分。
互联网软件的发布规则是：它运行不了，你就无法发布；一且它能运行了，你就可以立刻发布。
5.自动侦测错误并快速解决
互联网软件的另一个技术优势在于，你能再现大部分的bug。用户的数据都在你的硬盘上。如果某个用户使用软件时出错了，你就不必像开发桌面软件那样苦苦猜测到底发生了什么事情。一般来说，只要用户通过电话向你描述一番，你就能把问题再现出来。如果你的程序中有自动侦测错误的代码，那么不用等到用户找上门，你可能已经知道哪里出错了。
早一点发现bug就不容易形成复合式bug，也就是互相影响的两个bug。举例来说，一个bug是楼梯很滑，另一个bug是扶手松了，那么只有当这两个bug互相作用时，才会导致你从楼梯上摔下来。在软件中，复合式bug是最难发现的bug，往往也会导致最大的损失^。传统的方法是：“把软件彻底拆开，将所有bug统统清理干净。”这样做难免产生一大堆的复合式bug。如果软件是经常性发布，每次只有小幅度的变化，那么就不容易产生复合式bug。