在當工程師的這 10 年裡，讓我心累的 3 個經驗是…...

👉 #被當成用過即丟的工具

不是修電腦、送宵夜的工具人，而是被當成是免洗筷般的存在：被交代的任務就是完成它、把程式碼寫出來。合不合理？那不是工程師該煩惱的事情，是 PM 跟老闆要煩惱的；寫的不好／被客戶罵不好用……是誰背鍋應該不用多說吧？作為一雙免洗筷，筷子就應該做好筷子的角色，好好的把菜夾起來，不要問為什麼，閉嘴做就對了。

後來當然是趕快離開這樣的環境，任何人都不該助紂為虐。

👉 #做出來的東西沒人用

工程師不免會有匠人精神，會想要讓自己投入心力寫出來的程式碼能夠發揮最大的效益，為社會、公司或產品帶來價值，但市場是現實的，程式寫得再好、體驗做得再流暢，沒有打中使用者的需求、沒有人知道有這個功能，一切都沒有任何意義。

這也是為什麼後來我想要學習產品經理的職能，因為自己過往的經驗來說，不免在心裡會對做出的決策產生疑惑，但總會覺得也許是自己不夠了解市場，或是看事情的角度太過單一，因此就是乖乖做好執行者的角色。學了產品經理所需的能力之後，除了可以理解決策背後的理由、看得更全面以外，也在做出來的東西可能會變成沒人用的下場前，就先幫忙踩剎車。

👉 #每一個程式寫不出來的時候

在舒適圈跟成長圈的概念裡，超過自身難度 20% 左右的挑戰，最能讓自己成長。但倘若問題難度超過了這個範圍，這時就會陷入排查問題的地獄裡，如果網路上有資源、身邊有 mentor/senior 的同事可以諮詢幫忙倒還好，若一時之間找不到，又有時程壓力時，就會陷入更加焦慮、更加找不到解法的漩渦裡。這時候就會覺得自己很討厭寫程式。

處理方式當然有很多種：正面對決、繞道而行、延遲決鬥、打群架。

👉 👉 #正面對決

追查程式碼、翻文件，如果是開源專案就把 code 打開來看。如果評估時間允許，建議用這個方式，但如果查了兩個小時甚至半天以上，建議就先停下來（應該說查了一個小時就該反應給其他人了）。

👉 👉 #繞道而行

用其他方式解決，或是調整需求。逃避雖然可恥，但有用。

👉 👉 #延遲決鬥

他強由他強，bug 放一旁。也許這個問題不會影響到完成任務，就先不處理，待之後有時間再來處理。通常這就會變成技術債的一部分……。就要看團隊怎麼評估要不要再花時間處理了。

👉 👉 #打群架

試試看 pair programming, mob programming，三個臭皮匠都可以勝過一個諸葛亮了，多個工程師總會嘗試出可行的做法……吧？