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