- 程序不会照自己所想的跑。只会照所写的跑。
- 我对软件设计的方式导出的结论，有两种方式。一是把软件设计得单纯到很明显不会有缺陷，不然就是把软件设计得复杂到没有办法看到明显的缺陷。
- 有意见的话你写。
- 要杀一个程序员不需要刀，改三次需求就好无论需求多晚才能确定，完工期限永远不会变。这是所谓的「期限守恒定理」。
- 客户总是觉得水跟追加需求是不用钱的。
- 一个人挂了大家都挂了。
- bug过了一晚可能就变成需求了。
- 顾客想受PM喜欢，要自己了解到系统开发需要时间与金钱，早点确定需求。PM想受顾客喜欢，则要让程序员讨厌自己。
- 很多PM跟程序员都暗自想着有钱有时间的话什么系统都想自己动手做，这样有成就感不过都没这种机会。
- 质量的劣化程度依需求改变的次数与规模而定。
- 业务是认为空想能够实现的梦想家。PM则是深信任何障碍都能突破的冒险家。程序员则是被梦想家和冒险家抛到漆黑海里的漂流者。
- 有才能的程序员第一次看到设计细节时，要先理解程序的目的。接下来要设法让PM了解到用指定的方法、时间并无法完成这个工作。
- 程序是运气与直觉堆砌而成的奇迹。若不具备这两者，不可能以这样的工时实现这样的需求。修改需求是对奇迹的*行为。而追加修改则是相信奇迹还会重现的愚蠢行动。
- PM需要持久力，程序员需要爆发力。
- 每天准时下班，工作会变多。
- 完美的程序需要完美的时间与金钱。
- 详细设计要在程序代码的批注里做完。批注是程序员唯一的自卫手段，至少要让自己看懂。
- 还有时间看程序代码的话就执行他。CPU跑得比脑细胞快。至少这时候可以休息。
- 程序的异常该称为「bug」还是「技术或需求上的限制」是看期限还剩多久决定的。
- 祷告上线没有问题，然后跑吧。
- 程序不是用脑记的，要用身体记住。
- 当谁写的程序代码跑出严重bug时，那个人通常都不在了（xxx定理？）
- 需求书就像航海图，客户则是水流。水流阴晴不定，航海图就变垃圾。
- 程序员必须在没有航海图的海上凭自己的力量找到大陆。
- 多想个10秒钟，你可以不说「嗯，这个做得到」。
- 人是无法从别人失败记取教训的动物。砍成本、改需求、加需求、赶上线，从来没有人从众多失败中记取教训。
- 老手用来提振精神的魔法格言：「比起以前来说算是轻松…」。新人用来提起干劲的魔法格言：「把这件工作做完的话…」他们还不知道工作是没有终点的。
- 程序、PM、经理不是职务。是逃不掉的连环责任。
- 能够迅速想到解法的程序员太多了。
- 他们能用一分钟想到方法，用一天去写程序。
- 上线后的除错才叫做bug。
- 追加需求确定后交货期限就无法确定，交货期限确定后追加需求就无法确定。这称为「追加需求与交货期限的测不准原理」。
- 除三个错就会冒出一个新错。这称为bug的无穷循环。
- 不祥的预感总会实现。不过程序员不应该去烦恼不祥的预感，那是PM的工作。
- 不懂计算机的操作者是发现bug的天才。而且他们通常无法重现那个bug。
- 每次开会就更改需求的客户，他的操作手册要等到程序上线后才能写出来。
- 程序员所不满的需求也一定会让客户不满。（这是说程序员觉得难写的地方常常是PM沟通有落差）
- 正因为健康，程序员才能做不健康的事。
- 那是你说的需求，真的。
- 坏了也是因为需求。
- 「程序代码的可信度，不会比写的人还可信。」
- 唯一不产生bug的方法，就是不写程序。第二好的方法，就是在期限跟人员确定之后的每次改需求，都重新检视过整个项目。(但通常大家都忘了)
- 共同责任是程序员的责任。
- 如果可以改行的话，想找个准时下班不叫「逃跑」的工作。
- 对职业程序员来说，漂亮的程序是单纯而自然的逻辑、简单而基本的指令、丰富的批注，也就是新手程序员也能马上动手改的程序。而要写这样的程序，需要单纯、简单、美丽的需求。但可惜客人总是喜欢搞很复杂。
- PM对程序员说的「常识」每三小时变一次。
- 小学生时第一次看到计算机，初中时第一次学会怎么用，高中与大学学会程序语言，出社会后才发现自己早就走错路
- 「不要让老板当业务需求比较好」
- 说来说去，要去研究根本不知道为什么会运行的东西为什么不会运行了，找爱迪生来也没搞头。
- 就算程序里没bug，编译器会有bug。就算编译器没bug，OS会有bug。就算一切都没bug，客户会决定什么是bug。
- 需求与需求书是不同的东西，通常都是。
- 比期限更重要的是灵感与睡眠。
- 比知识与经验重要的是手册与时间。
- 过了三天看上去就是别人写的程序代码。
- 无论怎么检查，不管怎么确认，上线前一晚就是睡不着。
- 没有什么事情比让一开始就找不到任何bug的程序直接上线还要可怕的了。