编程技术就是程序员的手艺，你的程序就是你的艺术品。时刻关注自己的技艺，保持热情、保持好奇，争取做到富有专长而又多才多艺。
看似朴素的道理，实际是若干经验的总结，就像这本书的自序所讲的，这是一本包含有许多朴素的经验，写给注重实效的程序员的一本“演员的自我修养”。
简单和朋友们分享几点：
怎样提出你的问题
1：确切地知道你想要问什么，并尽量明确具体；
2：小心而得体地组织你的问题，记住你是在请求帮助；
3：发邮件时请使用有意义的主题；
4：坐回椅子上，耐心等候
破窗
团队不能容忍破窗（产品的不完善的地方），需要指定人修复，不能一直放着不管。当你看到糟糕的设计、错误的决策和糟糕的代码时，修正它们。在工作中，很容易对源源不断的bug不耐烦，或许被自己说服侥幸绕过，以后就会有更多的直至难以修复。破窗户讲的故事是一个小区的一扇窗户没有及时维修导致整个小区陷入被更多破坏的现实，人们再想起维修时，代价巨大，治安特别好的地区也对破窗严格治理。
不要恐慌
做一次深呼吸，思考什么可能是bug的原因。记得刚入团队时，我时常会对难以捉摸，尤其是不能复现的bug感到恐惧，但细细寻找，你还是能看到蛛丝马迹。
温水煮青蛙
个人和团队假如一直在一个假设的环境或者需求或者条件下继续下去，就很可能像那只可怜的青蛙一样，或者定时的检测下环境或条件或需求是否变化，或者团队里面专门有人来检测
重复的危害
不要在系统各处对知识进行重复。作为程序员，我们收集、组织、维护和利用知识。我们在规范中记载知识、在运行的代码中使其活跃起来并将其用于提供测试过程中所需的检查。遗憾的是，知识并不稳定。所有这些不稳定都意味着我们要把很大一部分时间花在维护上，重新组织和表达我们的系统中的知识。程序员须持续不断地维护。我们的理解逐日变化，当我们设计或编码时，出现了新的需求。环境或许变了。不管原因是什么，维护都不是时有时无的活动，而是整个开发过程中的例行事务。可靠地开发软件、并让我们的开发更易于理解和维护的惟一途径，是遵循我们称之为DRY的原则：系统中的每一项知识都必须具有单一、无歧义、权威的表示。
正交性
不要把任何一项知识分散在多个系统组件中。在计算技术中，该术语用于表示某种不相依赖性或是解耦性。如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。非正交的例子：直升机驾驶操作的各个控制器之间就是相互影响的，不是正交的。
正交的好处就是为了可以局部修正（local fix）。
何时使用异常
将异常用于异常的问题。例如：文件读写，例程返回值，各种状态异常检测，服务器超时等异常情况，都需要使用异常，通常为异常分等级，可以抛出异常，或者将异常写入日志。
交流
我们不是活在真空世界，需要花大量时间与人交流。只有当你是在传达信息时，你才是在交流。
有效交流的几种方法：知道你想要说什么，了解你的听众，选择时机，选择风格，让文档美观，让听众参与，做倾听者，回复他人。
定期为你的知识资产投资
让学习成为习惯。编程语言、技术日新月异，小伙伴们都感受至深，幸运的是我们的知识获得比任何行业都更加容易和方便，大量的社区，教程和热心的作者。书中也给程序员提了几点建议，每年学习一门新的语言，每个季度阅读一本技术书籍等。
让复用变得容易
如果复用很容易，人们就会去复用。创造一个支持复用的环境。将相同的功能抽离出来，可能会大量用到的方法使用静态关键字。
在你的作品上签名
过去时代的会陷入自我欣赏中，他其实还有一个作用，我对代码负责，我测试过并确保他的良手艺人为能在他们的作品上签名而自豪。你也应该如此。坦白的说，签名之后再看这段代码会非常愉悦，有时还好运行，也是一种自我监督吧。
“我的源码让猫吃了”，想想作为程序员的我们，是不是经常会帮自己解脱，向领导，测试，客户推卸责任，其实对于他们仿佛也就好比听“我的源码让猫吃了”这句话，是不是很讽刺?不管我们某个人基础再扎实，解决问题的能力再强，如果缺失了对自己的软件的责任，一定不会有好的工作成果。
很多很多，这些不是做过一次两次就说明已经掌握了，需要一个持续的过程去注意，实践，直到他们成为你的习惯，这样，你才能成为一个“专家程序员”。
