那些隱藏在果決背後的猶豫 這是我四年多前，從業務轉職成工程師前留下的碎念，現在的我做回顧，已經跟這些情緒有了距離，但我決定把這份脆弱留下來，遞給還在漩渦裡的人。 前陣子有讀者詢問我轉職方向，他卡在最源頭的掙扎：還不確定要不要轉職。這讓我意識到，過去的文章我大多呈現了確定目標後的果決，但那並不完全真實。事實上，在做出決定前，我經歷了長達一年的猶疑與反覆徘徊。 那段時間並不是某個瞬間的頓悟，而是一圈一圈的反覆確認與試錯。猶豫本身，是無法被壓縮成一句結論。當時我花了一段時間用各種方式測試、調整、再觀察，最後才下結論：繼續撐沒有用，該停損了。 這段歷程值得被記錄下來。如果你現在也卡在「要不要轉職」，或者單純好奇那些猶豫的人究竟在想什麼，希望這篇文章能給你一些共感。 關於業務工作的實測結論：開發型與維護型的差異 為什麼這兩條路，最後都沒有走得下去 業務其實有不同類型，例如：「維護型」、「開發型」，這邊只舉這兩個簡單說明。同一個職務也有可能開發跟維護都有，差別在於比例多寡。我曾做過半導體代理商業務（維護）、儀器業務（開發）、半導體原廠業務（維護）。 面向 開發型業務

之前提到要寫關於復盤（反思）的文章，這個想法在我腦中躺到都長灰塵了。 想到要從早期的文件重新檢視那些現在看來淺顯易見的錯誤，同時也得面對自己當初的不足，心裡的抗拒比想像中大太多了。畢竟剛轉職時踩過的坑又痛又深。趁著過年長假慢慢寫下來，總算把這段思考整理完成。如果你也對復盤在實作中的實際應用有興趣，以下紀錄我的思考歷程。 工作一段時間之後，我發現過去很多錯誤不是因為技術不好，而是因為太快開始解題。過去習慣看到問題就動手優化、修正、調整。好像只要把手段做漂亮，事情就會自然變好。 但有時候，真正應該先做的，是停下來確認：這個問題本身對嗎？我們要解的到底是什麼？成功的定義是什麼？那些「看起來理所當然」的前提，真的成立嗎？ 這篇文章是我用現在的視角，回頭檢視兩年前的自己，並紀錄我當時怎麼利用復盤跟反思，一步步改正自己的思考習慣，把自己從「急著答題」拉回「先把題目問清楚」。用兩個印象很深的踩坑案例，拆解我剛當工程師時在驗證標準、責任邊界、以及對既有邏輯的假設上，常犯的錯。 情境回放：電子發票上線的意外 — Staging OK 卻卡在 Production 2023

轉職不只打怪升等，更是「被怪打到痛」的真實洗禮——這篇記錄被怪打的心得 （以下內容著墨於轉職第一年的心得） 我的總體歷程大概是這樣： 功能可以動 → 可讀性問題 → 品質盲區，驗證不足 → 思路狹窄，只會找一個可行解 → 慢慢開始有自己的想法 這歷程裡的每一段，對我來說都不是自然而然突然會的，而是「刻意練習強制修正」。從訓練營出來也就 6 個月學習時間，仍然是趕鴨子上架，很多觀念只是了解表面而已。 真正進到商用產品真的還差了一大截，不可否認剛開始我對自己感覺良好，畢竟從訓練營畢業，能做出網頁而且可以 demo 我已經覺得自己很棒。但第一次 code review 之後就讓我面對現實了… 滿滿的 code review comment，讓我發現還有很多成長空間。想起來那段時間充滿壓力，每天不斷反思錯誤在哪，真的是胃痛啊啊啊啊啊啊。 Code Review 是照妖鏡：「以為懂了」，其實還沒懂？ 曾經前輩對我提出這個問題，並且要求我理解問題的時候加入以下流程： * 什麼是 XX？