这是一本老程序员的经验之谈，有很多让我深有同感的例子。
说“不”一章，我身边的刚好有这样的两个程序，一个规划好自己的工作，懂得说“不”， 一个是老好人，对策划需求来者不拒，但常常bug缠身，通宵解决。
争论一节，我也有这个毛病，到最后争得变成了面子。
压力一章的故事，是我这一年来经常思考的，来心游这三年很类似于作者的1988年。
专业主义
担当责任。
每周要抽出20小时，看书、练习、学习，或者做其他能提升职业技能的事情。
说“不”
能就是能，不能就是不能。不要说‘试试看’。
- 专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”！
- 最要说“不”的是那些高风险的关键时刻。越是关键时刻，“不”字就越具价值。
- 许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。如果承诺尝试，你其实也在承诺将改自己原来的方案。你是在承认原来的方案中存在不足。
说“是”
专业人士不需要对所有的请求都回答“是”。 不过，他们应当努力寻找创新的方法，尽可能做到有求必应。 当专业人士给出肯定回答时，他们会使用承诺用语，以确保各方能明白无误地理解承诺内容。
编码
程序员并非天生便是好的协作者。
男程序员搞定一个程序时就感觉是制服了一头巨兽。 女程序员编写代码更像是一种培育创造之物的行为。
时间管理
邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。
关于会议，有两条真理：
- 会议是必需的;
- 会议浪费了大量时间。
争论/反对
Kent Beck曾告诉我一个深刻的道理：「凡是不能在5分钟内解决的争论，都不能靠辩论解决。」 这类争论之所以要花这么多时间，是因为各方都拿不出『足够有力的证据』来支持己见。 所以这类争论依据的不是『事实』，而是『信念』。
技术争论很容易走入极端。每一方都有各种说法来支持自己的观点，只是缺乏资料。 在没有资料的情况下，如果观点无法在短时间（5～30 分钟）内达成一致，就永远无法达成一致。 唯一的解决方法是『去取得资料，让资料来说话』。
有人会试着借助个人能力赢得争论。他们可能会提高嗓门，近距离与你对视，或者摆出不屑的姿态。 但这都不重要，长期来看，强迫是无法解决争论的，最终还是需要资料。
有人会表现得非常被动。他们同意结束争论，之后却消极对待结果，拒绝为解决问题出一份力。 他们会安慰自己说：「既然其他人想要这么做，就这么做吧。」这可能是非专业的行为中最糟糕的了。 千万千万不要这样做。如果你同意了，就必须拿出行动来。
该怎么得到解决问题所需要的资料呢？有时候可以做一些实验，也可以做些模拟或是建立模型。 但是有时候，最好的办法是抛硬币来决定到底该如何选择。
如果问题解决了，这个选择就是对的。如果遇到了麻烦，你可以退回来选择另一条路。 明智的做法是，选定一个时间点或者设定一系列标准，来决定什么时候该放弃。
要小心这类型的会议：它们的目的只是发泄情绪，或者让大家选边站。 如果会议上只有一面之辞，就要避免参加。
如果争论必须解决，就应当要求争论各方在5 分钟内向大家表明问题，然后大家投票。 这样，整个会议花的时间不会超过15 分钟。
压力
即使有压力，专业开发人员也会冷静果断。尽管压力不断增大，他仍然会坚守所受的训练和纪律， 他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法。