注：【】部分为笔者心得，非原文摘抄。
- 好的软件作品，往往源自于开发者的个人需要。
- 优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么。
- 在你第一次把问题解决的时候，你往往并不了解这个问题，第二次你才可能知道怎么把事情做好。所以，如果你想做对事情，至少要再做一次。
- 如果你有正确的态度，有趣的事情自然会找到你。
- 当你对一个程序不再感兴趣时，你最后的责任就是把它交给一个可以胜任的接棒者。
- 把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径。
- 早发布，常发布，倾听用户的反馈。
- 如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。
- 德尔菲效应：一群专家（或一群无知的人）的平均观点要比一个随机选择的人的观点更有预见性。
- 对于一个被广泛使用的软件，其维护成本通常是开发成本的 40%或者更多。——弗雷德里克·布鲁克斯 ，《人月神话》作者
- 如果报告 bug 的用户对源代码不关心，则其报告通常不会很有用。对源代码不关心的用户，往往报告的都是表面症状，他们把自己的运行环境当成是理所当然的，他们不仅省略了重要的背景数据，而且很少给出重现 bug 的可靠方法。
- （就闭源软件而言）在一个已经延期的项目上增加人手，只会让项目更加延期。随着开发人员数目的增长，项目复杂度和沟通成本按照人数的平方增加，而工作成果只会呈线性增长。
- 聪明的数据结构配上愚笨的代码，远比反过来要好得多。
- 如果你把 beta 测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源。
- 仅次于拥有好主意的是，识别来自用户的好主意，有时后者会更好。
- 如果你发自内心地谦逊，并承认你欠别人很多，你将很快发现世界会这样对待你：他们认为是你发明了整个软件，而且你对自己的天赋有着得体的谦虚。
- 通常，那些具有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错的。
- 在不损失效能的前提下，不要犹豫，扔掉那些过时的特性。
- 设计上的完美不是没有东西可以再加，而是没有东西可以再减。
- 不仅是排错过程可以并行，开发和设计也可以并行。
- 任何工具都具备预期内的功能，但一个伟大的工具能给你带来预期外的功能。
- 写网关类软件时，尽可能不要干预数据流，而且绝不要扔掉信息，除非接收方强迫你这么做。
- 当你的语言还远不是图灵完备的时候，语法糖会让你受益很多。
- 系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。
- 当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到：
- 能运行；
- 让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。
- 项目领导人必须要有高度的设计直觉和聪明才智。
- 协调者是否拥有卓越的原创设计能力，并不是项目成败的决定性因素，但他是否能识别出别人的优秀创意，则一定是最关键的。
- 项目的协调人或领导人必须要有很好的人际交往和沟通能力。
- 技能可能有助于实现目标，但远远不是全部，人格特征也很重要。
- 想要解决一个有趣的问题，先去找一个让你感兴趣的问题。
- “利他”本身是“利他者”自我满足的外在表现。
- 如果开发协调者有一个至少像 Internet 这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战。
- 软件管理有五个功能：
- 明确目标并让大家朝同一个方向努力；
- 监督并确保关键细节不被遗漏；
- 激励人们去做那些乏味但必要的“体力活”；
- 组织人们部署并获得最佳生产力；
- 调配项目所需的资源。
- 乐趣预示着效率。
- 如果你在工作过程中感到恐惧和厌恶，就应该意识到过程已经出了问题。
- “玩”是创造性活动中最具经济效能的工作模式。
- 对于一个已有项目，走向开源不一定就能让项目免受目标错误、代码杂乱以及任何其它软件工程慢性病的困扰。
- 在交换经济下，社会地位主要取决于你有多少资源（并非只是物质资源）可使用或交易。
- 自称黑客不代表你就是黑客，只有其他黑客认为你是黑客，你才是黑客。
- 责任背后是权力。
- 如果一个人越是感受到自主性受限，其创造力就会越少。
- 给予激励是聪明的做法，但一定不能有附加条件，以避免把事情搞糟糕。
- 信息不对称会给市场带来负面影响。
- 如果满足下面这些条件，就该考虑开放源代码：
- 可靠性/稳定性/扩展性非常重要；
- 除了独立的同行评审，没有其它便捷易行的方法验证设计和实现的正确性；
- 该软件对客户的业务非常关键；
- 该软件创建或运转一个公共计算或通信基础架构；
- 关键方法（或能实现同等功能的方法）属于公共知识。