離職教會我的事

踏入軟體開發也算是邁入了第十年了，前後後也大概待過了五到六家公司。每次決定離職的時間點，我還沒有覺得後悔過。

我從來沒有遇到一個完全 100% 符合自己想像，理想的工作環境。倒是常常出現「待在這個公司也沒什麼意義」、「其他公司會不會更好」，也常常會在離職後開始找工作時回頭想「如果當時那樣做，會不會就不一樣了」。

人生沒有後悔藥，每次離職都有很多事情可以學習，也會慢慢理解自己能夠發揮的優勢。但是在離職之前，你真的想清楚了嗎？我會以第一線開發者的身份分享一些血淋淋的案例，為未來的自己當作指南，也希望能夠幫助那些曾經迷惘是否要離職的人。

每個人對職涯的追求不一樣，有些人喜歡在公司裡面玩職場遊戲，在公司裡工作能找到更多成就感；也有人比較喜歡接案，保持生活上的彈性；或者是選擇一個完全不同的路線，比如創業。

沒有一條路是完全錯誤的。

我在某間公司離職時，當時還年輕的我曾經發了一篇一萬多字的文章，談我在公司裡面的經歷、對同事們的感謝、我對公司的制度不滿，以及我後來看到的事。

那篇文章被轉發了很多次，也被公司的法務看到了，他甚至還跑來文章底下留言說，公司最擅長的就是讓原本對公司失望的人離職之後變得更失望。

現在回想起來，專屬於年輕人的衝動是難能可貴的，現在回頭看那樣的自己，好像有點不成熟。

以前年輕的我，常常會覺得技術就是一切。

現在回頭看，那樣的想法很天真。有時候你會覺得你能夠放心地專注在開發上，並不是因為你自己變得更厲害，或者是你變得更好了，而是因為有那些前人的犧牲。

他們努力地把環境給架設好，基礎建設給搞好。你的主管幫你擋了意義不明的需求，或是在半夜被老闆痛罵一頓。這些事情你可能都不會察覺到，你只會覺得「哇我怎麼那麼猛！」。

離職不是解藥

我在後面的章節會提到需要優先考慮離職的情況，但在離職之前，你可以先想想看自己屬於哪種情況：

• 因為職場裡有你不喜歡的事（情緒、壓力），你想要逃避
• 你已經清楚知道你要什麼，你覺得繼續待在這裡無法得到你想要的

如果離職只是為了逃避環境中的不完美，往往會在下一份工作中陷入相同的循環。任何組織都必定存在資源分配不均、溝通效率低下或摩擦，這些限制反而是成長的好機會。

如果離職的理由是「環境不好」（例如：主管太強勢、流程混亂），但沒有在現有環境中嘗試優化流程，那麼當你在新公司遇到類似性格的人或相似的混亂時，依然會缺乏應對機制。

我在某個專案裡被晉升到 Tech Lead 時，我並不熟悉如何推進專案進度。

當時我在團隊裡技術相對掌握較多，也有比較多想法。但當時我的表達方式不佳，對於同事的提案挑三揀四，常常讓人覺得我非常強勢且難以合作。

後來同事給了我非常重的負面評價，認為我這樣的強勢會嚴重影響團隊士氣，他還直接寫我的行為讓他 pissed off。

後來我與主管 1 on 1，主管也鄭重提醒我，在職場上更重要的是發揮影響力。老實說一開始聽到這個意見我很不以為然，常常覺得為什麼大家好像都不太注重程式碼品質，然後現在還拿到負面評價。但如果只把不滿回報給主管，不會有任何改變或成長。

那一次對我來說是蠻大的學習和成長，我開始去顧及周遭的人，以及去想說我可以怎麼做，讓團隊發揮更大的產出。也開始涉略與管理、人際關係相關的書籍。

如果不是有主管的提醒，然後同事非常沉重的負面評價，我可能不會改變我的做事方式。

價值觀是雙面刃

想要在價值觀完全符合的職場下工作很困難。在職場中總有幾件讓你不開心的事：

• 主管只會叫人做事
• 辦公室政治

曾經我們有個需求是，希望使用者離開頁面後，可以自動呼叫 API 刪除圖片。很自然會想到使用 sendBeacon，然而由於某些原因 sendBeacon 沒辦法套用到那個場景。另一位同事便直接使用 ajax，它有提供 sync 參數，可以強制讓 HTTP 請求變成同步。

我當時看到那個解法很火大。因為我下意識覺得這根本不是專業開發者應該提出來的方案。

過了幾年後反思，我當時的態度以及心境是不好的。為什麼並沒有把為什麼用 Ajax 使用 sync 的快速給提出來，而且這位開發者他提出的解法，的確能夠解決當下的問題。

透過這個案例我發現，有時候並不是價值觀不合的問題，而是你根本從一開始就沒有想要理解對方的想法。這兩件事情是非常不一樣的。

把理所當然的事言語化

身為開發者，開發久了大概會知道，程式碼這樣寫會有哪些潛在的問題，看某一個函數的寫法就知道哪邊出現 Bug；聽完需求就大概知道架構會長怎樣。

環境變數不應該放到 Git 的歷史、用 Secrets Manager 管理、資料庫外網不公開、密碼要做 hash、用 SSR（Server-Side Rendering）加強 SEO、資料庫正規化。

這些開發者信手捻來的「常識」，你有辦法講出背後的理由與原因嗎？

在《刻意練習》這本書有提到，像西洋棋的大師，在展示棋局的 5 秒之後，他說大師能夠記住 20 多個棋子的位置或步驟。

但如果棋子是完全隨機擺放的話，大師和新手的表現是沒有顯著的差異的。這是因為高手已經累積大量的經驗，已經能完全依靠直覺推敲棋局的進行幫助記憶。

可惜開發不是下棋。當職位到達一定的高度之後，可能要和不熟技術、完全不懂技術的人解釋你這麼做的原因。這會要求把你視為理所當然的常識，轉變成可以讓別人懂的東西。

你會發現有時候視為理所當然的事情或心情，是沒有辦法言語化的。或是，你在逃避語言化。因為把想法、經驗、常識轉成文字，會逼迫你直面自己邏輯上的漏洞。

為什麼想離職？

我們來做個練習吧，為什麼你想離職？

可以先列出幾個理由：

• 老闆太機車
• 薪水太低
• 價值觀不一樣

如果我們再繼續具現化：

• 老闆太機車 → 什麼叫做機車？
  • 在上一次的專案中，我與老闆回報專案可能出現的風險，老闆沒有當作一回事，但是當風險發生後卻怪罪在我身上
  • 近一個月當中，老闆丟給我非職責範圍的工作，如買咖啡、打掃廁所的次數多達 10 次
• 薪水太低 → 你的理想薪資是多少
  • 我的理想薪資是當前薪資多 20%
• 價值觀不一樣 → 你的價值觀與你觀察到的價值觀落差為何
  • 以我目前的觀察，公司較為鼓勵個人英雄主義。因為當有人快速把某個功能完成時，老闆會給他比較多鼓勵；但是有人撰寫文件分享知識，或是改善部署速度時，老闆並沒有任何反應。我比較偏向有凝聚力的團隊分工
  • 公司沒有為員工制定成長、評價計畫、曾經提出 Onboarding 建議被否決。所以我認為公司比較傾向即戰力而非能一起長期打拼的團隊

像這樣，用實際的案例整理，會有更多可以思考的地方。

有嘗試改變嗎

有想要離職的念頭，也分析出原因了。

在這些原因裡面去找，假設這些原因都被解決了，你還會想要留在這裡嗎？如果答案是「會」的話，你有試著去改變嗎？

有幾個問題可以先問問看自己：

• 如果我遇到的困難與課題解決了，我會想繼續留在這裡嗎？
• 我有嘗試過解決這些問題了嗎？這是我能力所及所能做出最好的方法了嗎？
• 想想三、五年後的目標，這裡有辦法幫助你達成嗎？

在遇到問題的時候，我們很容易去怪罪環境，這是很正常的事。

在《與成功者有約：高效能人士的七個習慣》這本書中提到兩個圈圈，一個是影響圈，一個是關注圈。

關注圈是指所有你感興趣或擔憂的事物；影響圈是指在關心圈內，你可以透過行動直接改變的事物。

如果想要掌握自己的人生，我們應該要多關注影響圈，也就是你可以透過行動直接產生的改變，而非關注圈。

例如覺得薪水太低，是否有抱持著即使可能被拒絕或感到不舒服，也會試著去跟老闆談，你有試著提出公司應該給你加薪的依據嗎？你做了哪些事情，它帶來哪些成果？

你有跟老闆說：「我不想要做這些雜事，因為我想要更專注在我的產出上面」嗎？

價值觀不一樣，你有跟你的主管反應過嗎？

覺得程式碼太難維護，有試著提出方案，推進重構或改善，並說服主管為什麼這件事情很重要嗎？

如果你都做了，發現還是沒有辦法改變；再試幾次，還是沒有辦法改變的話，就可以考慮離職了。

專注在自己能改變的事情上面。

大公司的保護傘

很多人覺得自己在現職累積了很多技能、完成了很多專案，但說穿了，那可能只是資深前輩或技術長幫你把環境架設好，你只是在裡面照著別人鋪好的路解任務而已。

在一間有規模甚至是上市公司，通常你的職務範圍會切分得很清楚。

專案需要伺服器架設，你可以請 SRE 團隊幫你，他們會幫你把網路、權限、環境都幫你架設好，也會幫你撰寫自動部署的腳本，透過 Ansible 和 Terraform 做部署。

功能開發完了，會有專業的 QA 團隊幫你寫好測試計劃，然後由他們去執行測試、開票。

一切聽起來非常的理想對吧？

壞處是你只會專注在自己的職責範圍裡，當你今天到了資源有限，你需要自己從頭到尾去架設環境的時候，可能就卡關了。

這時候你就會覺得怎麼雜事那麼多，但這不是雜事很多，而是你之前的職場都活在一個保護傘裡面，而你沒有試著去跳脫。

如果你無法具體說出「這件事是因為『我』主動推動，才產生了什麼改變」，那你其實只是個被服務的客人。帶著這種過客心態跳槽，到了真正需要你自己開疆闢土的環境，絕對會吃大虧。

想往上爬，逃不過人與組織的難題

很多開發者會覺得技術是一切，像這種政治的事是骯髒的、不道德的。然而當你的影響力需求超過了個人產出上限時，你就必須透過合作來達成目標。

想要寫好讚的程式碼、好讚的架構並沒有辦法說服人，追求邏輯正確要求別人全盤接受，是一件相當傲慢的行為。

當你的影響力需求超過了個人產出上限時，你就必須透過他人來達成目標。人際關係與組織架構不再是阻礙工作的雜訊，而是工作本身的核心參數。避開這些難題，等於拒絕了規模化自己的機會。

我知道身為開發者，一定有自己的偏好、堅持，想要死守的價值觀。你很難去做到完全靠攏其中一邊，但我們能做到的是找到一個自己能夠接受的動態平衡。

在日本有一句俗語叫做「根回し」（nemawashi），意思是說在開會之前，或者在一個正式做決策的會議之前，分別私下去找那些有影響力的人，詢問他們的想法並與他們協調。

等到正式在會議中提出時，就更容易獲得認同。當你面對的專案，擁有的範疇更大時，你會需要開始觀察這些技術以外的事情。

我曾經有一個專案，需要從頭建設一個用於伺服器端渲染的伺服器。

因為我們當時使用的內部工具支援有限，再加上有一個需求是動態抓取資料的方式，所以我提出了新的架構來實作。

這個架構需要比較多部門的配合：SRE 需要準備和架設伺服器，企劃端可能也想知道這樣的功能之後可以為他們帶來哪些好處，開發端則會想知道架構上大概是怎麼設計的。程式碼本身的實作其實不難，它只是一個 Next.js 伺服器部署而已。

但是，為了說服這些跨部門的人，我準備了非常多的文件，針對不同部門調整寫法。當時剛好人手不太夠，導致我當時需要一邊推進與跨部門的溝通，一邊自己把這個架構實作出來。幸好有主管的支持，讓我在完成這個專案之後，拿到了一筆非常高的加薪。

雇用關係=資本遊戲

千萬不要抱持著「這家公司沒有我就活不下去」的想法離職，這種心態非常不健康。

在資本主義下，沒有人對公司來講是不可取代的。在資本市場一定找得到可以取代你的人。

雇用關係的本質是勞動力與資本的等價交換，而非情感的寄託。在組織架構中，任何人的功能都是可以被模組化取代的，這是資本主義追求穩定性的必然結果。

但對自己來說，加入一間公司代表的就是價值觀的選擇，你在公司獲得的技能、信任、人脈，都是沒辦法取代的資產。

我曾經問過創辦人，他有沒有把員工當成夥伴。後來回想，這個問題問得有點天真——就算真的當夥伴，僱傭關係依然存在。

既然是僱傭關係，公司要存活下來，核心就只有兩件事：公司有沒有賺錢，以及運作是否順暢。團隊的存在不是為了當彼此的夥伴，而是為了達成每一個目標。

當時我還問了另一個問題：假設員工生病或遇到一些煩惱，身為老闆，你會用話術去應付，還是會真的去關心？我知道這兩種做法產生的結果可能一樣，但我心裡仍然希望老闆是真心關心員工的。這個心態大錯特錯。

職場從來就不是用來交換真心的地方。老闆的職責是讓公司活下去、讓團隊產出成果，而不是成為員工的心靈導師或知心好友。老闆能用得體的話術讓員工感到被尊重、維持團隊士氣，同時又不讓私人情感干擾決策，這才是專業。

真心關心聽起來很美好，但它也有代價。當老闆對某個員工投入太多情感，裁員時會猶豫，績效考核時會手軟，資源分配時會偏心。這些猶豫與偏心，最終傷害的是整個團隊，甚至整間公司。

我不應該硬套入自己的憧憬而忽略僱傭關係的本質——員工付出時間與能力，公司給予報酬與舞台，雙方把該做的事做好，就是最大的尊重。職場需要的不是真心，是把事情做成。

成長來自痛苦

I wish upon you ample doses of pain and suffering. — Jensen Huang

當然，每個人加入職場的動機、職涯目標可能都一樣，或許是為了在有一份工作可以養活自己的同時，去尋找自己想要走的路，這完全沒問題。

NVIDIA 執行長黃仁勳之前提過，他希望每個人都去承受苦難，尤其那些從小到大有足夠資源、教育環境、家庭環境都夠好的環境出生，你被賦予非常高的期待，並且有辦法去付高昂的學費進入一個比較好的教育體系學習。他說這種人通常會有比較沒有韌性。

他覺得真正偉大的事物不一定是那種很聰明的人去做，而是那些受過苦的人做出來的事情。

一開始我不是很理解這句話，但現在我覺得慢慢可以理解。

我在大學的時候沒有那麼多的資源，所以像衣服、褲子、穿著這方面我都沒有辦法購買，也沒有餘裕買比較好的設備，甚至連電話費都繳不出來。

但也因為經濟狀況不佳，我有比較高的動力，我想要把學好、趕快學好某一門技術，然後趕快去實習。

這讓我有機會在大學求學的期間時就有累積軟體開發經驗，也讓我在之後的職涯有更有機會去追求技術要求比較高、薪資條件比較優渥的公司。

後來我在職場上有機會擔任 Tech Lead，負責帶領團隊做決策，或是做決定，然後跟其他部門溝通。這些事情都是你一開始做，不一定知道眉角在哪裡，你可能就要在這種你完全不知道、又在一個有高度不確定性的環境下進行。

升上主管之後，你又會面對不管是人也好、其他的成員也好，你沒辦法再用以前那一種「反正只要我的程式碼寫得夠好、有產出，我就可以得到一個好的結果」的思維做事，你要想辦法讓整個團隊變得更好。

每個階段當下都不一定是開心的，常常是痛苦的，因為它通常意味著你需要對現在的做事方法做出改變，甚至重新形塑自己的價值觀。

但是隨著做的決策變多，解決的問題變多，合作的人變得更多，跟老闆的溝通變得更多，看過的專案變多，你在這些相對不熟悉的環境裡面去找出解法，不斷嘗試，試著推進專案，過程雖然痛苦，但帶來的成長也是非常巨大的。

你開始會知道，現在的專案可能你之前就已經遇過，你大概知道架構跟技術長怎樣；為了讓專案順利進行，技術可能不再是最重要的那一部分。

你要怎麼去和關係利益人溝通？怎麼去說服他們你的方案可行？怎麼站在他們的角度出發？你會慢慢的掌握到，原來這些以前不會在意的細節，反而才是那個讓專案推進最重要的因素。

所以我覺得成長必定伴隨痛苦。

當你在職場裡面感受到痛苦的情緒在的時候，你可以想想看有辦法帶給你成長嗎？如果可以的話，那你可能不應該去逃避。

痛苦可以分兩種，一種是能讓自己成長的痛苦；一種是單純內耗的痛苦。

最近開始跑步，倒也不是真的很喜歡跑步。要早起，外面冷得要命還要跑，心臟快爆炸了還要跑，腳沒力了還要跑。

這些都很痛苦。但我知道累積跑量可以讓我更健康、心肺能力更好。

每次跑步的當下都很痛苦，但我從來沒有後悔過。反倒是因為在家裡耍廢而後悔。

無法帶來成長的痛苦就不太好了。

就好像你想要打排球，但發現遊戲規則是棒球。用排球的規則打棒球，怎麼打都不會贏。

困難在於，當下是無法分辨這兩者的，你根本不知道遊戲規則是棒球還是排球。

曾經遇過專案開發到一半，忽然宣布服務要關閉，我的績效就完全沒有了。那半年的努力成果直接泡湯。

話雖這麼說，如果要成長，就像跑步一樣，要持續累積痛苦，原本 9 分速跑得要死要活，現在 8 分速也不會喘。只有撐過去之後才知道痛苦帶來的成長。

從 FDE 反思職場

最近常看到一個職位叫做 Forward Deployed Engineer（以 OpenAI 為例）。這種類型不是典型的 Software Engineer 或顧問，而是有足夠深厚的技術能力，可以把 Prototype 部署到正式的環境，變成一個解決方案。

這是他的 Job Description

In this role, you will:

• Embed deeply with strategic customers to understand their business challenges and technical requirements in detail.
• Design, architect, and develop full-stack solutions using an experiment-driven, iterative approach.
• Prepare detailed scopes of work and project plans for both proof-of-concept prototypes and full production deployments.
• Work hands-on with customers' technical teams as a technical expert and trusted advisor, coding side-by-side to drive projects to completion on their infrastructure.
• Collaborate with Product, Research and Applied teams to ensure seamless customer experiences, project success and actionable product feedback
• Contribute to internal knowledge bases, codifying best practices and sharing insights gained from customer engagements to scale the Forward Deployed Engineering function.

You’ll thrive in this role if you:

• 7+ years of professional full stack engineering experience (excluding internships) in relevant roles at tech and product-driven companies - customer-facing experience is highly desirable
• Former founder, or early engineer at a startup who has built a product from scratch is a plus
• Experience with relational databases like Postgres/MySQL
• Have a bias for action and willingness to work iteratively with your customers to deliver the right solution that solves their problem.

一般 Software Engineer 在團隊當中的角色是——收到需求，PM 與企劃端已經 Refine 好，開發團隊按照這些需求實作出來。

Forward Deployed Engineer 是直接在客戶的面前，看他們現場運作的情形並提出解決方法，自己做出解決方案並能夠推進專案到上線。

這需要擁有把模糊的需求轉為可實際執行的能力，以及能跟客戶建立信賴關係的能力。

可以想像在這樣子的工作內容當中，會遇到很多需要溝通的事。與關係利益人溝通，說服對方自己的方案可行，在有限的資源與時程下給出最合適的方案。

它不一定會是你的那個舒適圈，或者是你習慣的事情。

不一定要玩職場遊戲

講到這裡，可能還是有人不認同。

為什麼我要花這麼大的力氣，去說服一個跟我價值觀相差甚遠的部門、主管、甚至老闆？這樣做真的太累了。

弭平認知落差很累、很痛苦、很無力，在職場下想要推進，但無法說服對方，只代表你的溝通還不夠、代表你的影響力還不夠，認知落差不是脫罪之詞，沒什麼好辯解的。只是離開職場遊戲規則之後，有些你真心不認同的事情，大可以說出來沒關係。

完全可以不玩這場遊戲。你可以鄙視它，可以不認同它。你可以說：我覺得這樣太累了，我想做我自己，我想專注在技術上、開發上，我想證明 technology always win。

完全可以。

但當你選擇這條路之後，你可能就很難在典型的職場裡往上爬。你可能需要花比別人更多的時間，去找到那間真正契合你的公司——老闆懂技術、尊重工程師、甚至本身就是很強的開發者，也給得起薪水。

然而，這裡有一個很重要的前提：不玩遊戲是一種選擇，但不玩遊戲同時又抱怨遊戲結果，就是另一回事了。

你不能一邊拒絕學習職場的運作規則，一邊又在那邊感嘆：「我明明是千里馬，為什麼遇不到伯樂？」

這不是懷才不遇，這是你自己選擇不走進那個會被看見的賽道。選擇本身沒有對錯，但每個選擇都有代價。

必須馬上離職的指標

雖然建議大家在離職前都要先想清楚，但這裡列出幾個要馬上考慮離職的指標：

身心靈受到嚴重影響

它可能反映在你的內分泌失調，晚上睡不好，飯也吃不下沒有食慾；心靈層面上，常常出現焦慮、憂鬱，或是做什麼事情都提不起勁。

一旦出現這樣的訊號，建議不要硬撐，就直接離職吧。身心靈的傷害是沒有辦法挽回的。

權限跟責任不匹配

被交付一個任務，主管要求你按照他的指示去做，而沒有讓你發揮的空間。但做出來的成績或效果不如預期，你會被問責、被質疑。

評價系統失調

公司的評價系統與你自己的價值觀不符合。

比如說，公司偏向交付工作給比較親近的人而不給予成長機會，或在公司裡面完全沒有評價機制，你不知道做什麼會被正確評價，你不知道公司對你的期待。就算跟主管溝通，也只會給出模糊的答案。

辦公室政治

比如有些人的關係比較好，跟主管的關係比較親近，甚至有親戚關係、家族關係，導致某個職位不是按成果晉升；又或者跨部門之間有很明顯的鬥爭。

職權騷擾、性騷擾

職場上頻繁出現職權騷擾、性騷擾，或者是老闆以消極的態度對待人才、不把員工的話當一回事、有做出反應但沒有改善。

有時候是這樣的，環境就是不適合，構造的問題很難靠個人改變什麼。

總結

前面分享了這麼多，但其實還有另一種思考方式：你清楚知道自己要什麼。

職涯對有些人來說，可能只是一份工作——為了有一份薪水，讓自己有更多餘裕去專注在真正想做的事情上。

每個人對職涯的想像與目標不同，不一定要追求往上爬或不斷成長。有些人追求的是安穩的生活，這也是一種選擇。

所以在思考職涯的時候，不妨先問問自己：工作對你的意義是什麼？你加入這間公司想達成什麼目標？

僱傭關係的本質依然是資本遊戲。在資本遊戲裡，個人其實是吃虧的——你隨時可能被取代。但你累積下來的技能、經驗、人脈、判斷力，這些資產是無法被取代的。

想清楚這件事，比決定離不離職更重要。

不管你最後選擇留下或離開，都希望你能做出對自己最有利的決定。也希望這篇文章對你有所幫助！