原文链接：My Engineering Axioms
摘要
- 变化是永恒的
- 您的产品是一项资产，但代码是一项负债
- 重复比过早抽象的成本要小
- 代码应该易于删除
- 现有代码具有强大的影响力
- 它存在的事实本身就表明它是正确和必要的。希望如此，但并非总是如此。我们需要保持改变它的信心，以及推理是否应该改变的能力。不要让代码本身的存在产生无法删除它的怀疑。
- Accidental complexity is one of the biggest risks.
- 由于设计不佳、决策不当以及没有在系统中优先考虑适当的简单性等因素而发生的
- 糟糕的个人素质可能会掩盖技术上的卓越
- 做一个别人愿意与之共事的工程师，比技术更重要（除了独立工作者）
- 你不是你的代码。善待程序员，而不是代码
- 你写了代码，但从那一刻起（即使是 3 分钟前）你已经成长，但代码却没有。关于代码的对话，无论好坏，都不应该涉及个人。保持专业。谈论代码或问题，但不要谈论编写代码的人。使用“我们”而不是“你”。有时我会假装我写了别人写的代码，这有助于我避免无意中听起来很个人化。
- 尊重并耐心对待那些懂得比您少的人
- 唯一真正的权威来自于知识，而不是地位
- 教学是变相的学习
- 提升周围人的技能，而不仅仅是你自己
- 等待的时间越长，你就会知道的越多
- 你拖延非必要决定的时间越长，你在做决定时需要依赖的信息就越多。当然，你不能总是拖延决定，但通常你可以，至少你应该考虑现在不知道答案是否真的可以。
- A good type system is worth its weight plus some.
- Having gone backwards and forwards through various static and dynamic languages over my career, I’m currently of the opinion that a good type system is worth its overhead. A good type system shouldn’t carry all that much overhead. If the type system is designed well, it can almost feel like a dynamic language (via features like inference and flow analysis) while removing a whole class of issues that the compiler can handle far better and quicker than you can. Developments like ownership in Rust are a nice example of how this has gone even further than people would have imagined years back.
- 正确的团队比一切都重要
- 这里的“正确”一词非常主观，而且与具体情况有关，但至少从传闻来看，同理心、尊重和友谊是我所参与过的优秀团队中反复出现的元素。
- 坚持使用无趣的技术，除非有充分的理由不这样做
- 组建尽可能小的团队，但不要更小。谨慎发展团队
- 休息
- Don’t pick a solution until you’ve thought of at least one more
- 你可以有自己的观点，但表达方式要避免让别人认为你不会改变他们
- 例如：“我 95% 确定使用 Visual Basic 是个坏主意。”即使只有 95%，这既是让别人质疑你的观点并展开对话的机会，也是你获得新信息后重新修正你的确定性的机会。
- 可以说“我不知道”或“我需要研究一下才能找到答案”
- 我们的价值不在于我们了解一切的能力，而在于我们学习、发现、回答这些问题和创造新问题的能力。
- Writing throwaway code to explore a problem space is underrated
- 犯几次错误然后重新开始可能比第一次就尝试做对更快。
- Manage state carefully
- 一切都无非是权衡
- 好的设计是你可以改变主意而不需要改变太多代码的设计
- 让我想到了《程序员修炼之道》ETC（Easier to change）价值观