Article Outline
最近 996.ICU 火得不像样。
有多火呢？996.ICU 在本月的 Github 榜单上位居榜首，收获了140,000+ 个 Stars，比第二名 15,000+ 个 Stars 多了一个数量级。
按理说，大家对加班应该一直都深恶痛绝，但怎么才突然爆发呢。
996.ICU 的成因
在过去 10 多年，互联网行业得到了最多的红利。程序员不但享受远超其它行业的薪资水平，而且还有令人羡慕的优势：可变现的高增长期权和股权，以及 获得上市、收购巨额财富的机会。
如果你是一个程序员，既能拿高薪水，又有高概率获得超额收益，加点班又算得了什么。而且程序员作为一个爱学习的群体，加班就当学习了呗（某工程师原话）。
后来情况发生了变化：房价涨了、市场萎了、知识迭代开始有人跟不上了。
- 职场新人发现，虽然拿的薪水依然很高，但相比高消费和高房价而言还是有点吃力的，而且期权股权和上市的机会越来越盼不上。
- 老社畜则发现，虽然之前经济上的老本还能吃，业务能力是不能吃老本了，还得担心会不会进入财务/人事优化的名单。
总体来看，从业性价比变低。虽然加薪有点难，抱怨一下加班 996 还是可以的。
996 到底有没有问题
现在大多数对 996 的讨论都是一个鸡同鸭讲的状态。
- 公司老板：我 12127，希望你们可以 996；如果不开心可以不要玩，离职正好优化人员结构和财务，求之不得。
- 程序员们：我期权都没有，为什么要跟你一样玩命；如果不是因为现在就业情况不好我早就走了/给我签一个竞业协议明天就走。
说不到一起去，当然是有问题。公司用最粗暴的方式来评估程序员产出，程序员觉得受到了不公对待，也是有问题的。
如何量化程序员产出
软件开发的精细管理，比如量化，一直都挺困难的。
- 狭义上的项目管理：多长时间，多少人，多少钱可以完成开发任务。
- 广义上的商业价值：能卖多少钱，多少预期收益，在市场中的地位。
这个量化过程中的问题，集中体现在几类调侃中：
- "就差一个程序员了"，讲的是商业对技术的低估
- "程序员是产品经理的死敌"，讲的是产品人员对技术产出的不理解（反之亦然）
- "上班 996，看病 ICU"，讲的是老板对软件研发产出有误解，以为只要你一直在写代码，一天多写俩小时工资就没有白给
如果我们能解决软件开发的量化问题，也就可以缓解以上的问题。
以时间计量的逻辑
在互联网公司的 996 的管理思路中，分母是不变的“人*日”。所以加班、增加工作时间，是最粗暴地尝试提升生产效率的管理手段。
- 既体现了管理者的懒惰：执行这条管理规定太简单了
- 又表达了管理者的无奈：确实很难找到好办法来量化程序员的工作产出
某上市企业 ABB 还要求算法工程师排夜班…… 嗯，真是一言难尽。
以代码行数计量的逻辑
听上去很不可思议对吗？程序员们一般只在调侃时才会提到代码行数的多寡。
但在 2016 的 Facebook，扎克伯格曾钦点把代码行数作为绩效指标，甚至有些主管的 bonus 有 50% 由团队在上季度提交的代码行数来决定。
这背后的逻辑是，虽然有无数的 corner cases，代码行数和开发团队的产出长期来看仍然是正相关的，而且交付更多代码的团队往往有更多的机会去学习、试验和探索，从而为公司创造更多价值。
更好的度量方式？
为什么程序员的工作产出难以量化？有人说因为软件开发是创造性工作，是半门艺术，拒绝量化。
一方面，我不认同拒绝量化。相比土木、医药等其它工程行业，计算机软件还非常年轻，人们从行业高速发展获得的红利远超精细化管理所付出的成本，但这并意味着不需要精细化管理。
但另一方面，我认为软件研发的量化确实特殊。比如 Linux 内核组的工作如何体现价值？虽然内核只有 2500 万行代码，但却被百亿台手机、7000万台服务器、和其它不计其数的设备运行，Linux 内核开发人员是否有机会得到相应的经济收益？
发展初期存在的非标准化、作坊式工作方式，是阶段性状态，不可能称为行业的常态。996.ICU 就证明了这一点：工程师对加班的反抗，本质上是对时间计量的不满，对不精细的产出量化方式的不满：
程序员：当我们是民工吗？
实际上，软件工程作为一门工程学科，评估、量化其行业产出是很有价值的事，因此一直都有学者致力于此。
比如说 Biff 的 VBSE 模型，B.Boehm 和 Ivan Mistrik 等人的研究，尝试设计软件工程经济学指标。
而 Jennifer Marlow 和 Jason Tsay 等人的论文则从开源软件社区探讨研发团队效能的评估。
无论是学者还是工程师，都希望能用更精细的方式来量化软件开发产出。我的校友，任晶磊博士的团队也在这方面有很深入的研究，他们最新的论文 "Towards Quantifying the Development Value of Code Contributions" 讲诉了如何运用抽象语法分析和机器学习，实现一种更精细的软件开发工作计量方法。
现在可以在 https://meri.co 体验他们的 Demo。下图是对 Bitcoin 的量化分析报告（局部）：
报告中，虽然创始人中本聪在 2010 后没有贡献过一行代码，但他写的核心代码依然有 2.92% 的贡献度，总排名第六。可见在精细的量化方法下，有价值的代码依然会得到客观的评价。
程序员的民工化
未来程序员的分化可以预见：民工化和精英化。
程序员：当我们是民工吗？
是的。即便是在行业最前沿工作的程序员，也并非总在做创造性工作，相关的事务性工作总是不可避免，俗称"搬砖"。
而在行业的中下层，大量的程序员确实只是在"搬砖"，比如写一些增删改查的东西，996 了自然能多搬几块是几块。
各国政府鼓励和开展编程教育说明了我们需要更大规模，工程化更强的软件生产方式，是所有工程化行业不可逆转的趋势。
那么精英化呢？
很多程序员都喜欢称自己为“手艺人”，喜欢讲“三个石匠“的故事：
有人问三个石匠他们在做什么。第一个石匠回答：“我在养家糊口。”第二个石匠边敲边回答：“我在做全国最好的石匠活。”第三个石匠仰望天空，目光炯炯有神，说道：“我在建造一座大教堂。”
— 德鲁克《管理的实践》
德鲁克认为第三个石匠是真正的管理者，我们则觉得自己有第三个石匠的心。
但这个故事的问题就在于，它太简单了。第三个石匠不会告诉你，要想造大教堂专心当石匠是不够的。你还得学习很多其它的技能，比如绘图、计算、选材、财务记账、客户沟通、气候分析、生产规划、质量检查、团队管理……
正如第三个石匠不仅仅是一个石匠，精英程序员也不仅仅是一个程序员。
