leaf

1.1 第一性原理思考工作 - 自洽的程序员關於程序員職場和生活的思考#

什麼是第一性原理思考#

第一性原理這個詞，最早是亞里士多德提出來的。不過要不是馬斯克天天掛在嘴邊，這詞可能現在還躺在哲學書的角落裡吃灰呢。

說白了，第一性原理就是：不人云亦云，不輕信二手結論，而是從最基本的事實出發，重新思考問題。

來個栗子🌰#

馬斯克想造火箭的故事可能你們都聽膩了，但這真的是個絕佳的例子：

當所有人都在說 "火箭太貴了，造不起" 的時候，馬斯克在想啥？ - "等等，火箭到底是啥玩意兒？" - "造個火箭要多少鋁合金、多少燃料？" - "這些原材料一共才多少錢？" - "為啥組裝起來就貴了這麼多？"

這就像我們寫代碼，與其複製 Stack Overflow 上的答案，不如想想這段代碼到底要解決什麼問題，從零開始寫會是什麼樣。

為什麼要用第一性原理思考工作#

在職場裡，我們經常被各種 "你應該..." 給包圍了：

• "你應該去大廠"（BAT 是程序員的終極夢想？）
• "你應該轉管理"（技術大牛就該帶團隊？）
• "你應該卷起來"（不卷就會被優化？）
• "你應該 35 歲前達到 P8"（為啥不是 38 歲？）
• "你應該像隔壁老王一樣努力"（老王也想像你一樣清閒...）

這些 "應該" 是從哪來的？

1. 社會壓力#

• 爸媽的期望："你看隔壁家小明..."
• 同學的壓力："他們都在大廠..."
• 社會輿論："35 歲危機..."

2. 行業慣性#

• "前端必須會 React"
• "後端必須會分佈式"
• "全棧工程師才有前途"

3. 個人認知局限#

• "大家都這麼做，我也這樣吧"
• "按老方法來準沒錯"
• "不確定的事情最可怕"

但是，用第一性原理思考的話，最基本的問題其實是： "我為什麼要上班，為什麼要寫代碼？"

工作認知的演進#

初入職場：簡單粗暴#

剛開始工作時，想法特別純粹：

• 賺錢，養活自己
• 學技術，長經驗
• 獨立，不啃老
• 證明自己，我行的！

真實案例#

小辣條（沒錯，就是我）剛畢業時：

• "月薪過萬就滿足了"
• "有免費零食的公司就是好公司"
• "能學到技術就行"
• "領導誇我代碼寫得好，開心！"

那會兒想法簡單，就想着能糊口就行，這沒啥不好，都是必經之路。

工作三五年後：開始懷疑人生#

工作幾年後，你可能會發現，代碼寫得越多，問題越多：

• "我到底喜歡寫代碼嗎？還是只是因為工資還不錯？"
• "為啥我天天加班改 Bug，隔壁老王天天摸魚還升職了？"
• "這工作到底是我想要的，還是別人眼中的 ' 好工作 '？"
• "35 歲危機是真的假的？要不要轉管理？"
• "要不要跳槽？要不要創業？要不要躺平？"

典型困惑#

• "工資是漲了，但感覺越來越菜了"
• "技術越學越深，但好像離產品越來越遠"
• "工作穩定，但無聊得想打瞌睡"
• "收入可觀，但頭髮越來越少"

這時候我們開始關注一些更深層次的問題：

• "我還能卷幾年？"
• "要不要轉行？"
• "要不要考個公務員？"
• "要不要回老家開個串串香？"

更成熟的階段：開始看透#

經過多年摸爬滾打，很多人會達到一個更通透的狀態：

• 不再焦慮要不要轉管理（反正都是坑）
• 不再糾結要不要進大廠（大廠也裁員）
• 找到了自己的節奏（摸魚和卷，都是人生的一部分）
• 建立了自己的判斷標準（老闆開心不是最重要的，自己開心才是）

真實案例#

辣條（還是我）十年工作感悟：

• 從 BAT 離職後選擇了小公司（錢少事少，生活質量高）
• 拒絕了幾個管理崗位（我還是喜歡寫代碼）
• 有時間陪家人了（再也不用和老婆解釋為什麼要加班）
• 開始做副業（加密貨幣搞起來）
• 心態更佛系了（項目延期？延就延吧，天還沒塌）

用第一性原理重新思考工作#

讓我們把所有的條條框框都扔掉，重新想想：工作到底是個啥玩意兒？

1. 工作是價值交換#

就像 API 調用：

• Request：

• 時間（每天 8 小時，加班另算）

• 技能（CRUD boy 的自我修養）

• 創意（產品經理的需求該怎麼實現）

• 體力（連續調試 8 小時的專注力）

• Response：

• 工資（房貸車貸的解藥）

• 經驗（從 Bug 中學習）

• 人脈（同事，未來的創業夥伴？）

• 成就感（這個 Bug 終於改完了！）

2. 工作是成長的遊戲#

• 技能樹不斷升級
• 認知水平不斷提升
• 思維方式不斷進化
• 社交能力不斷提高

就像玩 RPG 遊戲，工作就是主線任務，但別忘了還有支線任務（副業）和休閒任務（生活）。

3. 工作是人生的一部分#

• 不是全部（還有老婆孩子熱炕頭）
• 需要平衡（頭髮和工資不可兼得）
• 要有邊界（下班就是下班，工作群設置免打擾）

建立自己的工作觀#

1. 擺脫 "應該" 的束縛#

• 不是非要進大廠（小公司也能過得很滋潤）
• 不是非要當領導（技術專家也很香）
• 找到自己的節奏（有人喜歡衝刺，有人喜歡馬拉松）

2. 建立健康的工作邊界#

• 該摸魚時摸魚
• 該努力時努力
• 該休息時休息

3. 保持進化和迭代#

• 定期反思和總結（就像代碼要重構）
• 及時調整方向（需求變了就要改方案）
• 保持開放和學習（新框架要學，新語言要懂）

實踐建議#

1. 定期和自己對話

2. 每月反思：這個月摸魚摸得值得嗎？

3. 記錄心情，看見自己的情緒：今天改 Bug 改得想跳樓了嗎？

4. 复盘得失：這個項目坑在哪裡？

5. 建立評估框架

6. 工作是否開心？

7. 技術是否進步？

8. 錢是否夠花？

9. 及時做出調整

10. 不爽就換（總有更適合的坑）

11. 相信直覺（心累就該走了）

12. 大膽嘗試（最差也就是回去繼續寫 CRUD）

最後的幾句話#

用第一性原理思考工作，不是為了否定現有的一切，而是幫助我們：

• 看清本質（工作就是交換）
• 建立標準（開心最重要）
• 做出選擇（人生苦短，及時止損）

筆者還想強調的是，你對工作的認知，會隨著年齡和閱歷不斷變化，這很正常。關鍵是要經常問問自己："我為什麼要工作？" 只有時不時的思考下這個問題，才能在代碼的細節以及工作的繁瑣中偶爾抬起頭來，看清現階段的自己真正想要的是什麼。

畢竟，人生苦短，代碼要甜。🍬

1.2 工作掙扎是常態 - 自洽的程序員關於程序員職場和生活的思考

你今天掙扎了嗎？#

"今天的需求改了三遍..." "這個 bug 改了一周還沒解決..." "產品經理又改需求了..." "領導說要周末加班..."

如果你也經常發出這樣的感慨，別擔心，你不是一個人。每個程序員都在掙扎，只是有的人掙扎得比較優雅，有的人掙扎得比較狼狽而已。

程序員的日常掙扎#

技術掙扎#

• "這個框架文檔寫得跟天書一樣..."
• "這代碼是誰寫的？註釋呢？"
• "為啥我本地運行得好好的，一上線就炸了？"
• "這 bug 到底是從哪來的？"

業務掙扎#

• "產品經理，我們能好好說話嗎？"
• "這需求真的有人用嗎？"
• "又改需求？要不你來寫代碼？"
• "這個功能真的要這周上線？"

團隊掙扎#

• "代碼評審怎麼又被挑刺了？"
• "為啥我的代碼總是被說不規範？"
• "老王的代碼我看不懂啊..."
• "新來的同事水平有點差，帶起來好累..."

為什麼會掙扎？#

1. 技術發展太快#

• 昨天的最佳實踐，今天就成了反面教材
• 剛學會 Vue2，Vue3 就出來了
• 剛搞懂 Redux，Mobx 又火了
• 剛入門 Docker，k8s 又來了

就像你剛買的 iPhone 13，iPhone 14 就發布了，這種感覺，懂的都懂...

2. 業務需求太飄#

產品經理的日常語錄：

• "這個功能很簡單，下班前能改完吧？"
• "客戶說要改一下，就改個小需求"
• "這個需求很急，能不能今天就上線？"

每次聽到 "簡單" 這個詞，內心都會咯噔一下。因為經驗告訴我們，產品經理說的 "簡單"，往往意味著通宵。

3. 人際關係太複雜#

• 產品經理想要天馬行空
• 測試想要零缺陷
• 營運想要快速上線
• 老闆想要降本增效
• 我只想安靜地寫代碼

這就像在玩一個多人在線遊戲，每個人都想當 C 位，但最後背鍋的往往是程序員...

掙扎的本質是什麼？#

其實仔細想想，工作中的掙扎無非是這麼幾種情況：

1. 能力與要求不匹配#

• 項目要求：精通分佈式架構
• 現實情況：熟練 CRUD
• 最終結果：天天加班還寫不完

2. 期望與現實不匹配#

• 期望：心無旁騖寫優雅的代碼，改變世界
• 現實：天天改 bug，跟各個方向對需求
• 結果：每天懷疑人生

3. 付出與回報不匹配#

• 付出：每天工作 12 小時
• 回報：工資漲幅不及物價
• 收穫：頭髮越來越少

如何優雅地掙扎？#

1. 調整心態#

• 把 Bug 當成送分題
• 把加班當成充電
• 把改需求當成鍛煉
• 把背鍋當成歷練

（好吧，我知道這聽起來很像 "精神勝利法"，但是真的有用！）

2. 提升能力，掙扎的越厲害，成長越快#

• 每天學習一個新技能
• 遇到問題先自己解決
• 做好復盤和總結
• 建立知識體系

3. 建立護城河#

• 技術上：

• 至少一個領域要精通

• 至少一個方向要深入

• 至少一個特長要突出

• 軟實力上：

• 學會和產品經理談判

• 學會和測試講道理

• 學會和領導說不

• 學會和同事互幫互助

掙扎中的成長#

1. 技術成長#

• 從 "這 bug 怎麼改？" 到 "為什麼會有這個 bug？"
• 從 "這代碼怎麼寫？" 到 "這代碼該怎麼設計？"
• 從 "複製粘貼" 到 "看源碼找答案"

2. 思維成長#

• 從 "完成任務" 到 "解決問題"
• 從 "寫代碼" 到 "寫方案"
• 從 "改 bug" 到 "防 bug"

3. 職業成長#

• 從 "被動接需求" 到 "主動提方案"
• 從 "只管寫代碼" 到 "參與決策"
• 從 "單打獨鬥" 到 "團隊協作"

最後的幾句話#

工作中的掙扎就像人生的必修課：不是你的錯，但要你來解決。不是你能控制的，但要你來負責。不是你想要的，但要你來面對。

與其抱怨掙扎，不如把掙扎當成成長的機會。就像重構代碼一樣，掙扎的過程也是重構自己的過程。

最後的最後，掙扎是常態，但快樂也可以是！你無法控制工作的掙扎現實，但可以控制自己面對現實的心態。

2.3 尋求幫助是項高級技能 - 自洽的程序員關於程序員職場和生活的思考

從一個尷尬的故事說起#

"那個... 老王啊，這個報錯你知道怎麼解決嗎？" "你自己有谷歌過嗎？" "呃... 還沒..." "......"

相信每個程序員都經歷過這種尷尬：問題沒調研就去問同事，結果被嫌棄了。但反過來也有另一種情況：

"這 bug 我已經調了一周了，實在搞不定..." "你怎麼不早說啊？這個問題我上周剛處理過！"

是不是很眼熟？其實這兩種情況都說明了一個問題：我們不會尋求幫助，或者說，不會正確地尋求幫助。

為什麼我們不敢尋求幫助？#

1. 面子問題#

• "問這麼簡單的問題會不會顯得我很菜？"
• "都工作這麼久了，這都不會，多丟人啊..."
• "萬一被同事看不起怎麼辦..."
• "領導會不會覺得我能力不行..."

2. 錯誤認知#

• "自己的問題應該自己解決"
• "優秀的程序員應該什麼都有"
• "問別人就是無能的表現"
• "獨立解決問題才是真本事"

3. 性格因素#

• 內向不善於交流
• 不想麻煩別人
• 害怕被拒絕
• 社交恐懼症

不會尋求幫助的後果#

1. 時間成本#

• 一個有經驗的同事 5 分鐘能解決的問題
• 你可能要花一整天去摸索
• 項目進度被拖延
• 工作效率嚴重下降

2. 心理負擔#

• 越卡越焦慮
• 越焦慮越卡
• 自信心受挫
• 工作熱情下降

3. 團隊影響#

• 本可以共享的經驗沒有共享
• 本可以避免的坑沒有避免
• 團隊協作效率低下
• 重複踩同樣的坑

什麼時候該尋求幫助？#

1. 該自己解決的時候#

• 基礎語法問題
• 簡單的配置問題
• 常見的報錯信息
• 有明確錯誤提示的問題

2. 該求助的時候#

• 嘗試過多種方案都不行
• 搜索了很多資料沒頭緒
• 卡了較長時間沒進展
• 涉及到歷史遺留問題
• 需要業務相關的上下文

如何正確尋求幫助？#

1. 求助前的準備#

• 把問題描述清楚

• 什麼情況下出現的

• 已經試過哪些方案

• 當前卡在哪一步

• 準備相關信息

• 錯誤日誌

• 環境信息

• 復現步驟

• 相關代碼片段

2. 選擇合適的對象#

• 了解這個領域的同事
• 做過類似項目的前輩
• 有相關經驗的朋友
• 特定技術社區的專家

3. 選擇合適的時機#

• 不要在別人最忙的時候
• 不要在快下班的時候
• 不要在對方在開會時
• 最好提前預約時間

提問的藝術#

1. 好的提問方式#

• "我在實現 XX 功能時遇到了問題..."
• "我已經嘗試了 A、B、C 方案，但都不行..."
• "我覺得可能是 XX 原因，你覺得呢？"
• "能否幫我看看這個思路對不對？"

2. 糟糕的提問方式#

• "這個怎麼做啊？"
• "為什麼我的代碼不行？"
• "幫我看看哪錯了"
• "這個 bug 怎麼解決？"

3. 提問時的注意事項#

• 表達要清晰具體
• 態度要謙虛誠懇
• 要尊重對方時間
• 記得總結和感謝

建立良性循環#

1. 及時記錄和總結#

• 把解決方案記錄下來
• 總結問題的原因
• 整理相關的知識點
• 分享經驗給其他同事

2. 主動回饋他人#

• 幫助遇到類似問題的同事
• 分享自己的經驗教訓
• 參與技術討論和分享
• 貢獻團隊的知識庫

3. 建立學習體系#

• 收集常見問題
• 整理解決方案
• 建立知識體系
• 形成經驗沉澱

最後的話#

在程序員這個職業裡，尋求幫助不是能力不足的表現，更不是逃避責任的藉口，而是一種提高效率的方法，解決問題的手段。

就像代碼要講究復用一樣，經驗也是可以復用的，知識也是可以共享的，成長也是可以互助的。

會尋求幫助的程序員，才是真正的高手。 不是因為他什麼都有，而是因為他知道如何更快地解決問題。

2.4 害怕直面衝突，怎樣才能支棱起來 - 自洽的程序員關於程序員職場和生活的思考

"老王，你這代碼寫得也太爛了吧？" "啥？我這代碼怎麼了？" "你這變量命名，這代碼結構，這是人能看懂的嗎？" "我尋思挺好啊，能跑就行呗..." "能跑就行？！後面誰維護你知道嗎？"

場面一度很尷尬。

代碼評審現場翻車，相信不少同學都經歷過。但更多時候，我們的反應是：

• 默默點個 "收到"，然後繼續摸魚
• 心裡暗罵對方太較真，但嘴上說 "好的我改"
• 改完立馬找產品理論："這需求本來就不合理！"
• 在工作群怼不過，轉手就把對方拉黑

說實話，誰不是從怂包子開始的呢？我自己剛工作那會兒，那叫一個怂。產品經理改需求，默默接受；測試提 bug，默默修改；leader 說要加班，默默加班... 直到有一天，我實在忍不住了。

為啥我們這麼怂？#

傳統文化教我們做 "老好人"#

從小到大，我們都被教育要 "和為貴"。打小學起：

• "要和同學好好相處啊"
• "忍一忍就沒事了"
• "吃虧是福" 這些話聽得耳朵都起茧子了。

到了職場，這種思維更甚：

• "大家都是同事嘛"
• "和氣生財"
• "多一事不如少一事"

結果呢？憋出一堆職場 "老好人"。

害怕得罪人#

這個真不能怪我們怂，實在是：

• 得罪測試，你的 bug 就別想過了
• 得罪產品，下次需求改到你懷疑人生
• 得罪 leader，你的績效就懸了
• 得罪同事，代碼評審能挑毛病挑到天亮

更要命的是，現在都講究 "團隊協作"。得罪一個，可能得罪一群。誰還不想混口飯吃了？

技術底氣不足#

說實話，很多時候我們不敢怼，是因為：

• 代碼寫得確實不夠好
• 技術深度確實不夠
• 方案確實有漏洞
• 經驗確實不足

就很尷尬，明明知道對方說的不全對，但又說不出所以然來。

怂著怂著，就出事了#

技術債越堆越多#

• 今天妥協用了個爛方案
• 明天將就寫了個爛代碼
• 後天將就改了個爛需求 最後？整個項目爛得像坨漿糊。

我之前就遇到過，一個 "臨時方案" 用了兩年，最後重構的時候，連碰都不敢碰，生怕整個系統崩潰。

背鍋俠本俠#

• 測試說有 bug，默默改
• 產品說要改需求，默默改
• 營運說要加功能，默默改
• 領導說要優化，默默改

結果呢？但凡出點問題： "這塊代碼是誰改的？" "哦，是小王啊，每次都是他改的..."

職場混成透明人#

久而久之：

• 技術討論不敢發言
• 方案評審不敢反對
• 有想法也不敢說
• 有建議也憋著

最後在團隊裡混成了隱形人，存在感只剩下每天打卡。

衝突其實沒那麼可怕#

職場衝突很正常#

就像寫代碼一樣：

• 不同的人有不同的代碼風格
• 不同的團隊有不同的技術棧
• 不同的項目有不同的要求

有分歧很正常，沒分歧才不正常。

把衝突當成機會#

• 代碼評審被怼，是提高代碼質量的機會
• 方案被質疑，是完善設計的機會
• 觀點不一致，是思維碰撞的機會
• 需求有分歧，是深入理解業務的機會

如何硬氣起來？#

先把技術能力搞上去#

說白了，底氣不足就是因為實力不足。

要學會：

• 寫代碼先想想為什麼要這麼寫
• 接需求先想想有什麼坑
• 做方案先調研同行都怎麼做
• 有空多看看源碼，別光是 CRUD

學會正確表達#

以前我的表達方式： "這個... 可能... 會不會有問題..."

現在的表達方式： "這個方案我覺得有三個問題： 1. 性能可能會有瓶頸 2. 擴展性不太好 3. 維護成本會很高 我建議我們可以..."

把對抗變成合作#

與其對抗：

• "你這需求改得也太頻繁了！"
• "你這代碼寫得也太爛了！"
• "你這測試也太細了！"

不如：

• "要不我們先確定核心需求？"
• "我們一起看看代碼怎麼優化？"
• "測試案例是不是可以優先級排序？"

最後說兩句#

職場衝突就像代碼裡的 bug，遇到很正常，解決很重要，回避不可取，處理要及時。

重要的不是避免衝突，而是學會處理衝突。

記住：

• 把話說出來總比憋在心裡強
• 把問題擺在台面上總比暗地裡較勁強
• 把分歧當面討論總比背後吐槽強

最後，祝大家都能成為職場上的 "硬漢"，不再害怕衝突。

2.5 如何面對職場 PUA - 自洽的程序員關於程序員職場和生活的思考

"小王啊，你看看隔壁組的小張，人家周末都在加班呢..." "就這點代碼量，你要寫到什麼時候？" "你這個年紀的時候，我早就是高級工程師了..." "不加班？你是不是對公司沒有歸屬感啊？"

聽著耳熟嗎？這不是普通的說教，這是赤裸裸的職場 PUA。

什麼是職場 PUA？#

簡單說，就是用各種 "看似合理" 的方式，打擊你的自信，控制你的行為。

常見的 PUA 話術#

產品經理版：

• "其他開發都說這個需求很簡單啊"
• "就改個小需求，怎麼這麼久還沒好？"
• "你看某某某，人家從來不說做不到"

技術領導版：

• "這麼簡單的 bug，你怎麼會犯？"
• "代碼寫成這樣，你是怎麼通過面試的？"
• "你的代碼水平好像沒什麼進步啊"

HR 版：

• "你看看同期的小李，人家都升職了"
• "你覺得就你這表現，年終獎能拿多少？"
• "現在外面行情不好，你要好好珍惜這個機會"

為啥會被 PUA？#

1. 江湖地位太低#

• 剛畢業沒經驗
• 技術深度不夠
• 資歷尚淺
• 沒有話語權

就像我剛工作那會兒，改個代碼還要被噴十遍，寫個需求要改八百遍，天天被說 "這都不會？"。

2. 不懂套路#

• 以為多做就能出頭
• 以為忍讓就能平安
• 以為付出就有回報
• 以為老實就不會挨欺負

結果呢？越老實越被欺負，越忍讓越得寸進尺。

3. 不敢反抗#

• "萬一得罪領導怎麼辦？"
• "得罪 HR 會不會被穿小鞋？"
• "現在找工作不容易啊..."
• "忍忍就過去了吧..."

PUA 的後果有多嚴重？#

1. 身心俱疲#

• 工作沒激情
• 睡覺睡不好
• 上班心慌慌
• 看到某些人就胃疼

2. 職業發展受阻#

• 自信心被打擊
• 創造力被壓制
• 主動性被消磨
• 成長空間被限制

3. 越來越卷#

今天：

• "周末加個班吧" 明天：

• "這個月多做點吧" 後天：

• "你看看人家..."

如何應對職場 PUA？#

1. 擦亮眼睛，識別 PUA#

正常的批評：

• "這段代碼可以優化一下，我們一起看看"
• "這個 bug 下次注意下，我來教你排查思路"
• "最近進度有點慢，是不是遇到什麼困難？"

PUA 式批評：

• "就這麼簡單的代碼都寫不好？"
• "這種低級 bug 都會犯，你是怎麼想的？"
• "你這個效率，怎麼做程序員的？"

2. 建立自我防護#

• 記錄工作內容

• 每天做了什麼

• 解決了什麼問題

• 貢獻了什麼價值

• 留存證據

• 保存聊天記錄

• 保存郵件往來

• 記錄關鍵會議內容

• 設立邊界

• 工作時間要有度

• 加班要有補償

• 職責要有邊界

3. 學會正面回應#

PUA：這麼簡單的需求，你怎麼做這麼久？ 回應：

• "這個需求涉及到 A、B、C 三個模塊的改動，我評估需要 3 天時間"
• "我這邊已經完成了 70%，還有哪些地方你覺得可以加快？"
• "如果你覺得時間太長，我們可以一起看看有什麼可以優化的地方"

PUA：你看看人家小張，周末都在加班... 回應：

• "我更注重效率，周內我都會提前規劃好工作"
• "我的工作量和產出都達到了要求，有問題嗎？"
• "我們是按產出評估，還是按加班時間評估？"

4. 準備後路#

• 保持技術更新
• 擴展人脈網絡
• 關注市場機會

一些特別提醒#

1. 不要期待 PUA 者改變#

他們不會改變，因為 PUA 對他們來說是有效的管理工具，他們可能也是被 PUA 出來的，他們覺得這樣做沒問題。

2. 保護好自己#

自己的身體健康最重要，重視自己的心理健康，規劃自己的職業發展，該走的時候要走。

3. 警惕自己變成 PUA 者#

• 當了領導不要學這套
• 帶新人要以理服人
• 評審代碼要就事論事
• 工作溝通要講道理

最後的叮囑：

• 工作只是一份工作
• 公司只是一家公司
• 領導只是一個領導
• 你的人生不該被 PUA 毀掉

職場 PUA 就像代碼裡的死循環：發現得早跳出來還來得及，發現得晚可能整個系統都崩潰。

2.8 工作倦怠了嗎，試試三葉草模型 - 自洽的程序員關於程序員職場和生活的思考

"最近上班好累，上班如上墳.." "不是身體累，就是... 提不起勁" "天天就想摸魚，對工作提不起一點興趣"

如果你也有這種感覺，不妨用三葉草模型來給自己做個診斷。

什麼是三葉草模型？#

三葉草模型是一個職業生涯規劃模型，它把工作動力分成三片葉子：

• 興趣葉：對工作的熱情和喜愛程度
• 能力葉：解決問題的技術和才幹
• 價值葉：工作帶來的回報和意義

這三片葉子相互影響，缺一不可：

• 有興趣，學習能力才會提升
• 有能力，才能創造更多價值
• 有價值，才能持續保持興趣

三種倦怠類型#

1. 厭倦型（興趣葉枯萎）#

表現：

• 天天盼著下班
• 看到代碼就煩
• 對什麼都提不起勁
• 工作完全是為了完成任務

就像我一個同事說的： "以前看到新技術就興奮，現在看到新框架就頭大" "記得剛工作那會兒，周末還會自己寫代碼，現在連 IDE 都不想打開"

2. 焦慮型（能力葉不足）#

表現：

• 總覺得跟不上節奏
• 害怕接到新需求
• 看不懂同事的代碼
• 技術分享時坐立難安

一個典型場景： "產品經理說這個很簡單，可我看了半天也沒頭緒..." "同事兩天就能寫完的功能，我要寫一周..."

3. 失落型（價值葉缺失）#

表現：

• 付出沒有回報
• 努力得不到認可
• 看不到職業發展
• 覺得自己是工具人

常見的抱怨： "我優化了整個系統性能，領導說 ' 這不是應該的嗎？'"" 加班做完的方案，第二天被一句 ' 需求變了 ' 否定 "

如何治癒倦怠？#

1. 厭倦型的治療方案#

第一步：找回興趣的源頭 - 回憶當初為什麼選擇編程 - 列出曾經讓你興奮的技術點 - 想想最有成就感的項目

第二步：重新培養興趣 - 嘗試一個自己感興趣的 side project - 研究一下新技術或者開源項目 - 和志同道合的同事一起做點東西

第三步：轉化興趣 - 把枯燥的工作遊戲化 - 在日常工作中設立小目標 - 給自己設定技術挑戰

2. 焦慮型的治療方案#

第一步：正視能力差距 - 列出具體的技能短板 - 設定合理的學習目標 - 制定可執行的計劃

第二步：系統提升 - 每天抽固定時間學習 - 參與有挑戰性的項目 - 向高手請教和學習

第三步：發揮優勢 - 專注於自己擅長的領域 - 把已有技能做到極致 - 找到適合自己的位置

3. 失落型的治療方案#

第一步：重新定義價值 - 不只看外在回報 - 關注個人成長 - 尋找工作的其他意義

第二步：創造價值 - 主動承擔重要任務 - 解決團隊痛點問題 - 提升工作的可見度

第三步：尋找平台 - 選擇更適合的團隊 - 找到欣賞自己的領導 - 尋找價值觀一致的環境

一些特別提醒#

1. 三片葉子是相互影響的，找回興趣，能力自然會提升，提升能力，價值自然顯現，獲得價值，興趣會更濃

2. 治癒倦怠需要時間，不要期待立竿見影，給自己一個緩衝期，保持耐心和信心。

3. 記住選擇權在你，可以換個團隊，可以轉換方向，可以尋找新機會。

就像調試代碼一樣：先定位問題（哪片葉子出問題了），再分析原因（為什麼會這樣），最後解決問題（對症下藥）。

程序員嘛，修 bug 的時候都那麼執著， 修復自己的倦怠，也要這麼認真才行。

2.10 職場中如何做選擇 - 自洽的程序員關於程序員職場和生活的思考

"要不要跳槽？" "要不要轉管理？" "要不要接這個項目？" "要不要去創業公司？"

職場就是一個不斷做選擇的過程。 但很多時候，我們糾結得像在 debug 一個隨機 bug。

選擇困難症患者日常#

1. 跳槽選擇困難#

• 現在公司雖然不完美，但是很穩定
• 新公司給的多，但是不知道坑多不多
• 現在同事關係不錯，換了環境要重新適應
• 要不... 再等等？

2. 方向選擇困難#

• 繼續做技術還是轉管理？
• 專精一個方向還是廣泛發展？
• Java 轉 Go 好還是轉 Python 好？
• 要不... 都學學？

3. 項目選擇困難#

• 老項目雖然爛，但是熟悉
• 新項目雖然好，但是風險大
• 這個有挑戰，但是可能會很累
• 要不... 隨便吧？

為什麼選擇這麼難？#

1. 信息不對稱#

• 新公司看起來很好，但實際呢？
• 新技術很火，但會不會昙花一現？
• 新項目很酷，但坑有多深？

就像買房： 看起來裝修不錯， 但你永遠不知道鄰居半夜會不會放音樂。

2. 結果不確定#

• 跳槽可能升職加薪，也可能處處碰壁
• 轉管理可能平步青雲，也可能兩頭不討好
• 接新項目可能大放異彩，也可能翻車現場

3. 機會成本#

• 選 A 就意味著放棄 B
• 選這個就要錯過那個
• 現在不選以後可能沒機會了

兩個實用的決策思路#

1. "Hell Yeah" or "No"#

遇到選擇時，問問自己： "這個機會讓我興奮到想大喊 'Hell Yeah!' 嗎？"

如果你的回答是："還可以吧"，"還不錯欸"，"蠻好的"，"值得考慮"，

對不起，這些都不是 "Hell Yeah!" 那就應該是 "No"。

2. 未來的故事法則#

再問問自己： "這會是一個值得在飯局上開心分享的故事嗎？"

好故事的樣子：

• "我帶領團隊重構了整個系統架構..."
• "我們在一個月內把性能提升了 10 倍..."
• "我從零開始組建了公司的 AI 團隊..."

無聊故事的樣子：

• "我在那混了三年，每天按時下班..."
• "工作還行，工資還可以..."
• "就那樣呗，還能咋樣..."

如何利用這兩個思路做選擇？#

1. 跳槽決策#

不要問：

• 新公司工資高多少？
• 新公司福利好不好？
• 新公司名氣大不大？

要問：

• 想到去這家公司，我興奮嗎？
• 這份工作會讓我有好故事講嗎？
• 三年後，我會為這個選擇自豪嗎？

2. 技術方向#

不要問：

• 這個技術火不火？
• 這個方向賺不賺錢？
• 學習曲線陡不陡？

要問：

• 這個技術讓我熱血沸騰嗎？
• 這個方向能讓我有成就感嗎？
• 這會是我職業生涯的精彩一筆嗎？

3. 項目選擇#

不要問：

• 這個項目簡單不簡單？
• 這個項目有沒有風險？
• 這個項目能不能按時完成？

要問：

• 這個項目夠挑戰嗎？
• 這個項目能讓我成長嗎？
• 這個項目值得我投入嗎？

一些特別提醒#

1. "Hell Yeah" 不是盲目樂觀#

不是不考慮風險，不是不考慮現實，而是在充分評估後的由衷興奮。

2. "好故事" 不是吹牛#

不是追求表面光鮮，不是為了炫耀，而是真實的成長和收穫。

3. 找不到 "Hell Yeah" 的選擇？#

可能是視野要再開闊些，可能是能力要再提升些，可能是方向要再調整些。

最後的碎碎念#

職場選擇就像寫代碼：不要只看表面的需求，不要只顧眼前的實現，要考慮長期的可維護性，要思考未來的擴展性。

最後的最後： 你的職業生涯是一個個選擇堆積而成的故事， 要麼激動人心到值得說 "Hell Yeah!" 要麼乾脆就不要寫進去。

3.1 領導一對一（1on1）聊什麼 - 自洽的程序員關於程序員職場和生活的思考

"下周一對一，又不知道聊什麼..." "每次都是領導問，我就答，感覺好被動" "一對一好尷尬，就像相親..."

很多人都有這種困擾。 其實 1on1 是個難得的機會， 就看你會不會用。

為什麼要重視 1on1？#

1. 這是你的專屬時間#

• 不是日常晨會
• 不是項目周會
• 不是績效面談
• 而是屬於你的 30 分鐘

2. 這是雙向溝通的機會#

• 不是領導訓話
• 不是工作匯報
• 不是被動答問
• 而是平等的對話

3. 這是建立信任的時刻#

• 不是表面客套
• 不是應付了事
• 不是互相防備
• 而是真誠交流

聊什麼？#

1. 工作進展#

不要只說： "項目都按計劃進行..." "沒什麼特別的問題..."

要說：

• 遇到了什麼挑戰
• 如何解決的
• 學到了什麼
• 還需要什麼支持

2. 個人成長#

主動分享：

• 最近在學什麼
• 遇到什麼瓶頸
• 有什麼困惑
• 未來想往哪個方向發展

3. 團隊建設#

可以聊：

• 團隊氛圍如何
• 和同事協作情況
• 流程上有什麼建議
• 團隊還缺什麼

4. 對公司的想法#

可以談：

• 對公司戰略的理解
• 對產品的建議
• 對流程的改進想法
• 對團隊發展的建議

怎麼聊？#

1. 會前準備#

• 列個提綱
• 記錄關鍵點
• 準備具體例子
• 想好你的訴求

比如： "最近在做性能優化，遇到幾個難點，想和您討論下..." "對未來的職業發展有些困惑，想聽聽您的建議..."

2. 會中技巧#

• 先說重要的
• 用數據說話
• 多提建設性意見
• 注意傾聽反饋

3. 會後跟進#

• 記錄關鍵點
• 落實行動項
• 跟進解決方案
• 下次匯報進展

幾個常見場景#

1. 遇到困難時#

不要說： "這個問題好難，搞不定..."

要說： "我遇到這個問題， 已經嘗試了這些方案， 但效果不理想， 想聽聽您的建議..."

2. 有想法建議時#

不要說： "我覺得我們團隊應該怎樣怎樣..."

要說： "我觀察到這個問題， 分析原因可能是... 建議我們可以... 您覺得這個思路如何？"

3. 談成長規劃時#

不要說： "我想往高級工程師發展..."

要說： "根據團隊需要和個人興趣， 我想在系統架構方面深入， 已經在學習相關知識， 希望能得到一些實踐機會..."

注意事項#

1. 要誠懇不要抱怨#

• 多談解決方案
• 少說牢騷
• 保持建設性
• 態度要積極

2. 要具體不要空泛#

• 多舉實例
• 少說空話
• 有數據支撐
• 重結果導向

3. 要主動不要被動#

• 提前準備話題
• 主動分享想法
• 爭取有效反饋
• 及時跟進行動

關於 1on1 的一些特別提醒#

1. 不是吐槽大會#

不要一味抱怨，不要傳播負能量，不要說同事壞話，要保持專業性。

2. 不是表演時間#

不要過分包裝，不要避重就輕，不要誇大成績，要保持真誠。

3. 不是單向匯報#

不要只說成績，不要只報進度，不要只答不問，要互動交流。

最後的建議#

把 1on1 當作：自我提升的機會，建立信任的渠道，解決問題的平台，職業發展的助推器。

好的 1on1 不在於時間長短，而在於溝通的質量；不在於說了多少，而在於解決了什麼。

3.4 同事是傻逼，我有厭蠢症，實在受不了了 - 自洽的程序員關於程序員職場和生活的思考

"這麼簡單的 bug，他怎麼改了三天還沒改好？" "這個需求都講了八百遍了，他怎麼還不懂？" "我的天啊，這代碼是人寫的嗎？"

如果你經常這樣吐槽，那麼恭喜你，你可能也是個 "厭蠢症" 患者，這個時候，就是考驗你 “向下兼容” 的能力了。

先冷靜一下#

1. 每個人都是別人眼中的 "傻子"#

• 產品經理覺得程序員不懂需求
• 程序員覺得測試不懂開發
• 測試覺得運維不懂測試
• 運維覺得所有人都不懂運維 （好像哪裡不對...）

2. "聰明" 是個相對概念#

• 你覺得他笨，
• 可能別人覺得你更笨
• 就像你寫的代碼，
• 說不定被別人在群裡吐槽呢 （想想還有點小緊張）

3. 每個人都有自己的長處#

• 他雖然代碼寫得慢，但 bug 少
• 他雖然理解需求慢，但做得穩
• 他雖然技術一般，但人緣好
• 他雖然不太聰明，但很努力 （好像也沒那麼糟？）

如何應對？#

1. 換個角度想#

• 也許他是新手
• 也許他是轉行的
• 也許他正在學習
• 也許他有特殊困難 （誰還沒個新手的時候？）

2. 調整心態#

• 與其生氣，不如幫助
• 與其抱怨，不如指導
• 與其嫌棄，不如包容
• 與其逃避，不如溝通 （好像有點道理）

3. 具體行動#

• 寫詳細的文檔
• 畫清晰的流程圖
• 做耐心的解釋
• 給出具體的例子 （感覺自己變得更專業了）

特別提醒#

1. 不要人身攻擊#

• 不要說 "你怎麼這麼笨"
• 不要說 "這都不懂"
• 不要說 "誰招的你"
• 不要說 "你是不是腦子有問題" （說出來顯得自己更 low）

2. 不要過度包攬#

• 不是所有人都需要你救
• 不是所有事都要你管
• 給他成長的空間
• 給自己喘息的機會 （累死自己可不值得）

3. 該放手時放手#

如果真的無法溝通：

• 和領導反饋
• 調整分工方式
• 換個協作方式
• 實在不行就換組 （及時止損很重要）

最後的話#

其實，所謂的 "厭蠢症"，往往是我們對他人的不理解，和對自己的過度自信。

記住：每個人都在自己的節奏裡成長，你對別人的包容，也是對自己的善待。

（誒，好像最近那個 "笨蛋" 同事進步不少...）

PS: 如果你真的想 "殺" 了他，建議： 1. 用耐心 "殺" 死他的無知 2. 用幫助 "殺" 死他的迷茫 3. 用專業 "殺" 死他的混亂 4. 實在不行，"殺" 死自己的偏見

4.1 好的伴侶可以幫你消化工作上的負面情緒 - 自洽的程序員關於程序員職場和生活的思考

"今天不談工作！" "回家就忘記公司的事！" "工作的事不要帶回家！"

這些話聽起來很有道理，但真的合適嗎？

🤔 為什麼要和伴侶分享工作情緒？#

1. 壓抑不等於解決#

情緒就像氣球，憋得太久總會爆炸

• 刻意回避反而加重壓力

• 負面情緒會在潛意識中積累

• 可能導致更嚴重的心理問題

• 影響工作和生活的質量

• 負面情緒需要適當宣洩

• 找到合適的傾訴對象

• 選擇恰當的表達方式

• 保持情緒的健康流動

• 伴侶是最好的傾訴對象

• 最了解你的生活狀態

• 最容易產生情感共鳴

• 最願意傾聽你的心聲

2. 伴侶的獨特價值#

為什麼伴侶比閨蜜 / 基友更適合傾訴？

• 更了解你的性格特點

• 知道你的處事方式

• 理解你的情緒變化

• 懂得如何安慰你

• 更深度的情感聯結

• 共同的生活目標

• 相互的責任擔當

• 長期的情感投入

• 更安全的傾訴環境

• 不用擔心信息泄露

• 不用顧慮面子問題

• 可以完全地展示脆弱

💡 怎樣和伴侶分享工作情緒？#

1. 選擇合適的時機#

時機比內容更重要

• 不要在這些時候分享：

• 剛到家的疲憊時刻

• 對方工作壓力大時

• 正在享受美食時

• 準備休息入睡時

• 推薦的分享時機：

• 晚飯後的散步時光

• 周末早晨的咖啡時間

• 假期出遊的輕鬆時刻

• 雙方都有精力傾聽的場合

2. 注意分享的方式#

態度決定效果

• 語氣的選擇

• 平和而不激動

• 理性而不情緒化

• 討論而不是抱怨

• 分享而不是發洩

• 內容的把控

• 重點突出

• 條理清晰

• 適可而止

• 互動的技巧

• 注意對方的反應

• 給對方表達的機會

• 接納不同的觀點

• 感謝對方的傾聽

📝 如何開啟工作話題？#

1. 選擇合適的開場白#

🔴 不恰當的方式：

• "今天那個產品經理又犯傻了！"
• "我們老闆真是太過分了！"
• "我受夠這個工作了！"
• "你知道今天發生了什麼嗎？氣死我了！"

✅ 推薦的方式：

• "親愛的，能聽我說說今天遇到的事嗎？"
• "最近工作上有點困惑，想聽聽你的想法。"
• "你在工作中遇到過類似的情況嗎？"
• "能和你分享個工作中的小故事嗎？"

2. 不同場景的溝通話術#

遇到工作挫折時： "今天項目上遇到點困難，能聽我說說嗎？我想理清楚自己的思路。"

面對職場壓力時： "最近工作壓力有點大，能陪我散散步聊聊天嗎？感覺和你說說話會好很多。"

經歷職場衝突時： "遇到個讓我很困擾的情況，想聽聽你的看法，你在工作中遇到過類似的事嗎？"

3. 營造輕鬆的分享氛圍#

• 晚飯後："今天遇到個有意思的事，我們邊走邊聊？"
• 周末早晨："一起喝杯咖啡，聽我說個小故事？"
• 休息時光："能借用你幾分鐘，幫我參考個問題嗎？"

⭐️ 如何建立長期的分享機制？#

1. 固定的分享時刻#

• 建立例行的交流習慣
• 創造專屬的分享場景
• 保持適度的分享頻率
• 注意互動的質量

2. 健康的互動模式#

• 雙向的信息流動
• 平等的對話關係
• 積極的反饋機制
• 持續的情感投入

3. 良性的成長循環#

• 共同進步
• 互相支持
• 價值認同
• 感情升溫

❗️ 特別提醒#

1. 保持邊界感#

分享不等於全盤托出

• 注意保護公司機密

• 不涉及具體業務數據

• 不透露商業機密

• 不談論具體人名

• 重點是情緒而不是細節

• 把握分享的度

• 不要變成抱怨大會

• 不要沉浸在負能量中

• 不要期待對方解決所有問題

• 保持適度的分享量

2. 關注正向反饋#

不只分享困難，也要分享快樂

• 分享工作中的成就

• 項目完成的喜悅

• 能力提升的欣慰

• 同事認可的自豪

• 工作進展的滿意

• 討論職業發展

• 分享職業規劃

• 探討發展方向

• 憧憬美好未來

• 共同規劃人生

🎯 最後的話#

記住：

好的伴侶關係，不是形式上的兩個人住在一起，而是靈魂上的相互理解和支持。

工作是生活的重要部分，而不是需要隱藏的秘密。適度分享不僅能幫助消化負面情緒，更能增進彼此的理解和信任。

分享工作中的酸甜苦辣，也是讓感情升溫的催化劑。在互相理解和支持中，兩個人都能獲得成長。

（今天又被產品經理改需求了，回家得跟對象好好吐槽... 啊不是，是 "理性探討" 一下～）

PS：給還沒有伴侶的打工人： - 找個好伴侶真的很重要 - 不是因為需要人分擔房貸 - 而是需要一個懂你的人 - 在你累的時候遞上一杯溫水 - 說一句："來，給我講講。"

4.2 維系親密關係最重要的一點 - 自洽的程序員關於程序員職場和生活的思考

"你為什麼不能像他 / 她一樣..." "你要是能改改這個習慣就好了..." "你什麼時候才能懂我的心意..."

等一等，維系一段親密關係最重要的，不是轟轟烈烈的愛，不是無限量的付出，而是 ——接納對方本來的樣子。

🤔 為什麼是接納？#

1. 愛是如你所是，而非如我所願#

真正的愛不是把對方變成自己想要的樣子

• 接納意味著：

• 允許對方保持本真

• 尊重個體的差異

• 給予成長的空間

• 包容不完美

• 強求改變往往導致：

• 壓抑真實的自我

• 產生抵觸情緒

• 累積負面感受

• 關係漸行漸遠

2. 穩定關係的密碼#

長久的感情建立在相互理解和包容之上

✅ 健康關係的特徵：

• 很少的攻擊
• 很少的對抗
• 很少的強人所難
• 很多的理解和接納

🔴 不健康關係的特徵：

• 頻繁的批評指責
• 持續的爭吵對抗
• 試圖改變對方
• 過度的期待要求

💡 如何做到真正的接納？#

1. 允許不完美#

完美的關係不存在，但快樂的關係存在

• 接受對方的小缺點：

• 偶爾的健忘

• 某些小習慣

• 性格的特點

• 處事的方式

• 明白一個道理：

• 沒有十全十美的人

• 差異造就獨特

• 不完美才真實

• 包容創造和諧

2. 給予成長的空間#

愛是成全，而不是束縛

✅ 應該這樣：

• 支持對方的興趣愛好
• 理解對方的職業選擇
• 尊重對方的社交圈
• 給予獨立思考的空間

🔴 避免這樣：

• 過度干預對方生活
• 強制改變對方習慣
• 限制對方的社交
• 要求對方事事順從

⭐️ 具體的行動指南#

1. 日常相處中的接納#

從小事做起，在細節中體現

✅ 這樣做：

• "你喜歡就好，我支持你"
• "這是你的選擇，我理解"
• "需要幫忙隨時說"
• "你有自己的想法很好"

🔴 避免說：

• "你怎麼總是這樣..."
• "你什麼時候才能改改..."
• "你必須要聽我的..."
• "要是你能像誰誰誰..."

2. 面對分歧時的態度#

不同不代表錯誤，理解勝過改變

✅ 建設性的回應：

• "我們想法不同，這很正常"
• "讓我試著理解你的觀點"
• "也許我們可以各自保留意見"
• "重要的是互相尊重"

❗️ 特別提醒#

1. 接納的邊界#

• 不是放縱傷害行為
• 不是默許原則問題
• 不是忽視重要分歧
• 不是犧牲自我價值

2. 需要警惕的情況#

• 單方面的付出
• 過度的忍讓
• 原則性的讓步
• 價值觀的衝突

🎯 最後的話#

穩定的關係，不在於愛得多熱烈，而在於傷得多少。

真正的愛，是讓對方做自己，而不是變成你想要的樣子。

每一次的包容，都是給感情加分。每一次的接納，都是給關係加溫。

（誒，好像該去陪對象打遊戲了... 雖然我不太懂，但看著也挺開心的～）

PS：給正在相處的你： - 愛不是改變對方 - 而是欣賞差異 - 包容不完美 - 給予自由 - 相信時

4.4 伴侶老是抱怨，我該怎麼辦 - 自洽的程序員關於程序員職場和生活的思考

每個人都希望下班回到家能得到溫暖和理解，但現實往往是：剛進門就聽到一連串的抱怨。工作已經夠累了，回家還要面對這些，該怎麼辦？

🤔 為什麼會有這麼多抱怨？#

在談如何應對之前，我們先要理解：為什麼會有這麼多抱怨？

1. 抱怨的本質#

抱怨背後往往隱藏著更深層的訴求： - "今天又加班" = 我很想你 / 我覺得被忽視了 - "工資太低" = 我擔心我們的未來 - "你都不陪我" = 我需要更多的關注和陪伴 - "你總是玩手機" = 我想要更多的互動

2. 抱怨的積累#

很多抱怨不是突然產生的，而是長期積累的結果： - 小事情沒有及時溝通 - 情緒沒有得到及時疏導 - 期望沒有被及時調整 - 問題沒有被真正解決

💡 換個角度看抱怨#

其實，抱怨也不全是壞事：

1. 抱怨是一種信任

2. 敢對你抱怨，說明還在乎這段關係

3. 願意表達不滿，總比憋在心裡強

4. 抱怨是在尋求改變，而不是放棄

5. ** 抱怨是溝通的開始