两次工作,两次被开除,理由几乎是同一份复印件:沟通不好,开工前不打招呼;活儿交得慢,还不说;交出去的东西质量不行,测试环境反复被搞崩,同事和客户都跟着上火。这位开发者后来做的第一件事,不是换个更自律的工作方法,而是去看了精神科——确诊重度抑郁,现在每天吃氟西汀和奥沙西泮,正在评估是不是ADD,靠社会福利过渡,暂停了写代码这件事。
他自己给出的解释是:自律不够,沟通太差,可能还有点ADD。这个答案很诚实,但未必是唯一正确的答案。
被算成“不自律”的,其实是一笔行业账
WHO 的估算是这样的:全球每年因抑郁和焦虑损失约1200亿个工作日,直接经济代价约1万亿美元;全球约5.7%的成年人患有抑郁症,专注力、决策力、精力和出勤都会被拖累。开发者这个群体不例外——Stack Overflow 2020年的调查里,近15%的受访者自报某种情绪障碍,其中7.2%明确选了抑郁症或双相。
这不是个别人扛不住,是一笔规模化的隐性成本,只是通常被记在个人绩效考核那一栏,而不是企业健康支出那一栏。
沟通不是性格问题,是中介变量
学界这些年在用“工作要求-资源模型”研究这类现象。一篇梳理了92篇软件工程倦怠研究的综述反复指向同一组变量:工作过载、角色模糊、心理安全感缺失,这些东西通过沟通质量和团队信任,一路传导到绩效和离职意愿上。顺序往往是反的——不是性格内向所以沟通差,而是先被压垮,才没心力沟通。
原文作者自己复盘,第一步该做的是“先沟通”,这恰好印证了模型里沟通既是果、也是因的双重身份。
- 结论.把结构性倦怠记成个人失职,账目好看,代价迟早要有人补。
倦怠不是匀速下滑
真正反直觉的一点来自一项针对372名印度开发者的研究:倦怠短期内没有拉低自评绩效,反而伴随更高的自评工作表现,同时伴随更差的组织认同和更差的人际关系。这和“病了就该表现差”的直觉不一样,更接近先透支、后崩溃——靠肾上腺素硬撑出一段高产出,代价是关系和沟通先垮掉,绩效才慢慢跟着垮。
其兴也勃焉,其亡也忽焉。
放在一个人身上也成立。原文作者的轨迹就是这条曲线:第一周信心满满,第三周动力归零,直接坠崖,中间没有过渡。
LLM拿走了那根保险丝
原文里有个细节值得多想一层:LLM让“多任务”变容易了,活儿可以甩给模型,代价是原本“必须测试才能交付”的强制路径消失了。以前状态再差,写完代码也得跑测试、过一次CI,这道关卡顺便是暴露状态不对的信号——测试老不过、部署老出问题,团队先看到“这活儿有问题”,再注意到“这个人可能有问题”。LLM能把活儿糊弄得看起来完整,那盏信号灯可能被提前拔掉了。
- 风险.LLM抹平了倦怠期原本会暴露出来的错误信号,问题只会拖到更晚、更大的时候才被发现。
目前学界对这件事几乎没有系统研究,谁在倦怠期靠AI侥幸多撑了几个月、又在哪个环节最终露馅,现在只是一个悬而未决的问题,不是一个已有答案的问题。
对个人来说,原文作者写下的教训是成立的:沟通要趁早,别等关系崩了才开口。但对组织来说,如果每年一万亿美元的账单摆在那儿,只把开发者的沟通差、交付慢当成绩效问题处理,更像是把结构性代价转嫁成了个人失败。WHO 自己算过一笔账:每往抑郁和焦虑治疗里投1美元,大概能换回4美元的健康和劳动能力。这笔账企业算得清,通常只是没人愿意先出这1美元。