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. 職業成長#

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

最後的幾句話#

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

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

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

1.3 工作承載不了太多意義，但也不要陷入工作虛無主義 - 自洽的程序員關於程序員職場和生活的思考

關於工作的兩個極端#

最近在程序員群裡，經常看到兩種極端的聲音：

極端 1：工作就是生活的全部#

• "不加班怎麼能進步？"
• "不卷怎麼能成功？"
• "工作就是生活的意義啊！"
• "多幹活才能有未來！"

這幫人把工作當成了人生的全部，仿佛不工作就活不下去了。每天加班到深夜，周末也在想工作，朋友圈全是技術文章...

極端 2：工作就是浪費生命#

• "工作不就是為了賺錢嗎？"
• "反正都是給老闆打工"
• "上班就是浪費生命"
• "能摸魚就摸魚"

這些人覺得工作毫無意義，上班就是在消耗生命，除了賺錢沒有任何其他意義，恨不得立馬辭職去流浪。

為什麼會有這兩種極端？#

1. 社會壓力#

• 房貸車貸的壓力
• 35 歲危機的焦慮
• 同齡人的對比
• 父母的期望

2. 互聯網的放大效應#

• 成功學的洗腦
• 躺平學的誘惑
• 各種極端觀點的傳播
• 戾氣的積累

3. 個人認知的局限，當然也是當下主流的工作倫理#

• 把工作等同於生活
• 把工作努力等同於最高道德
• 把收入等同於價值
• 把職位等同於能力
• 把忙碌等同於進步

工作到底承載了什麼？#

1. 最基本的：生存需求#

• 溫飽（這是最基本的）
• 房子（安身之所）
• 車子（代步工具）
• 醫療保險（以防萬一）

2. 進階的：成長需求#

• 技能提升
• 視野拓展
• 人脈積累
• 經驗沉澱

3. 更高層的：自我實現#

• 成就感
• 價值認同
• 社會貢獻
• 個人影響力

工作的真相是什麼？#

1. 工作既不是全部，也不是虛無#

• 它是生活的一部分，但不是全部
• 它有它的價值，但不是唯一的價值
• 它值得認真對待，但不要太較真
• 它需要投入，但不是無限投入

2. 工作是一種平衡#

• 在理想和現實之間
• 在付出和收穫之間
• 在個人和團隊之間
• 在工作和生活之間

3. 工作是一個過程#

• 不是終點，而是旅程
• 不是結果，而是經歷
• 不是負擔，而是選擇
• 不是束縛，而是機會

如何找到平衡？#

1. 給工作一個合適的位置#

• 不要把它看得太重
• 也不要把它看得太輕
• 找到自己舒服的節奏
• 保持健康的距離

2. 建立多元的生活#

• 工作之外要有愛好
• 職場之外要有朋友
• 技術之外要有興趣
• 收入之外要有追求

3. 保持清醒的認知#

• 知道自己要什麼
• 明白自己在做什麼
• 清楚自己能做什麼
• 了解自己該做什麼

一些具體建議#

1. 工作時間#

• 正常下班就走
• 周末儘量不加班
• 休假要好好休
• 摸魚要有度

2. 工作態度#

• 該認真時認真
• 該放鬆時放鬆
• 該拒絕時拒絕
• 該妥協時妥協

3. 工作方法#

• 提高效率，而不是延長時間
• 追求質量，而不是堆砌數量
• 注重成長，而不是純粹付出
• 講求方法，而不是蠻幹

最後的幾句話#

工作就像人生的一個維度：它很重要，但不是唯一。它需要投入，但要有度。它值得認真，但別太執著。

工作是為了更好的生活，而不是讓生活成為工作的附屬品。

我們的目標是：認真工作，快樂生活。既不做工作的奴隸，也不做生活的逃兵。

最後，送大家一句話： 工作和生活就像代碼和註釋，缺一不可，但要比例適當。

2.1 心態開放，你的職場第一課 - 自洽的程序員關於程序員職場和生活的思考

為什麼心態開放這麼重要？#

還記得第一次接觸新框架時的感覺嗎？面對滿屏的新概念，你可能像我一樣，恨不得立刻關掉編輯器，躲回自己熟悉的 "舒適窩"。這就像一隻從來沒見過大海的青蛙，突然被扔進了太平洋 —— 慌得不行。

但你知道嗎？正是這種 "慌得不行" 的感覺，往往預示著我們遇到了成長的機會。

固定型思維 vs 成長型思維#

說到思維模式，不得不提心理學家德韋克提出的這兩種類型：

固定型思維的小夥伴們是這樣的： - "這個新框架太難了，我學不會的" - "我就是個後端程序員，前端的事情碰都不想碰" - "我寫了十年 Java，改不了這個習慣了" - "新技術？等別人踩完坑再說吧"

聽起來是不是特別耳熟？這就像一隻固執的鴕鳥，遇到挑戰就把頭埋在沙子裡，心想："看不見就不存在"。

而成長型思維的小夥伴則是這樣的： - "雖然看不懂，但是好像挺有意思的" - "多學一樣技能，多一條路" - "試試看呗，大不了就是報錯" - "踩坑也是一種經驗啊"

這就像一隻好奇的貓咪，看到什麼新東西都想去撥弄兩下，說不定就發現了新大陸。

為什麼說心態開放是第一課？#

想象一下，如果你是一個杯子：

• 固定型思維就像一個已經裝滿水的杯子，新的東西都裝不進去
• 成長型思維則像一個空杯子，隨時準備接納新的知識

在職場中，技術更新得比你手機系統還快。今天你精通的技術，明天可能就變成 "傳統藝能" 了。如果不保持開放的心態：

• 新技術學不進
• 新方法用不上
• 新機會抓不住
• 新發展看不到

就像那句老話："SELECT * FROM world WHERE 心態 = '開放'"—— 好吧，這是我編的，但你懂我意思。

如何培養開放的心態？#

1. 擁抱 "不懂"#

記得我剛轉行做程序員時，遇到不懂的東西特別害怕被人發現，問問題之前要先憋上半天，搜索一堆資料，生怕被人說 "連這都不知道"。

現在想想，這就像公共場合突然想放屁一樣，憋得自己難受，還要裝作若無其事一樣不讓人看出來。其實，承認 "不懂" 一點都不丟人，丟人的是：不懂裝懂（這是最容易被戳穿的），不懂不學（這是最快掉隊的），不懂不問（這是最耽誤事的）。

2. 學會 "歸零"#

每隔一段時間，我們都需要給自己 "格式化" 一下：

• 清空已有的經驗偏見
• 重新審視工作方式
• 思考是否有更好的解決方案

就像我們的電腦一樣，時不時需要重啟一下，清清快取，更新更新系統。不然，你可能還在用 IE 瀏覽器，堅持認為這是最好的選擇。

3. 保持好奇心#

好奇心就像是我們的 "技能點"，需要不斷投入：

• 看到新技術，先想想 "這個有意思"
• 遇到新方法，試著問問 "為什麼"
• 碰到新工具，琢磨著 "怎麼用"

記得有個同事說過："我不是天才，但我有一顆八卦的心。" 沒錯，職場進步有時候就靠這種 "八卦" 精神。

4. 建立 "試錯" 機制#

很多人不敢嘗試新東西，是因為害怕犯錯。但是，你想啊：

• 測試環境不就是用來犯錯的嗎？
• Code Review 不就是用來發現問題的嗎？
• 版本控制不就是用來後悔的嗎？

把 "試錯" 當作學習的一部分，就像打遊戲一樣，死幾次才能熟悉地圖，這很正常。

開放心態的實踐建議#

1. 從小事開始#

不要一上來就要啃最難的骨頭，可以：

• 今天試用一個新的 IDE 插件
• 明天學習一個新的快捷鍵
• 後天嘗試一個新的調試方法

就像玩遊戲要從新手村開始一樣，一步步來。

2. 找到學習夥伴#

• 和同事組成學習小組
• 參加技術社區
• 關注技術大牛的博客

有個夥伴一起學習，就不會覺得自己是一個人在戰鬥，同時，小夥伴還會給你帶來新的視角和思路，甚至於，起到一定的監督作用。

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. 壓抑不等於解決#

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

• 刻意回避反而加重壓力

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

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

• 影響工作和生活的質量

• 負面情緒需要適當宣泄

• 找到合適的傾訴對象

• 選擇恰當的表達方式

• 保持情