這是 30 天寫作挑戰的第 24 天。今天要來回答臉書留言的提問：
在當工程師的這 10 年裡，讓我心累的 3 個經驗是……
30 天寫作挑戰：連續 30 天，每天都會從 ChatGPT 、生活中的靈感或是網友提問中，選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你／妳的問題，可以問我一個跟工程師、技術產品經理、產品經理有關的問題。
被當成用過即丟的工具
不是修電腦、送宵夜的工具人，而是被當成是免洗筷般的存在：被交代的任務就是完成它、把程式碼寫出來。合不合理？那不是工程師該煩惱的事情，是 PM 跟老闆要煩惱的；寫的不好／被客戶罵不好用……是誰背鍋應該不用多說吧？作為一雙免洗筷，筷子就應該做好筷子的角色，好好的把菜夾起來，不要問為什麼，閉嘴做就對了。後來當然是趕快離開這樣的環境，任何人都不該助紂為虐。
做出來的東西沒人用
工程師不免會有匠人精神，會想要讓自己投入心力寫出來的程式碼能夠發揮最大的效益，為社會、公司或產品帶來價值，但市場是現實的，程式寫得再好、體驗做得再流暢，沒有打中使用者的需求、沒有人知道有這個功能，一切都沒有任何意義。
這也是為什麼後來我想要學習產品經理的職能，因為自己過往的經驗來說，不免在心裡會對做出的決策產生疑惑，但總會覺得也許是自己不夠了解市場，或是看事情的角度太過單一，因此就是乖乖做好執行者的角色。學了產品經理所需的能力之後，除了可以理解決策背後的理由、看得更全面以外，也在做出來的東西可能會變成沒人用的下場前，就先幫忙踩剎車。
每一個程式寫不出來的時候
在舒適圈跟成長圈的概念裡，超過自身難度 20% 左右的挑戰，最能讓自己成長。但倘若問題難度超過了這個範圍，這時就會陷入排查問題的地獄裡，如果網路上有資源、身邊有 mentor/senior 的同事可以諮詢幫忙倒還好，若一時之間找不到，又有時程壓力時，就會陷入更加焦慮、更加找不到解法的漩渦裡。這時候就會覺得自己很討厭寫程式。
處理方式當然有很多種：正面對決、繞道而行、延遲決鬥、打群架。
正面對決
追查程式碼、翻文件，如果是開源專案就把 code 打開來看。如果評估時間允許，建議用這個方式，但如果查了兩個小時甚至半天以上，建議就先停下來（應該說查了一個小時就該反應給其他人了）。
繞道而行
用其他方式解決，或是調整需求。逃避雖然可恥，但有用。
延遲決鬥
他強由他強，bug 放一旁。也許這個問題不會影響到完成任務，就先不處理，待之後有時間再來處理。通常這就會變成技術債的一部分……。就要看團隊怎麼評估要不要再花時間處理了。
打群架
試試看 pair programming, mob programming，三個臭皮匠都可以勝過一個諸葛亮了，多個工程師總會嘗試出可行的做法……吧？
今日寫作觀察
今天比較晚開始寫作，結果不知不覺快要寫超過時間了。驚覺自己有進入到心流狀態。
