職涯故事

A collection of 9 posts
那杯茶
職涯故事

那杯茶

剛進公司那陣子,他出門前還會花一點時間在自己身上。 站在衣櫃拿起一件,想一下,再換另一件,確定好了,還會順手用蒸氣熨斗把折痕燙平。 換上隱形眼鏡,他對著鏡子看一眼,把頭髮撥整齊。 走到門口時,有時還會折回去再看一次。 那篇文章是他前一個週末寫完,帶進了公司。 上午他改了幾個字,午休前又重讀了一次,把圖的順序重新排過。 有前輩教他,把流程畫出來看。他畫了,那些原本容易漏掉的情況,順著箭頭一條一條出來了。 他想,這種坑以後進來的人也會踩。 那個週末,他圖重畫了好幾次,甚至還找朋友幫他看過一遍,確認別人真的看得懂。 吃完午餐回來沒多久,前輩喊了他一聲。 「我們來討論一下吧。」 他把文章打開,推到前輩面前。 前輩看完,頓了一頓,說: 「主動寫文件很好啊。不過你現在這個階段,還是先把基本功練熟比較重要。 我之前給你的那本書,你再多練幾遍看看。 先練到不用看教學,也能把基礎功能寫出來。」 他點頭,說好。 手卻先一步把教學文章的視窗關掉了。 那篇文章後來沒有再被提起。它一直留在他的 private 文件區裡。
閱讀時間 8 分鐘
開會
職涯故事

開會

會議上,同事在講新功能的概念,還沒講完。 我提出一個盲點。 同事視線往斜下方落了一下,嘴巴微開,停了半拍,才說「對誒。」 他開始接我的問題時,第二個問題已經頂到喉嚨口,幾乎是自己滑了出去。 他回答的速度降了下來,認真地說:「這個問題很好,我要想一想」。 我原本只是坐著聽,背卻不自覺挺直了,身體往桌前靠了一點。嘴角抿住。 走出會議室,我用比平常更快的腳步回到座位,什麼都沒做,只是不斷重播剛剛那一幕,不是我開口的瞬間,是他真的停下來想的那一秒。 腦中甚至開始浮現下一次的畫面:我再丟出一個問題,對方再一次停住。 隔一天的會議,我又在討論的斷點切了進去。 別人話還沒講完,我已經抓到提問的縫。 第一題還在試,後面卻越問越順。有一次我丟出一個問題,旁邊的人直接接過去,討論順著那個方向就展開了。 我第一次不是散會後才補交作業,而是在討論還活著的時候,跟上了那個速度。 那幾天,我甚至開始期待開會。 有次朋友聊到愛情觀,聊到一見鍾情, 他還找了一支短影片傳給我看,説他就是那樣的人。 我一邊看,腦袋卻已經先往前跑了,從他上次失戀到現在的模式、
閱讀時間 9 分鐘
答案來得太快之後
職涯故事

答案來得太快之後

閱讀器平常都在我身上,搭車會看,等人也會看。 那天下班打開新買的工具書,看了幾行,文字開始糊在一起,怎麼讀都進不了腦袋。把書蓋起來,打開手機,滑了十分鐘不知道自己在看什麼。再打開,又是同一頁。 不是身體累。 放下書,想說那來安排週末好了。打開行事曆,盯著看,挑個週末能去的地方。眼睛聚焦不了,關掉。 今天上班到底做了什麼? 其實沒做什麼特別的,只是打開 AI,跟它討論工作規劃,再一路審查它的產出。 以前寫到一半卡住,會開一個分頁,搜尋那段語法怎麼寫。複製回來,貼上去,跑一次看看。錯了,再查。那十五分鐘裡什麼都不用決定,手在動,腦子可以放空。 現在按下去,兩秒後整頁程式碼已經在那裡了。手還放在鍵盤上,但接下來每一行都要自己判斷。沒有那十五分鐘了。 我試過解決這個問題,寫更多的規則讓 AI 可以幫代勞判斷。它確實越來越像回事,但以前錯得明顯,現在是錯得漂亮。 我得停下來,
閱讀時間 7 分鐘
我原本以為那只是一次支援
職涯故事

我原本以為那只是一次支援

撇除公司一定要參與的任務之外,我們其實有一部分目標是可以自己選的。 有一次季初選目標時,我看到一個基礎建設任務。我看到的當下停了一下。腦中閃過的畫面很具體:三個月後的 demo meeting,我坐在那裡,從頭講一個自己主導的東西。不是補充說明,不是協助處理,而是有一條主線是我自己的。 同事舉手了。我沒動。我覺得對方確實能做得更好。我把視線移開了。 同一時間,另一個 API 重構任務正在找幫手。同事直接開口問了,有沒有人能支援。 我當下是抗拒的。 但我最後還是答應了。 我甚至還替自己找了一個很順的理由:只幫一下應該還好,原本的任務多少還是能往前推。結果我真正想推的任務進展很慢。時間被分去支援救火,最後哪邊都沒有長出很清楚的成果。 下一季到來,那個 API 任務又被提了出來。 我一聽到,心裡先縮了一下。 果然,沒有人接。 同事開始一個個往下問。 問到另一位也有主要任務的同事時,他沒有移開視線,幾乎在問題一說完的下一秒就回了不要,拒絕幾乎是直接撞在問句的尾音上。 我愣了一下。 現場沒有拉扯,沒有我以為會有的那種壓力。提問的同事只是很自然地轉向下一個人,好像剛剛那句
閱讀時間 5 分鐘
AI 時代的工程師成長:從學工具到練能力
職涯故事

AI 時代的工程師成長:從學工具到練能力

2024 年我參加了曼陀號,得到很多職涯建議。當時覺得那些建議閃閃發光,連續發了長文紀錄。我最喜歡的那篇是「技術海中浮沉,尋找未來地圖」— 就是因為那篇,我才開始有意識地寫技術文、設目標、做紀錄。 一年多後,我想回來看看那套框架有沒有用。但得先說一件事:我技術文斷更了。 原因很直接。AI 太強了。強到讓我開始懷疑,自己花力氣學技術、寫技術文,到底還有沒有意義。這個懷疑越滾越大,後來我就停了下來。 這篇其實想回答的,是一個最近一直讓我有點站不穩的問題:AI 加速之後,原本支撐我成長、也支撐我寫下去的那種自我確認,還剩下多少意義? AI 讓我開始懷疑寫技術文章的意義 那時候根據教學訂了一個目標:成為公司裡的 CDN master。為了驗證成長,我寫了 4 篇相關技術文,內部解了至少 3 個痛點。做完後確實變熟,甚至公司遇到相關問題都會先問我。 但有一次,在寫技術文的過程中,我把一篇寫到一半的文章丟進
閱讀時間 14 分鐘
要不要轉職?從業務轉工程師前,我怎麼判斷該停損離開
轉職心得

要不要轉職?從業務轉工程師前,我怎麼判斷該停損離開

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

工程師為什麼會解錯問題?從 Staging 到 SQL 優化的兩次復盤

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

新手工程師的 Code Review 衝擊:從訓練營到商業產品的現實落差

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

只補技術還不夠:我在曼陀號月會重新理解職涯與產品視角

轉職成工程師後,我前一段時間幾乎把重心都放在技術上。看文件、補知識、學工具,這些都很重要,但做了一陣子之後,我開始隱約覺得哪裡怪怪的:如果我只會從技術角度看事情,那我的職涯到底要怎麼往下走? 我會有這個感覺,是因為平常接觸的人幾乎都在公司內部,視角很容易被現在的工作環境限制住。也是因為這樣,我開始想找一個能接觸不同觀點的地方,後來加入了曼陀號。這是一個為期約六個月的 mentoring 計畫,每月有實體月會,也會搭配小組線上討論。 對我來說,它最有價值的不是活動形式本身,而是我第一次有機會在公司之外,聽到不同背景的工程師怎麼理解職涯、產品與工作的下一步。 第一次 engineer 組月會裡,船長 Jalex 講的不只是工程師要學什麼技術,而是我們的影響力、角色定位,還有職涯發展怎麼思考。那次我才比較明確地意識到:我原本以為自己缺的是更多技術知識,但其實我也缺少了看待職涯與產品的視角。 這篇我想從月會中最有感的兩個主題談起:職涯發展故事,以及產品思維。其中第一個真正打到我的,是怎麼從工作裡累積自己的職涯故事。 很多人前期只專注把任務做完,卻很少回頭想:我現在做的這些事,未來有
閱讀時間 12 分鐘