如果你不是那萬中選一熱愛工作的優質員工的話，我相信我們或多或少，都曾經或著即將會與職業倦怠有些交集。即使在不同國家、不同職業、不同年資之間有樣本數或形式上的落差，也沒有必要因此被刻板印象定義自己的狀態。
統計數字終究只是有助於旁觀者理解而已，遠不如多花點心思了解自己來得實際，即使我是唯一一個做軟體工程師做到職厭倦怠的人，我仍會想找個機會談談這段經驗。
當時並沒有預先感覺到什麼明顯的徵兆讓我能先行處理這問題，基本上是已經陷入職業倦怠的狀態，才後知後覺的意識到需要應對一下。值得慶幸的是過於理性的思考方式依舊穩定運作著，有條有理的把自己搞定後，還能將當時虛無飄渺的情緒與感受轉化成這些具體文字。
我曾經以為自己對軟體工程的熱忱根本不會有職業倦怠的問題，但我很快地發現那跟工作完全是兩碼子事。更準確一點的來說，是我深刻體會到「是不是優秀的軟體工程師」和「會不會職業倦怠」兩者間沒什麼關聯。
這就先來談談職業倦怠的原因好了，網路上能查到很多，但我只會談談我自己的：
優秀的軟體工程師不會職業倦怠
在高手雲集的同溫層裡距離優秀可說是遙遙無期，但至少我有個明確的方向持續努力著，而不要被職業倦怠扯後腿就是其中之一，現在回頭看這真是個坑自己的爛主意。
即使再怎麼糟糕的情境，我仍會盡可能使用合理的設計，交付品質至少能讓自己接受的程式碼，持續輸出知識提高整體技術水平。這些一個不漏的做起來說真的勞心費神，沒有時間能浪費在職業倦怠上。
這就是當時當時的賭局，究竟是我先成為理想中「優秀的軟體工程師」然後將一切應付得得心應手，還是先沉入職業倦怠的泥沼中，被迫認清事實著手處理這個狀況。
結果明顯是後者。前者以我對自己的要求在當時的環境待個十年也無法達到，即使成了也不可能如我所願得心應手，因為有許多關鍵的外部因素不會因此而消失。
原本以為職業倦怠只是自己的個人問題，但顯然不是。
企業文化與價值觀的不相容
職業倦怠成因中那些與工作環境或內容有關的，雖然有些歸因於產業性質，但八成都和企業文化有所關聯。從程式碼變數命名規則這種灰塵般的小議題，大到加班時數有沒有違反勞基法這種紅線，處處都清晰的反映著。
無所不在的企業文化我一直都有所察覺，但也僅止於察覺，然後講些自嘲的工程師笑話和茶餘飯後的八卦消遣而已，頂多我抱怨的頻率比平均值高了點。
除此之外我並沒有，確切來說是沒有想到可以，特別有目的性的去掙扎什麼。就如同在荒野中遇到暴雨，我知道被淋濕很糟，但也沒得躲，跑起來也不會淋比較少，多遇到幾次久了就習以為常了。
大概是這個時期，企業文化不相容對我而言更像一種天災，我沒能力抗衡它。這種束手無策的無力感隨著天災的發生次數快速累積，日復一日，難以消散。
一直到我已經用其他方式解決問題後，我才驚覺這方向可能有令人耳目一新的答案，開始動腦追溯根源。而我得出的結論是：有些東西無法改變是因為有其他人覺得這麼做相當合理，要改變文化需要先改變關鍵的人。
以工作量規劃為例，有些團隊將留有餘裕視為常態，若沒有應付緊急需求則由成員自行提案。有些公司將工作量塞滿作為常態，僅有在連假時才會進行減量，若遭遇緊急需求仍需要調度人力解決。
當然，職業倦怠並不是什麼絕症，至少在我身上不是。然而這需要的絕對不是精神雞湯，而是在釐清原因後用對應的方法根治。
軟體工程師是份工作
在我把自己的個人定位和軟題工程師的職位完全剝離後，精神負擔可說是如釋重負。它不過就是份工作而已，沒有必要把自己對於軟體工程的堅持或憧憬全然投射在上面。
我們可以是個十分擅長效能最佳化的工程師，但沒有必要在工作中無時無刻做到這一點，你甚至不需要讓同事知道，避免承受額外的期待。
也許是服兵役時體悟到的心得，既然躲不掉不如抽離所有情緒與價值觀，就當那段時間昏迷了一樣。一週約莫就四十小時，放下執著隨和地應付，剩下的時間和精神都是自己的。
當然這也不是在慫恿人扔了技術背景的堅持，而是強調工作本質是利益交換，審時度勢理性投入。把自己的整套價值觀給搭進去，很容易把無力感反向傳遞回自己身上，形成「職場不順 == 職涯不順 == 人生不順」的僵局，迅速導致職業倦怠。
軟體工程並非一定得和工作綁死，規律性的閱讀和寫作對我來說就是一大樂趣，下班後的職涯對許多人來說相當陌生，但也因此才有更多的可能性值得探索。
改變自己的工作內容
最初我完全沒有朝著這個方向思考過，一直以為工作內容就固定是 job description 上寫的那些，我頂多只能多拿幾個 offer，在它們之中選個喜歡的而已。
一天超過 6 小時在寫 code 對我來說是種折磨，光想像這種日子未來還要持續個一兩年就足以觸發我的職業倦怠，但其實目前痛苦並不代表未來都將如此。
隨著對工作事務的上手，我很快便有了些時間上的餘裕能夠深入研究些感興趣的技術、跑一些實驗、甚至多管閒事的去推動些沒被要求但我覺得值得一試的改善計畫。
對工作的興趣似乎因此而有些復燃的跡象，加上有前輩明確地和我討論調整工作內容的可能性，也有同儕分享類似的經驗，我才有意識地將這作為向上管理的其中一個目標。
即使經歷了工作轉換，這個方法仍然給了我自己不少幫助。寫程式的時間降低至平均每日 2 至 4 小時左右，對我來說是個舒適的範圍，但可能也和我對程式語言的熟悉度提升有關。
取而代之的是多瀏覽一些技術方面的設計提案，並協調工具整合來改善流程中的痛點，這對我更有吸引力的多，當然也少不了自行研究的部分，而最終知識也將被應用在公司產品上。
預防遠勝於治療
當然，如果能在入職之前事先知道自己會不會快速感到倦怠，那應該是在好不過了。
為此我盡可能明確的整理出感到無力的因素，並且有技巧地確認對方團隊中是否存在類似的問題。下面列出了幾項，也許能讓你有些共鳴：
- 不願意投入資源進行自動化，維持勞力密集作業
- 將超額的工作量作為常態，完全不當它是問題
- 職等或薪酬受到硬性限制，比如學歷、年資或性別
然而這些資訊往往會影響到企業品牌形象，對方不一定會據實以告或是被要求以官方說法回應，執著追問可能也有損印象分數，我個人習慣是用一些旁敲側擊的方式確認。
比如半開玩笑的提一下過去工作經驗中的慘況消遣自己，觀察對方有沒有露出「真的假的這裡也差不多欸！」的表情，或是管不住嘴直接真情流露的把一切都招了。
具體上也可以藉由請教「部署新版本的流程」來試探自動化程度，以及用「想認識喜歡旅遊的同事」開話題，試探連假是否會被凹加班，以及請長假是否會被刁難。
要記住獲得資訊才是首要目的，各式話題與閒聊氛圍都只是手段，要圍繞著目的去設計與開展。
寫到這裡，大致上談了上一次職業倦怠的種種感受與經驗，以整個職涯來看其實是在相對初期的時候，比大多數案例提早了不少。
主因應是對於工作環境有不合理的期待，又沒有足夠的能力與經驗立即做出改變。所幸情況不嚴重，在尚未深陷其中時就採取行動脫身，如今能一邊回憶整理思緒一邊淬煉文字將其更好地表達出來，十分值得作為成功克服的紀念。