- 你的产品是一种资产，但代码是一种负债。
您的产品解决了客户的问题，因此是您的资产。代码本身就是创建资产的成本。您拥有的代码越多，就越需要阅读、测试、更改和理解。
- 重复比过早抽象的成本要低。
除非您非常有信心您的抽象能够为自己带来回报，因为它解决了您确实遇到的真实的抽象问题，否则不要这样做。等待并了解更多信息。在此之前，重复代码可以帮助避免依赖性，这本身使得代码更容易独立更改或删除。
过早的抽象会通过依赖和间接造成复杂性，并可能成为您响应变化的能力的瓶颈。
- 代码应该易于删除。
编写可移动的代码，这在很大程度上与“解耦”相同。当然，并非所有代码都需要类似地可删除。
但最大限度地减少依赖性、通过定义良好的接口具有清晰的边界以及周到的整体系统设计可以更轻松地删除/更改部件。
我喜欢这样的暗示：删除代码可以降低未来的成本。
- 不要用某一段代码的好坏来评判程序员的好坏。
代码只是一个时刻，它捕获了我们认为我们了解的某些事物，不能完全代表你。
你可能已经写了它，但从那一刻起（即使是 3 分钟前）你已经成长了，但代码却没有。
关于代码的讨论，无论好坏，都不应该是私人的。保持专业。谈论代码或问题，但不要谈论编写代码的人。
- 教学是一种变相的学习形式。
如果您认为自己知道某件事，请尝试教授它。通常，试图向别人解释你所知道的事情本身就会迫使你更清楚地形式化你自己的想法。
把事情写下来似乎也有类似的效果。
- 避免过快的做出决策。
我仍在学习这一点，并努力避免我几乎默认的快速决定的愿望。
事实是，你推迟非必要决策的时间越长，在做出决策时需要依赖的信息就越多。
当然，你不能总是拖延做决定，但通常你可以，而且至少你应该考虑现在不知道答案是否真的可以。
- 坚持使用无聊的技术，除非有充分的理由不这样做。
无聊的技术往往更古老，也更容易理解。
对于如何有效地使用它，我们有久经沙场的经验，可以更好地理解它的故障模式，并且更容易找到关于如何最好地应用它的人员和资源。
我真的很喜欢丹·麦金利的创新代币想法。你只能得到 3 个。用它们来采用或构建全新的东西——最好是能让你更好地发挥核心能力的东西——但任何超过 3 个，永远无法达到稳定/成熟的风险就会开始增加。
- 在你额外想到一个解决方案之前，不要选择那个仅有的方案。
当这件事在你脑海中闪现并且你意识到你找到了解决问题的方法时，这是诱人和令人兴奋的。
也许对于一个微不足道的问题来说这很酷，而且实际上没有什么可做的。但是，如果问题非常重要或不重要，则值得考虑可能还有您尚未想到的其他解决方案。
- 我们的价值不是我们了解一切的能力，而是我们学习、发现、回答这些问题和创造新问题的能力。
我们的行业发展很快，虽然有很多新的旧事物，但也有大量的新事物。我们每天都在学习，没有答案绝对没关系。
我们的价值不是我们了解一切的能力，而是我们学习、发现、回答这些问题和创造新问题的能力。
- 主动犯错。
几次完全错了然后重新开始可能比第一次尝试做对要快。有时，探索问题的最佳方法是深入研究问题并尽可能多地尝试。
也许您还没有真正理解问题空间，但是通过尝试一些事情，您可以发现有关设计的高级对话或阅读文档会完全错过的东西。如果你可以自由地犯尽可能多的错误，并在最后把它全部扔掉，你可以学得很快。
- 一个好的设计是你可以改变主意而不需要改变太多代码的设计。
变化是恒定的。这意味着我们需要很好地应对不断变化的条件才能取得成功——不仅仅是发生在我们周围并带领我们前进的外部变化，还包括来自枢轴、新功能、扩展挑战等的内部变化。
一个好的系统设计应该尽可能地适应我们改变解决问题方式的需要，而不强迫我们从头开始。换句话说，我们需要更改或删除的部分越少，我们面对变化的速度就越快；设计越好。