1、关心你的技艺
Care About Your Craft
除非你在乎能否漂亮地开发出软件，否则其它事情都是没有意义的。
2、思考！你的工作
Think!About Your Work
在你做某件事情的时候思考你在做什么。不间断地思考，实时地批判你的工作。这将占据你的一些宝贵时间，酬劳则是更为活跃地参与你喜爱的工作、感觉到自己在掌握范围日增的各种主题以及因感受到持续的进步而欢愉。从长远来说，你在时间上的投入将会随着你和你的团队变得更为高效、编写出更易于维护的代码以及开会时间的减少而得到回报。
3、提供各种选择，不要找蹩脚的借口
Provide Options,Don't Make Lame Excuses
不要说事情做不到；要说明能够做什么来挽回局面。不要害怕提出要求，也不要害怕承认你需要帮助。
4、不要容忍破窗户
Don't Live With Broken Windows
不要留着“破窗户”（低劣的设计、错误的决策、或者糟糕的代码）不修。发现一个就修一个。如果没有足够的时间进行适当的修理，采取某种行动防止进一步的破坏，并说明情势处在你的控制之下。
如果你发现你所在团队和项目的代码十分漂亮——编写整洁、设计良好，并且很优雅，你不会想成为第一个弄脏东西的人。
5、做变化的催化剂
Be a Catalyst for Change
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。
设计出你可以合理要求的东西，好好开发它。一旦完成，就拿给大家看，让他们大吃一惊。然后说：“要是我们增加...可能就会更好。”假装那并不重要。坐回椅子上，等着他们开始要你增加你本来就想要的功能。人们发现，参与正在发生的成功要更容易。让他们瞥见未来，你就能让他们聚集在你周围。
6、记住大图景
Remember the Big Picture
如果你抓一只青蛙放进沸水里，它会一下子跳出来。但是，如果你把青蛙放进冷水里，然后慢慢加热，青蛙不会注意到温度的缓慢变化，会呆在锅里，直到被煮熟。
不要像青蛙一样。留心大图景。要持续不断地观察周围发生的事情，而不只是你自己在做的事情。
7、使质量成为需求问题
Make Quality a Requirements Issue
你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。让你的用户参与权衡，知道何时止步，提供足够好的软件。
8、定期为你的知识资产投资
Invest Regularly in Your Knowledge Portfolio
让学习成为习惯。
持续投入十分重要。一旦你熟悉了某种新语言或新技术，继续前进，学习另一种。
是否在某个项目中使用这些技术，或者是否把它们放入你的简历，这并不重要。学习的过程将扩展你的思维，使你向着新的可能性和新的做事方式拓展。思维的“异花授粉”十分重要；设法把你学到的东西应用到你当前的项目中。即使你的项目没有使用该技术，你或许也能借鉴一些想法。例如，熟悉了面向对象，你就会用不同的方式编写纯C程序。
如果你自己找不到答案，就去找出能找到答案的人。不要把问题搁在那里。
9、批判地分析你读到的和听到的
Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。
10、你说什么和你怎么说同样重要
It's Both What You Say and the Way You Say It
作为开发者，我们必须在许多层面上进行交流。我们的时间有很大部分都花在交流上，所以我们需要把它做好。
如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处。
知道你想要说什么；了解你的听众；选择时机；选择风格；让文档美观；让听众参与；做倾听者；回复他人。
交流越有效，你就越有影响力。
11、DRY原则——不要重复你自己
DRY - Don't Repeat Yourself
系统中的每一项知识都必须具有单一、无歧义、权威的表示。与此不同的做法是在两个或更多地方表达同一事物。如果你改变其中一处，你必须记得改变其它各处。这不是你能否记住的问题，而是你何时忘记的问题。
12、让复用变得容易
Make it Easy to Reuse
你要做的是营造一种环境，在其中要找到并复用已有的东西，比自己编写更容易。如果复用很容易，人们就会去复用。而如果不复用，你们就会有重复知识的风险。
13、消除无关事物之间的影响
Eliminate Effects Between Unrelated Things
我们想要设计自足（self-contained）的组件：独立，具有单一、良好定义的目的。如果组件是相互隔离的，你就知道你能够改变其中一个，而不用担心其余组件。只要你不改变组件的外部接口，你就可以放心：你不会造成波及整个系统的问题。
你得到两个主要好处：提高生产率与降低风险。
14、不存在最终决策
There Are No Final Decisions
没有什么永远不变——而如果你严重依赖某一事实，你几乎可以确定它将会变化。与我们开发软件的速度相比，需求、用以及硬件变得更快。通过DRY原则、解耦以及元数据的使用，我们不必做出许多关键的、不可逆转的决策。有许多人会设法保持代码的灵活性，而你还需要考虑维持架、部署及供应商集成等领域的灵活性。
15、用曳光弹找到目标
Use Tracer Bullets to Find the Target
曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。
曳光弹代码含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是，一旦你在系统的各组件之间实现了端到端（end-to-end）的连接，你就可以检查你离目标还有多远，并在必要的情况下进行调整。一旦你完全瞄准，增加功能将是一件容易的事情。
16、为了学习而制作原型
Prototype to Learn
任何带有风险的事物。以前没有试过的事物，或是对于最终系统极其关键的事物。任何未被证明的、试验性的、或有疑问的事物。任何让你觉得不舒服的东西。都可以通过制作原型来研究。比如：架构；已有系统中的新功能；外部数据的结构或内容；第三方工具或组件；性能问题；用户界面设计等等。
原型制作是一种学习经验，其价值并不在于所产生的代码，而在于所学到的经验教训。
17、靠近问题领域编程
Program Close to The Problem domain
计算机语言会影响你思考问题的方式，以及你看待交流的方式。用你的用户的语言进行设计和编码。
18、估算，以避免发生