1、程序不会照自己所想的跑。只会照所写的跑。
2、我对软件设计的方式导出的结论，有两种方式。一是把软件设计得单纯到很明显不会有缺陷，不然就是把软件设计得复杂到没有办法看到明显的缺陷。
3、有意见的话你写。
4、要杀一个程序员不需要刀，改三次需求就好无论需求多晚才能确定，完工期限永远不会变。这是所谓的「期限守恒定理」。
5、客户总是觉得谁跟追加需求是不用钱的。
6、一个人挂了大家都挂了。
7、bug过了一晚可能就变成需求了。
8、顾客想受PM喜欢，要自己了解到系统开发需要时间与金钱，早点确定需求。PM想受顾客喜欢，则要让程序员讨厌自己。
9、很多PM跟程序员都暗自想着有钱有时间的话什么系统都想自己动手做，这样有成就感不过都没这种机会。
10、质量的劣化程度依需求改变的次数与规模而定。
11、业务是认为空想能够实现的梦想家。PM则是深信任何障碍都能突破的冒险家。程序员则是被梦想家和冒险家抛到漆黑海里的漂流者。
12、有才能的程序员第一次看到设计细节时，要先理解程序的目的。接下来要设法让PM了解到用指定的方法、时间并无法完成这个工作。
13、程序是运气与直觉堆砌而成的奇迹。若不具备这两者，不可能以这样的工时实现这样的需求。修改需求是对奇迹的亵渎行为。而追加修改则是相信奇迹还会重现的愚蠢行动。
14、PM需要持久力，程序员需要爆发力。
15、每天准时下班，工作会变多。
16、完美的程序需要完美的时间与金钱。
17、详细设计要在程序代码的批注里做完。批注是程序员唯一的自卫手段，至少要让自己看懂。
18、还有时间看程序代码的话就执行他。CPU跑得比脑细胞快。至少这时候可以休息。
19、程序的异常该称为「bug」还是「技术或需求上的限制」是看期限还剩多久决定的。
20、祷告上线没有问题，然后跑吧。
21、程序不是用脑记的，要用身体记住。
22、当谁写的程序代码跑出严重bug时，那个人通常都不在了（xxx定理？）
23、需求书就像航海图，客户则是水流。水流阴晴不定，航海图就变垃圾。
24、程序员必须在没有航海图的海上凭自己的力量找到大陆。
25、多想个10秒钟，你可以不说「嗯，这个做得到」。
26、人是无法从别人失败记取教训的动物。砍成本、改需求、加需求、赶上线，从来没有人从众多失败中记取教训。
27、老手用来提振精神的魔法格言：「比起以前来说算是轻松…」。新人用来提起干劲的魔法格言：「把这件工作做完的话…」他们还不知道工作是没有终点的。
28、程序、PM、经理不是职务。是逃不掉的连环责任。
29、能够迅速想到解法的程序员太多了。
30、他们能用一分钟想到方法，用一天去写程序