得到我的第一份後端工程師工作

前言

2025/11/25進入部門第一天，收到兩個tickets，打開vscode盯著看，我腦袋一片茫然，到底要怎麼理解這個東西？

於是我下定決心，要把我在過程遇到的所有問題都記錄下來，並且附上對我有幫助的資源。

（本文持續更新…）

心態

這兩篇文章安慰我這種溺水感：
Seven Steps for Surviving Your First Programming Job | HackerNoon

1. 大家都這樣，就算已經工作一陣子，新專案開始也是這樣
2. 確實存在有些人就愛把東西搞複雜
3. 別試著理解全部的東西
4. 優先學好測試
5. 把任務拆到最小，配合測試，一次做一個小修改
6. 了解到開發的複雜性和權衡，別當個憤世嫉俗的人批評前輩的做法
7. 學習OOP和Design pattern
8. 記得軟體的複雜度確實很瘋狂，先活下來之後，再慢慢讓事情變得更好

My First Year as a Professional Developer – Tips for Getting into Tech (freecodecamp.org)

1. 沒有人了解所有東西，重點是把自己需要用到的東西弄熟，對於其他部分有個廣泛的基本認識，其餘大部分時間都在figure things out
2. 作者過了幾年後回顧自己的經驗，覺得每段經歷都讓他成長，即使是有毒的環境也是
3. 永遠不要在一個不舒服的環境定下來
4. 如何學習的方法──其實就是一直試

如何Onboard？

剛加入一個團隊很有挑戰性，原因不是技術，而是「熟悉整個環境」，就像是搬到新家時也很消耗，因為要適應全新的生活習慣。

我覺得大腦在這個階段的信噪比很低，我接收到大量訊號湧入，但不知道哪些是我當前需要的，又有哪些是不重要的資訊，這就是為什麼我總是帶著筆記本記錄，因為真的跟不上大家討論的用詞和內容。

我提到的雜訊還有：團隊中每個人說話的方式、問題要問誰？問人的方式要訊息還是當面？這是我要自己解決的問題還是可以問的問題？組內的文件放在哪裡？常用工具有哪些？要怎麼查設定檔？諸如此類的問題，幾乎讓開發的效率降到最低。

不過好消息是以上的混亂都會隨著持續記錄，慢慢收斂出訊號，過了四周我已經開始能理解團隊會用到的服務有哪些等等，可以比較專注在「開發」本身，而非找尋各種東西放在哪裡。

這篇文章提到Onboard的方法，對我蠻有幫助的
How To Onboard - by Ryan Peterman - The Developing Dev

關鍵摘要： 先請主管或 Tech Lead 提供「關鍵人員名單」，有方向地認識團隊，在出問題時問問題會更有效率。接著用具體、目的導向的問題來學習，而不是泛問「我該知道什麼」。問題可聚焦三件事：

1. 團隊方向與動機（為何要做、期待成果），
2. 系統與責任範圍（在整體架構中的位置、團隊負責哪些部分），
3. 知識分布（誰最懂某技術、出問題該找誰）。

如何開始開發？

拿到一個需求，通常會經歷以下的流程：

1. 理解需求：什麼要做？什麼不要做？這次要做的範圍在哪裡？
2. 開始理解既有的程式碼與Domain → 要像組內資深工程師一樣能夠清楚的講出某功能運作的steps
3. 開始使用技術解決問題 e.g. Redis, Kafka, …
4. 提交Code review與修改
5. 用CI/CD上版到Development環境，並在測試環境做Integration test
   • 這邊要想一個驗證流程，確保功能上線沒有問題
6. 用CI/CD上版到Production環境，完成交付

1和2是brownfield development中花最多時間的部分，而一個稱職的工程師，要能夠和PM和討論功能的可行性、知道怎麼設計功能、知道當前公司系統的限制並給出建議。

至於第三點，有點像是會計師事務所不可能教員工excel，正如同軟體公司不會教員工redis, kafka，所以這些技術必須用自己的時間補強，才能夠把時間花在1和2上。

如何讀程式碼？

目標：讀程式碼最重要的是「理解既有的業務流程」，才能在之上繼續開發。所以能夠講出某個業務流程會經歷哪些處理、每個處理分別又是怎麼做到的，是最重要的。

一些我試過最基本的起始點：

1. Clone下來第一步先編譯和跑測試，確認沒有程式碼沒有問題
2. 實際執行，用debugger協助理解關鍵行為
3. 請copilot畫出關鍵流程的Mermaid diagram，這點對理解非常有用

這篇文章給了一些建議：
How to wrap our heads around large codebases and open-source GitHub repositories (shivangsnewsletter.com)

1. 理解大型陌生程式碼庫，從來不是「先讀程式碼」，而是「先理解系統」
   • 先理解一條完整的業務 flow，像是從UI到backend了解一個重點use case，再慢慢擴大理解
   • 可以先看data model、database scheme、ER diagram
2. Debug 是理解大型系統最快的方法
3. 新手不用急著貢獻開源，先把「寫得出完整系統」這件事練好

Debug

這篇文章介紹怎麼看待Debug： The Debugging Mindset - ACM Queue

1. 把Debug的本質上視為「學習」
   作者的關鍵轉換視角是：Debug ≠ 修錯，Debug = 知識獲取的過程
2. Bug的來源是什麼：認知不完整
3. Debug的心態：主動回想不要被動查詢、分段休息不要陷入沉沒成本、堅持自己會進步、保持好奇心
4. Debug的科學方法：「形成一個可被證偽的好假設」
   1. 建立理論
   2. 提出假設
   3. 驗證假設（有很多指標可以用，像是SQL指令執行時間、API latency）
   4. 推翻或修正
   5. 重複

實際的體悟：

1. 理解問題、能夠reproduce是最重要的，通常80%的精力都會花在這裡（但有些bug只有在特定環境才能觸發，就一定要在正式環境排查log）
2. 設計一個最小路徑以快速驗證
   舉個例子，如果reproduce bug需要按很多次UI才能觸發，可以花時間設計一個debug用的UI，直接觸發關鍵元件，這可以幫助自己縮小問題的範圍，也可以快速驗證到底有沒有解決掉問題。
3. 我發現debug和trace code很容易迷失，所以把「問問題」當作一種集中注意力的方式。講白話一點就是，想像如果主管隨時經過，問我現在在做什麼，我都能夠回答出來我現在的問題在哪裡，正在做什麼驗證，不然常常被淹沒在海裡。

求助也是工作的一部分

畢業後的第一份工作，發現學校和職場的心態非常不同。

在學校裡，老師或助教出難題是為了「考」我，解不出來就被扣分，反之就成績比較高，所以要通過測試證明自己的能力。

但在工作，這種心態反而是次要的，能夠「解決問題」才是最重要的，我有天洗澡的時候突然想通——求助也是工作的一部分。

為什麼這句話對我很重要？因為這一期的任務對我來說太難了，我這一週一直撞牆，除了情緒上焦慮以外，也對自己沒能力感到低落。反思之後，我認為這是因為我仍然抱持著「被測驗」的心態，覺得自己「沒有能力通過測驗」，就像是以前期末考爆掉，被考試證明自己很爛的感覺。

把求助當成能力的一部分，而不是能力差才使出的手段。

求助的能力包含：

1. 練習把問題說清楚
2. 練習在問問題之前先驗證幾種可能性，明確知道自己卡在哪裡，也讓其他人的協助能夠更有效率

Joyce分享給我這一頁，覺得很受用，就貼在這裡。資料來源：大人學破局思考

長期成長與學習

學習新技術

💡 關鍵在於：尋找「最小可行解」（minimal workable solution）

1. 尋找能持續回頭參考的官方權威文件
   先熟悉怎麼查文件，這聽起來很廢話，但老實要熟悉官方文件的結構沒有想像中直觀。
2. 一旦有可靠的回饋來源（官方文件），就去找最精簡的tutorial，遇到不確定的部分，以官方文件為主
3. 拆解並理解每個部分，在過程中問問題，不要淪被動的吸收
4. 嘗試重新實作部分內容
5. 確保自己有Transferable Skills，而不是overfit在特定問題上
   1. 建立一張筆記，從頭開始模擬：如果再次遇到這個問題，該怎麼解？以後可以快速回來參考
   2. 用自己的話嘗試把概念講清楚

Note：就算覺得超不熟，也不要浪費時間去找更多資源或課程，也不要亂逛一堆零散的部落格文章。直接去解問題，相信自己會在之後掌握這個技術。整個過程不要花太久，不然又像是回到學校那種地毯式學習模式，很沒效率。

長期成長

目前還在求生階段，還沒有真正體會到這些重點：軟體工程師如何長期成長？

我自己有體悟的學習方式：

1. 先混亂再整理，而非先理解再實作
   • 工作以後才發現這種和學校完全相反的學習模式：先模仿 → 實作 → 再發現規則 → 最後理解
   • 既有的程式庫就是最好的老師，幾乎所有問題都可以找到。像是怎麼讀取設定檔、call其他服務要怎麼寫等等
2. 兩個最好的學習來源
   1. 白天工作遇到的問題：主動整理、紀錄並輸出
   2. 額外花時間學習：但為了不要壓迫到自己休閒時間，我對學習內容是highly selective，不追求讀完一整本技術書，只挑幾個章節讀，並要求能夠輸出（品質大於量）
3. 關於輸出
   1. 把自己與gpt的聊天記錄，整理成blog post（可以自己先嘗試寫，然後再讓AI補成容易閱讀的文章，這樣AI寫出來的才不會和自己想的差太多）
   2. 錄影片自己教自己
   3. 每個學到的觀念，都「動手」寫一個實際可以跑的最小程式驗證（新訓期間主管教我的方法）
4. 關於輸入
   1. 開始工作後，感覺到需要學習的東西太多了，不知道從哪裡開始。
      我向後端工程部主管提出後，他建議我先做規劃，想清楚「自己三年後想要成為哪一種工程師」，再從這個目標反推回來現在什麼要學什麼不要學。他的意思是先問自己「為什麼要學這個？」

Soft skills的重要性

• 學會溝通和問問題非常重要
  • 每次問問題+得到回覆都花很多時間，常常問題的方向不對，又或是透過訊息很難表達
  • 勇敢地問，但在問問題之前先問自己五次為什麼，釐清問題在哪裡
• 拿到需求要先釐清需求，學會問問題去澄清
• 不要糾結，趕快推一版上去，讓其他人能夠code review
• 主動報告進度：在Daily時sync up自己的bottleneck，明確的說出自己現在進度到幾%
• 開發習慣：讓code維持能夠deploy的狀態（docker能跑、設定檔狀態同部署環境），以下提供兩種方式：
  • Consul設定成False，然後用appsetting.Development.json
  • 本地開發直接連consul

• Code review
  • 每個commit要小，這樣reviewer才知道要怎麼review
  • 發MR之前要確定可以compile + test
  • YAGNI: 要克制自己不要去修其他東西，專注在這次需求的交付就好
  • 可以問 mentor：建議這樣改的原因是什麼？code的意圖要明顯易懂，先從意圖開始思考

我的困境

困境1：遇到模糊性和資訊過載時難以前進

在拿到需求後，面對龐大的codebase和設計方案抉擇，我常常覺得缺乏充足的背景知識做決定，原因：

1. 對手上技術的理解不足
2. 缺乏業務背景
3. 缺乏對實作方式的權衡和理解

種種過量的資訊和未知，都讓我常常癱瘓無法行動

困境2：AI 時代標準水漲船高

公司內的資深工程師，其實都有經歷一段手寫程式碼的時期，也在過去的時間累積了對系統和工具的熟悉度。

但作為剛找到第一份工作的人，又搭上 AI 時代的開發新標準，我在缺乏經驗的時候，就要趕上大家的交付範圍和份量。對於沒有做過設計決策、程式架構的我來說，連怎麼設計一個好的API都不知道。但是 AI 時代不像過去能讓我慢慢累積經驗，我很快就被要求要獨立負責開發功能和服務。

雖然AI大幅加速交付的速度，但對完全缺乏經驗的人，光是把業務流程轉換成spec就已經有點困難。

2026/2/6學到的事情

這週完全沒有交付，壓力爆棚，好不容易想到一個簡單的做法，結果我交付的東西完全不是主管所想的，於是又要整個重做，原因出在我不知道怎麼設計一個新服務——API介面、還有軟體的架構。

感覺自己好爛，主管已經降低標準了我還是做不到，但後來覺得自己要修正對於「進步」的定義。

浪費兩天做一個完全錯誤的東西，我以前覺得叫做「浪費」不叫做「進步」，但我反思過後，如果今天沒有交出一個垃圾給主管看，我可能根本不會收到回饋。

我學到的東西：

1. 學會把錯誤用溝通拋出來，讓主管知道我在撞牆，整體團隊風險才能降低
   • Scrum開發流程的核心，其實是一個與風險共處的工作模式，不斷地溝通，是為了及早暴露每個人的錯誤與卡點，這些都是在不確定性中前進的方法
     • Daily stand up是提供機會給團隊各成員將交付的風險暴露出來
     • Retro是為了收集feedback，讓下一個sprint能夠化解這種風險
     • Design review是在實作前就先把錯誤的方向修正，不要等到交付才出事
2. 無法前進時，用假設去推進。在紙上寫下：我假設X，所以我採用Y
3. 如果溝通無效，另一個在AI時代累積經驗的方法，就是厚著臉皮先交一份程式碼，然後再依據回饋去修正，然後避免下次再犯

這次看到主管怎麼看一個網站，就能夠拆解出背後的API要怎麼設計，真的很驚艷原來可以這樣拆解和模仿一個服務。

半年內目標（到2026/6）

目標 A｜brownfield 獨立作業能力

1. 敘述：提升自己在brownfield上獨立作業的能力，能夠獨立設計不同方案並實作出來
2. 驗證方式：
   1. 拿到需求後，能夠用清楚的steps，在紙張上指出目前系統的狀態，與這次改動涉及的範圍
   2. 自行提出 ≥2 個可行方案，清楚說明 trade-off（風險 / 成本 / 影響）
   3. 方案被採納或經 review 後實作，完成 ≥5 次 brownfield 任務

練習在不確定性中持續推進和拆解問題：「我目前理解需求是 X，系統中可能是在 Y 處處理，我打算用 Z 的方式實作，但不確定是不是最佳方向，想跟你確認一下。」

目標 B｜壓力下的穩定交付能力

1. 敘述：學會在壓力中保持沉著與信心，穩定交付
2. 驗證方式：
   1. 能在接到需求後，分析任務所需的時間，讓任務準時交付
   2. 一旦判斷會延誤，至少在 deadline 前 ≥2 個工作天提出原因與調整方案（縮小scope/協助人力/延後時程擇一）
   3. 要能夠清楚紀錄延誤的原因：需求變更 / 依賴阻塞 / 估時錯誤 / 技術風險 / 資源不足

中期目標（到2026/12)

目標 C｜資訊不完全下的決策能力

1. 敘述：觀察同事是怎麼做出決策的，學會在混亂中把問題問好，並做出決策
2. 驗證方式：
   1. 面對模糊需求，能產出一份：
      • 問題定義
      • 已知 / 未知
      • 決策點
   2. 回顧並檢討決策的品質
      • 我當時的關鍵假設是什麼？
      • 最後結果證明：假設對/錯在哪？
      • 下次我會改哪一條提問或驗證步驟？

目標 D｜AI 協作與 Vibe Coding 能力

1. 敘述：能用Vibe coding快速從模糊的需求凝聚成具體的產品，在過程中釐清與AI協作的核心技能是什麼？
2. 驗證方式：
   1. 至少 2 個從模糊想法 → 可 demo 的產品或功能，並有至少一名使用者，完成一次回饋的迭代
   2. 產出一篇與AI合作的文章，文章中要明確列出 ≥5 條「AI 可以做」與「AI 不該做」的分界規則

長期目標？？

時程

附上自己每個階段的狀況。

1. 前三個月：拉肚子、生病、適應通勤、作息、人際、辦公室 我感覺這三個月沒什麼「專業培養」，是從自由自在的學生變成社畜的陣痛期，每天都很累又很緊張，不知道自己能做到什麼
2. 第三個月開始： 好像比較知道要怎麼勝任工作、願意在額外的時間開始學習，想把工作做得更好

一些可以持續學習的資源

Coding projects for developers: Let’s get some hands-on practice – Part 1 (shivangsnewsletter.com)

尚未解決的問題

💡 對犯錯很恐懼：很怕把系統搞砸、要麻煩別人修改、增加工作量。但這讓我沒辦法放鬆專注在工作上，搞到時時刻刻都很焦慮，希望自己面對新挑戰可以平靜，並且在犯錯時勇於認錯，從錯誤中學習而不是一直避免犯錯。