最近看到這個問題被談得很多。鋪天蓋地的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歲的人有娃，需要花時間陪娃、接娃上下課）。
草草寫一點想法拋轉引玉一下。