charlie21

鉴于软件复杂度本身 (v2ex.com/t/975722?p=1)，系统设计水平如何？是否能很快定位到 bug 在哪，并且通过解耦来降低 “牵一发而动全身” 的情况

这要从软件工程复杂性从何而来说起
https://www.sohu.com/a/524801828_612370
https://github.com/Cactus-proj/A-Philosophy-of-Software-Design-zh
https://zhuanlan.zhihu.com/p/590534099?utm_id=0 浅谈 A Philosophy of Software Design 软件设计哲学 作者：John Ousterhout Tcl 脚本语言的创建者，并且以在分布式操作系统和存储系统中的工作而闻名

@cmdOptionKana 你的解读没错。但相信它呢它可以改变一个人的心情，这也就是信仰的特征要素之一：虽然无法证明，但相信（这一心理活动，在谁心中发生了）则（仅）对相信者有改变。信仰就是不能证明的，即使所有外部证据都在指向它为 false （所有外部证据都不支持它为 true ），该信还是信。

团队里现有 10 人，可以允许有 9 个人觉得关系最重要 + 1 个人觉得能力最重要
一旦团队的 10 个人有 10 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 11 个人并让他觉得能力最重要
一旦团队的 11 个人有 11 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 12 个人并让他觉得能力最重要
一旦团队的 12 个人有 12 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 13 个人并让他觉得能力最重要
一旦团队的 13 个人有 13 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 14 个人并让他觉得能力最重要
一旦团队的 14 个人有 14 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 15 个人并让他觉得能力最重要
一旦团队的 15 个人有 15 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 16 个人并让他觉得能力最重要
一旦团队的 16 个人有 16 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 17 个人并让他觉得能力最重要
一旦团队的 17 个人有 17 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 18 个人并让他觉得能力最重要
一旦团队的 18 个人有 18 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 19 个人并让他觉得能力最重要
一旦团队的 19 个人有 19 个人觉得关系最重要，那么必然开出一个新岗位：招纳第 20 个人并让他觉得能力最重要

至此，人的感官被愚弄：人感觉到趋势就是 “越来越多的人” 觉得关系最重要， “越来越少的人” 觉得能力最重要，这是人的感官被愚弄。
在人的行为上，一旦所有人认同关系最重要，则必然开出一个新岗位需求 for 一个觉得能力最重要的人，即使只有 1 个人干活儿，所有人在旁边看着。

至此，人的平均利益被稀释：本来 10 人团队能办成的事，现在 20 人团队才能办成。如果总受益不变，则人均受益下降。所以，总受益必然提升：多余的人必须想办法去提升总收益 —— 从 1 个干活儿的人的角度，19 个人在想办法（在并未把受益绑在能力上的情况下，把受益绑在关系上）以此增加总受益，这些相当于 19 个爱搞关系的牛马在为 1 个有能力的人打工

“爱面子” 相当于 “鼓励其他人 judge 自己”

你越 “鼓励其他人 judge 自己”，你越有可能 “爱面子”

你越 “爱面子”，你越助力到一个 “鼓励其他人 judge 自己” 的环境。由此形成一个闭环

这是一个收藏数量大于回帖数量的帖子

java 工资高，不是 java 导致的，而是大公司业务复杂度导致的

php 工资低，不是 php 导致的，而是小公司老板压榨员工导致的

总之，面向工资编程的时候不应该将某个语言直接映射为工资高低，否则会出现经典火鸡问题（ Russell's Turkey ）
https://zhuanlan.zhihu.com/p/20514116

放养是不可能放养的，若是亲生子 则这辈子都不可能放养

但我会劝别人放养