程序员的思维修炼笔记

程序员对负责架构、需求甚至业务流程的相关人员的反馈要么根本没有，要么被严词拒绝，要么干脆被大家遗忘在脑后。程序员经常实现一些他们明知道是错误的东西，忽略了明显的警告信号，这非常类似于上例中的护士行为。敏捷方法有助于促进所有团队成员的反馈并有效利用，但这只是成功的一半。

很真实，有段时间开发的时候总是在做一些明知道没用，甚至过几个版本就会完全重构甚至被剥离的模块，但是还没法拒绝。
整理下一些观点：
- 混淆模型和现实
- 低估不能形式化的特性
- 规定违背个人自主性的行为
- 偏袒新手，从而疏远了经验丰富的员工
- 阐明太多细节
- 把复杂局势过于简单化 ps:阐明细节不代表明确复杂化，复杂和细节没有关系。
  
  每个项目、每种情况都比那更复杂。每当有人开始说：
  
  “你需要做的仅仅是......”或者“只需要做这个......”，他们十之八九错了。
- 追求过度一致
  
  同样的标准不可能放之四海而皆准。上一个项目里最管用的东西对当前这个项目来说可能是一场灾难。
- 忽视情境的细微差别
  
  形式方法针对典型情况，而不是特殊情况。但是，“典型”真的会发生吗? 情境对专业表现至关重要，而形式方法往往会在它们的公式中丢掉情境的细微差别
- 在遵从规则和自行判断之间犹豫
- 故弄玄虚
  
  语言表达如果过于口号化，它就会变得微不足道，并最终完全失去意义(例如， “我们是一个以客户为中心的组织!”)。
不要屈服于工具或者模型的虚假权威。没有什么可以替代思考。
正如你所看到的，只是因为你“认为是这样”并不代表这是正确的。认清和克服自己的认知偏见说起来容易，做起来难。

记住标题:“很少”不意味着“没有”。

我们对定论的渴望意味着我们总是努力消除不确定性。但是过早地下结论减少了你的选择，甚至可能消除了成功的选择。

最后，为了避免一厢情愿、盲目乐观的想法，记住任何一个决定都是一种权衡。不是没有免费的午餐。凡事总有两面性，仔细权衡——积极和消极的两面——有助于确保你更全面地评估形势。
总会有新技术或者现存技术的新版本需要学习。技术本身并不重要，持续学习才是最重要的。
失败是成功的关键——但不是任意的失败，你需要管理好失败。你需要有良好的学习环境来帮助你，这样你可以更容易地从失败和成功中积累并应用经验。