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

前言

2025/11/25進入部門第一天，收到兩個tickets，盯著Jira需求單，然後把codebase clone下來，打開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. 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

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

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

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

求助也是工作的一部分

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

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

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

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

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

求助的能力包含：

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

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

學習新技術

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

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

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

長期成長

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

一些可以持續學習的資源

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

尚未解決的問題

💡 AI：工作以後，覺得沒有AI就寫不出來，但又有進度壓力不能不用AI，感覺自己沒有在成長

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