The major problems of our work are not so much technological as sociological in nature
《people-ware:productive projects/teams》
几个月前，我做了一个有关个人工程格言的演讲-大致讲了过去几年来在写代码，打磨产品(building things)以及跟人合作时,积累的一些有用而且一般来说都是正确的想法
格言是一个很有意思的单词，但是从词源学的角度追根溯源，axiom来自希腊语ἀξίωμα, 含义是“合适或值得思考的想法”。我喜欢这个说法，将我格言中的每一条都当作是值得深思的。
当然，他们都是根据我过往经验并且我认为有用的工程格言。你的个人经验可能有所不同。也许你已经了解了zero termination（C字符串通常用0结尾），抑或有比 scissors to remove bugs更好的工具。
不管怎样，我以为通过简要的阐述将格言清单列出来是件有趣的事情。有些表述可能相当平淡，但还是希望有人可以因此产生更多深入的思考或者有趣的不同意见。
这里只翻译了几个我认为比较重要的条目，有兴趣的可以直接看原文My Engineer Axioms
1. Change is contant
这条不应该有太多的争议。几乎万事万物都时刻在变化，包括变化本身（又想起那句“世界永远不变的是变化本身”）。我们不仅要认识到我们应对变化的能力至关重要，同时要意识到我们怎么做好一件事（时间，成本，质量，可靠性）通常是我们竞争力的衡量标准。
2. Your product is an asset, but code is a liability
你的产品解决了客户的问题，因此是你的资产。而代码本身是你创造这个资产的负债。代码越多，就需要更多的阅读，测试，修改以及理解。当你将此与格言1联系在一起时，这一点尤为明显。保守地接受新的代码（包括对外部代码的依赖）。最好的代码是你什么都不用写。
3. Duplication is less costly than premature abstraction
除非你十分确信抽象由于能解决一个实际/抽象的问题，能带来足够的收益，否则不要轻易做。等待并且学习更多（掌握足够信息后再做决策）。在此之前，重复的代码有益于避免依赖，这会让代码更容易修改或者删除。过早的抽象可能通过依赖或间接的方式引入复杂度，这个可能会成为未来你应对改变的一个瓶颈。
4. Code should be easy to delete
写的代码应该是可以随时移除的，从某种角度来说就是要“解耦”.可以肯定的说，并不是所有代码都需要保持同样的可移除状态，但最小化依赖，通过好的接口提供清晰的边界，并且慎重考虑整体的系统设计以便某些部分可以更容易的删除/修改。我以前听说有人使用“花出去的代码”而不是“写好的代码”，我喜欢这种表述;我倾向于说，删除代码就是减少未来的成本。
5. Existing Code exerts a powerful influence
一段代码存在就表明它是正确的，必要的。希望如此，但实际情况并不总是这样。我们需要保持两份信心去修改它，有能力推断是否我们应该修改它。不要让代码存在本身制造一种它不可被删除的疑惑。就像第4条说的那样，代码应该总是很容易的删除，而且一个好的系统设计应该使我们可以理解我们是否需要它。(给予已有代码足够的重视与尊重, 老的代码虽然有这样那样的问题, 但至少是经历了足够的验证测试, 可以很好的运行, 如果下定决心要修改老代码, 首先要吃透其中的逻辑, 修改后做好充分的验证测试)
6. Accidental complexity is one of the biggest risks
偶然性的复杂度是指那些本可以避免，却由于诸如糟糕的设计，错误的决策或者未将简单作为系统设计的首要原则等因素引入的复杂。如果简单不是一个目标，偶然的复杂则可能随着系统的扩展而出现，会逐渐的对几乎所有事情产生负面影响，从修改系统到理解设计背后的逻辑。2006年有一篇关于次主题的文章跳出焦油坑(out of tar pit)值得一读。
后面几条(7 ~ 10) 都是关于团队协作以及如何与人沟通的，只翻译了部分，其余可以参考原文
7. Technical execellence can be shadowned by bad personal skills
除非你单独工作，否则真正起作用的不仅仅是个人解决技术问题/写好代码的能力。相反，如果你使身边的人不开心或者效率变低，这些能力实际影响更小。正如写好代码需要学习，你必须学习如何与人相处。同理心是其中很重要的部分，要认识到每个人都并不相同-主动关心别人，理解他人，帮助别人，并请求他人的帮助，保持友好。努力成为一个别人愿意共事的工程师。
- (8) You are not your code. Be kind to the coder, not to the code
- (9) Treat people who know less than you with respect and patience
- (10) The only true authority stems from knowledge, not from position
- (11) Teaching is a form of learning in disguise
12. Lift the skills of people around you, not just yourself
优秀的团队绝不会因为一个厉害的就变得优秀。团队之所以优秀是因为每个人都互相挑战对方，每个人都相互成长。当你学习到某个有意思的东西，分享出来-帮助团队其他人变得更好。当其他人做同样的事情时，每个人都从中受益，没有人会落后。这样做可以获得更多的乐趣。第二点好处参考第11条。
13. The longer you wait the more you’ll know
我一直学习这一点，努力避免快速决策的内在冲动。事实上，对于非核心的决策，延迟越久，等到需要做决定时，获取到的信息就越多。当然你不能总是拖延决策，但是常常可以这么做;最不济的来说，你应该至少要考虑当前是否知道问题的答案是否可以接受。
14. A good type system is worth its weight plus some
有关编程语言类型的（略过）
15. The right team of people trumps everything else
有一个彼此愿意工作在一起创造好的产品的团队，会使很多其他问题更容易处理。这里的”对“其实是相当主观，情景相关的，但至少是秩闻一样。同理心，尊重，友谊一直是我待过的优秀团队的特质。
16. Stick to boring technology, unless there’s a good reason not to
无聊的技术通常更老，更好的被理解。为了更有效的使用这些技术，更好的理解其失败的模式，人们曾经有过通过挣扎的经历，因此通常更容易找到知道如何进行最佳实践的人跟资源。我很喜欢Dan Mackinley的Innovation tokens的想法; 你只需要3个无聊的技术。用它们来构建新的东西-最好是那些可以提升核心竞争力的东西。不要超过3个，否则会增加（技术）从未到达稳定与成熟的风险。
17. Have the smallest team possible, but no smaller. Grow it carefully
小团队可以更有效的合作，减少沟通摩擦（个人表述，原文翻译略）
18. Rest
长期996实在不够明智，除了身心疲惫，可能你也失去了自我学习与成长的时间与机会。偶尔996,平时多注意锻炼身体，放松自己（个人表述，原文翻译略）
19. Don’t pick a solution until you’ve thought of at least one more
在找到了一个问题的答案之前，不要匆忙解决问题，而是要尝试多几个解决方案，充分考虑各个条件的平衡（trade-off)。（个人表述，原文翻译略）
20. Have opinions, but avoid expressing them in ways that cause other people to believe you won’t change them
表达观点是不要太过肯定，不是100%确定，而是留有余地，为后续的沟通保持一定的空间（个人表述，原文翻译略）
21. It’s OK to say “I don’t know” or “I need to research that before I have an answer”
承认自己不知道某件事情，并不丢人;当你不知道某件事情，表示你愿意与对方一起探讨问题，是一种更为友好的姿态（个人表述，原文翻译略）
22. Writing throwaway code to explore a problem space is underrated
如果你对某个问题理解不够，允许自己犯错，写一些尝试性的代码，你可以学的更快（个人表述，原文翻译略）
23. Manage state carefully
管理好代码中的状态，认真对待系统中状态的变化（个人表述，原文翻译略）
24. It’s all about trade-offs
所有的工程决策都包含中某种平衡; 仔细考虑这些平衡，在你想要修改某个已有的代码设计时，考虑这一点，这样你可能会做出更好的决策（个人表述，原文翻译略）
25. A good design is one in which you can change your mind without changing too much code
世界不变的永远是变化本身。代码要面向未来的变化，系统设计要能适应未来的变化（对标产品，新特性等）（个人表述，原文翻译略）