1、
程序员不擅长交际，但擅长说服别人。
2、
要习惯阅读别人的代码。
3、
通过阅读程序员的代码，主管可以从中了解程序员的能力，工作是否出色。
4、
在软件维护的过程中，被阅读最多的代码往往不是最好的代码，而是最需要重构的代码。
5、
如果程序根本无法正常运转，对其效率，适应性以及生产成本的评价就毫无意义。
6、
什么是程序中的毛病，在很大程度上取决于人的观点。如果这种毛病出现在你的程序中，你几乎不可能会认为它是毛病。
7、
在考虑一系列的程序的开发工作效果时，需要衡量开发时间的方差，而不是只考虑平均值。一般的开发主管宁愿先做
12
个月的计划，然后花
12
个月完成，也不愿做
6
个月的计划，却花了
9
个月。真正困扰人们的并非预先估计的平均开发时间，而是实际消耗时间的标准偏差。大多数人愿意每天花
10
分钟坐车，也不愿
4
天花
1
分钟，
1
天花
26
分钟。尽管就平均时间而言，后者花费更少，只需要
6
分钟。但是由于某次无法预测的长时间等待而将计划打乱，这点好处无法弥补损失。
8、
Fisher
基本定理：一个系统对某个特定环境的适应性越强，它适应新环境的能力也就越弱。为保证程序的效率，就必须考虑要解决问题的特殊条件。过分追求效率，只会降低适应性。但通常我们还是在二者之间做一取舍。至少，具备一种优点，要比哪种都没有强。
9、
衡量程序的真正效率，并不总能用运行时间来衡量。
10、
作为一个好程序，有一些重要的因素：该程序在多大程度上满足功能要求；该程序的开发是否按照计划完成，和计划的偏差幅度有多大；当条件改变时，是否能够修改，修改的成本有多大；程序的效率如何，为了弥补某一方面的低效率，是否牺牲了另一方面的高效率。
11、
主管根据什么来奖励程序员？在你的标准中是否存在相互矛盾的现象
?
即快又好，还要易与重构，容易修改？
12、
在你的项目中，修改或者重构是否属于一项主要开支？
13、
即使一个计划不可靠，只要它是完成进度的唯一希望（尽管可能根本无法完成），程序员还是会采用它，你知道为什么吗
?
14、
在进行某个项目的时候，你的脑子是否有一些明确的准则？或者是依照上级主管的看法？在项目的进行过程中，这些准则有无更改，或者你是否有办法让你的准则不被动摇？
15、
在编写程序时，你曾经有多少次想到它可能在未来会被人修改？反过来，在修改别人的程序时，你又曾经咒骂过几次？
16、
你是否因为追求“效率”，而延误了工作进度？反过来，是否因为要“赶时间完成”，而没有做到尽善尽美？
17、
在软件质量管理的过程中，软件性能的偏差使一个极其重要的方面。
18、
许多主管希望得到所有的东西，却不知道更重要的是应该通过明智的权衡，得到自己可能得到的最佳成果。
19、
爱因斯坦的名言：重要的是不要停止怀疑。如果不去进行尝试，我们永远不肯能成功。
20、
霍桑效应：因受到他人关注而带来提高或进步。关注手下工作的领导，将会取得更好的成绩。很多负责软件开发的主管，就是不愿意与属下并肩工作。
21、
最优秀的程序员同时也是那些最善于自省的。如果他们发现做错了什么，他们会对导致这个结果的思维过程（或物理过程）进行检讨；然后，他们会采取一些相应的措施，对这个过程进行调整。这种方法称为“根源分析”。然而更多人仍然喜欢使用“过失追究分析”方法，这种方法恰恰相反，它会诱导人们把引发问题的根源隐藏起来。