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、
最優秀的程序員同時也是那些最善于自省的。如果他們發現做錯了什么，他們會對導致這個結果的思維過程（或物理過程）進行檢討；然后，他們會采取一些相應的措施，對這個過程進行調整。這種方法稱為“根源分析”。然而更多人仍然喜歡使用“過失追究分析”方法，這種方法恰恰相反，它會誘導人們把引發問題的根源隱藏起來。