最近看到这个问题被谈得很多。铺天盖地的35岁、内卷化、996。这里也想谈谈自己的想法。
1）内卷化的形成
内卷为什么会形成呢？从公司内部的角度来说，同事之间做的事情也缺少独特性。那么既然每个人都差不多，那么与其招一个工作十年的人，还不如招个应届生。虽然说从代码的产出和质量来说，工作十年的工程师比应届生理论上来说应该是好很多， 但是如果工作十年的人缺少积累，缺少系统性的理解，那么跟应届生比较可能多了一些广度（因为换过工作）。但是深度上来说并没有本质上的区别。那么这个时候就会发生内卷了，公司不停的把老员工换成新员工，老员工也不停的跳槽导致缺乏积累，长此以往公司很难得到优质的员工，员工也很难得到深入的知识和技能的积累。
如果把这个发到公司之间，那么很多公司间的竞争也是重复性的，你做个朋友圈，那么我就做个拼圈，如果你做个金融服务，那么我也做一个。公司的产品决策并不完全是跟公司本身的基因和方向决定，而是因为什么方向火而赶鸭子上架。公司在做决策的时候考虑的是最少的投资和最快的回报，而不是靠着自己的特性而做长久的、独特的产品发展。在做这样重复建设的时候，公司可能会在竞争对手那里挖上那么几个牛人，然后其他的（包括UI）都照抄就好。长此以往，用户、客户很难用到更好的产品，而公司也很难积累出做出好的产品的能力。
2）从内卷到996
既然公司间都内卷了，公司做的产品跟别人的产品差不多，那么拼的就是手速了。如果竞争对手和你拿的投资差不多，那么招的人数也接近，如果竞争对手都996了，那么你955岂不是输在了起跑线上？同理，大一点的公司内部，团队之间也没有太多壁垒和界限，如果说你团队的输出能够替代另一个团队，那么让自己的团队拼一拼，把地盘占好，年底涨工资也是一个很美滋滋的事情。但是如果你这样做，别的团队也这样做，长此以往就没人不996了，最后你996也不够，只能007了。
3）我如何看待996
我今年工作刚好十年。我刚毕业第一年在阿里工作，团队的任务还是比较重，但是我一周也就两天会在公司吃晚饭。周末和晚上我也会花时间学习感兴趣的东西（当时是机器学习，还写了不少博客），真正晚上工作的时间不是很多。后来去了一个外企，基本上每天5点公司就没人了，我晚上就看看开源的项目，有时间贡献一下。过了两年我去了美国，第一年公司IPO前还比较忙，有时候晚上要在公司吃饭加个班啥的，后面IPO后公司也没人加班了，我周末和晚上不少时间都花在开源里面。最近这几年带团队，白天的会比较早，一周晚上也有那么几天有晚上的会，除了陪陪家人以外，有时间我还是会继续弄弄开源，看看论文和书。
我对于公司、团队级别的强制996是反对的，因为工程师做的事情应该是在更轻松的氛围里面创新，而不是被按在工位前出活。有些工作是需要很多的思考，特别是架构设计，还有职责划分之类的。996会让人缺少了思考的空间，对于那些资深的工程师或者架构师来讲，缺少思考的空间会导致最后出来的架构不是最优的，因为好的设计应该是想出来的而不是堆出来的，如果架构设计都出问题了，后面的工程部分会跟着错。对于管理方向的人也一样，如果缺少了思考的空间，管理者会更难为他人着想，更难思考团队到底需要和达到什么的目标，怎么做能够让公司受益等等。当你的时间都困在了工作中，长期来讲会产生工作的倦怠(burn out),对于身心、家庭、还有公司都不是什么好事。
但是另一方面我对于弹性的工作时间和短期的加班是可以接受的，比如说产品要发布了，或者客户有什么问题了，哪怕是周末或者晚上，我觉得也应该能够尽力帮忙，但是这样的加班节奏不应该是长期的、持续的、强制的。公司（或者管理者）不应该告诉员工这个时候加班，我的态度是，如果员工有一段时间特别忙，加班比较多，我会让他们去休个假，或者轻松一段时间。
我自己也一样，如果忙了一段时间，也需要从工作中脱离一下。因为忙碌的时间太久想要从中恢复很累，而且加班太多，导致心情不好的时候也会让家庭不开心，并且影响工作本身的效率。
4）工程师怎么避免内卷化
第一我觉得工程师要打好基础：不管是科班毕业还是转行。当你做上程序员的时候，就一定要打好自己的基础，基础包括：
– 编程本身的技能：一定要写一手好程序，有好的编程习惯。
– 写作、沟通的技能：能够写好的文档，做出清晰的沟通。
– 在工作的前几年，就要开始建立自己的社交圈，有一些值得信赖，互相学习、找工作可以互相内推的朋友，这样可以避免走很多的弯路。
– 在自己工作的范围内，看得比较深：因为你对于某一样东西有深入的理解后，学习浅一些的东西会很容易。比如说你做的是互联网的后台开发，那么深入理解一个或者几个分布式的系统很重要，如果做IOS app，那么对手机系统的内部工作应该是要很懂。
– 多阅读，多看看系统的知识，还有好的论文（比如说Google的论文）：这里我并不推荐付费的网课，相对网课，看看那些原创的书，比如说DAIA，算法导论之类的。会比只是教你刷刷LeetCode要好得多。当然LeetCode也是可以做做，不过不应该把它作为人生的追求。也建议看看管理、商业类的书，比如说硅谷之火，创新者的窘境之类的。
我建议这些能力在工作的3年内培养。
3年后，在有了这些基础后，对于业界和行业的发展应该会看得更清楚，而不至于走错大方向，比如说大家都在做SaaS的时候，你不应该花时间去学习太多windows 桌面的软件开发；选择一条发展更快的技术路线应该是避免内卷化的一个很重要的选择，如果方向都选错了那么避免内卷也很难。
另外跳槽的时候应该注意积累，每次跳槽应该是能够有更加深入的技能，而不是看跳槽（钱会自然来的）。如果每次跳槽都是换个方向平移重来，可能会导致工作十年跟工作3年的输出类似。
5）关于技术方向选型的一些建议：
– 我个人觉得未来的后端软件发展逃脱不了两样东西：第一是云，第二是开源。在大部分的时候是两者结合起来的，因为云本身也用了很多开源的软件。相比自己造轮子，使用开源，并且贡献开源（重点）应该是第一选择。把开源软件folk出来，自己搞一套我觉得并不是很可取。因为这样跟做闭源的区别也不是很大（当然你至少会对那个开源软件有深入的了解）。你的第一选择是，能否把一些贡献给反馈回开源的社区。
– 如果你选择贡献开源，最好选择贡献有社区的开源软件，其中以Apache或者CNCF为代表。因为有社区的开源软件会走得更长、也往往会更成功，作为一个这样（成功的）项目贡献者你的价值就会越大。
– 如果你刚毕业、或者工作时间还很短，建议选择更新一点的方向，比如说你现在想要做后端软件开发，Go/Rust会比Java更好，Java比C++也会更好。（我这里这样说不是为了搞语言之争，我也知道C++ ver.17 有很多新的特性，也本来就有很多市场）。
– 如果两个差不多的工作机会，做云上的软件开发（比如说一个给餐饮行业做管理的SaaS），会比做传统行业软件开发（比如给餐饮行业做桌面软件）要来得更好。因为一个发展更快，空间更大的行业的内卷化就会越少。
6）管理者：如何避免团队内卷化
作为管理者而言，在做好公司的任务之外，也需要尽力避免团队的内卷化。
首先说说加班，虽然说短时间的996会给团队带来（不少的）产出，不过从长时间来看，团队会因为倦怠和缺少进步而缺乏后劲。长时间的加班会让团队心情不好，钱给够是一个方面，但是钱很难买来长期的快乐（我的经验是涨工资的时候很开心，涨完了过段时间就平静了）。相对用钱去刺激加班（给1.5倍的工资，干两个人的活），我觉得更重要的是让团队成员真正能够得到发展，能够喜欢自己的工作，这样的效果很正向：公司能够得到工程师尽心尽力的产品，而工程师也能获得发展，并且过程很开心。作为管理者而言，你自己可以加班，但是不要要求团队总是和你一起加班，偶尔一次可以，总是这样的话，团队会变得低效和士气低落。
跟加班类似的，管理者也不应该认为员工的所有时间都属于公司的，应该尊重别人的休假、陪家人、生病等等的时间。
那么怎么能够让工程师更好的发展呢？管理者应该和工程师多沟通，多1-1，了解到别人的需求和想法，然后根据情况给出不同的机会（比如说承担某个重要的功能开发、在某个meetup上面讲一场技术专题、做一个更好的设计文档）。作为团队的管理者，不应该假设”给你做这个功能你就可以进步和开心了“。
其次，在面试的时候也不要有很多不恰当的要求，比如说觉得35岁以上、或者怀孕的人就不应该要之类的，在我看来35岁的程序员可以有非常厉害的输出，对这样的程序员的歧视首先是非常的没意义，其次也会加速内卷、社会更加不公平和完全不必要的焦虑（35岁焦虑）。对于公司而言应该是看大格局（怎么打造一个别人更喜欢的产品），而不是纠结于比较low的地方（如果招了一个刚结婚的人，未来一两年可能需要休几个月的产假；或者35岁的人有娃，需要花时间陪娃、接娃上下课）。
草草写一点想法抛转引玉一下。
