程序员是世界上最依赖确定性的职业。
前两天我在逛 reddit 时看到国外一名前端小哥的吐槽：
每周我们按照需求文档和 Figma 设计做功能，今天上线，第二天就要重构——因为有人又改需求了。
…
我们要重新做第十次，只因为产品自己都没想清楚想要什么。
看来全世界不论是哪里的公司，都有不停改需求的习惯，程序与业务之间的矛盾是人类共同所面临的历史性问题。
程序设计是一条因果链。之所以会对变更需求存在抵触情绪，是因为之前的沟通中已经明确了需要的输入是什么，流程怎么走，每个分支如何捕获、错误如何处理等等每一处逻辑，一旦其中一个细节发生变化，整体都会受到牵连。
可以说，没有非常确定性的需求，就无法正常完成工作。
也因此，程序员会对确定性的细节有极强的执念，不能拿到事情的每一处细节的做法，就不清楚应该怎么完成工作。
编程是面向确定性的工作，而业务则完全相反，业务是在随机性的市场中动态地获取信息并转为自己的优势，是一种研究如何通过不确定性获益的工作。
业务会随着市场变化不断地调整，调整就意味着会优化原来的工作流，也就会调整对原有技术产品的需求。
在公司层层信息过滤后，对于「保护」在内部的程序员来说，只需要知道确定性的结果即可。
然而，编程之外的事情，并不像程序设计的那样，可抽象、可预期、可复用，一切都是动态的，毫无确定性可言。由于一直处于确定的环境中，长期就会生成「逻辑闭环」的思维，产生一种幻觉：稳定才是常态，变化才是例外。
职业的思维逐渐会主导自己，成为行为和思考的方法。
确定性给出了一个静态的思维模型，模型的背后是对波动性的不理解和厌恶，是对所不能控制事情的合理化，会天然的认为随机性的事情也会在自己掌控的范围之内，无视风险，一旦出现了偏差就认为是世界错了。
如 reddit 帖子中的用户，会恼怒于需求的变更，为了确保自身思维的正确性，建立起一种需求变化快等于团队不靠谱的逻辑，来解释自己理解世界的方法并没有问题。
用这个思路来看，我意识到非常多确定性带来的习惯：
- 旅行时的规划出现一点偏差，赶不上下一个打卡点，就会怪罪交通和天气
- 到了约好的时间，对方还是没到，就开始怀疑对方人品
- 找不到工作，认为是面试官故意出难题，或者是大环境不好
- …
总之一句话，就是句句不提自己的问题，错的是这个世界。
未来会杀死我的，从来不是世界有多混乱，而是我一直活在一个「需要一切都确定」的幻想里。
这个世界，从来没有义务按照我理解的方式运行。
真正需要升级的，也许不是需求文档和业务模式，而是自己的操作系统。
–> END