# 成為軟體工程師，然後呢？

## 前言

**整篇會比較像是一個雜談，反正就想到甚麼寫甚麼。**

成為軟體工程師進到公司也將近四年了，部門在前三年間走的人遠遠大於來的人，但好消息是這半年來，部門加入了好多優秀的新血，但在跟他們聊天的過程中赫然發現，我認為如此優秀的他們，對於這份工作還是充滿焦慮跟不安。

於是身為差點死在沙灘上的前浪，我想利用年前最後一點自己的時間，用我自身有點烙賽的經驗，分享給也處於這種狀態的工程師，也順便梳理一下自身這四年的成長，再展望一下未來的自己會成為怎樣的工程師吧！

## 背景

快速回顧自己的背景好了，私立大學財金系畢業後先在 FMCG 工作一年後回家工作，然後中間考上四中資管所，等報到時間到後準時辭職當菸酒生。

研究所時期的教授是在醫療資訊大數據的專家，這段經歷也幫助我拿到一家醫療資訊新創公司的實習生的缺，中間就邊寫論文邊實習，碩論口試結束後沒多久開始面工作，運氣好的是當時是大徵才時期，願意把我撈上岸的公司很多，最終就選了一家面試過程很舒服的系統廠擔任全端軟體工程師，待到至今將近四年。

## Entry / Junior 工程師可能會遇到的問題

### 一、*[冒牌者症候群](https://womany.net/read/article/13322)*

想先來談談這個困擾我最深的難題 - 冒牌者症候群，關於他的定義可以參考連結，看完我的背景，應該不難想像我會有這狀況，非本科跨考仔一開始擔任軟體工程師，我的冒牌者症候群真的超級嚴重，若你跟我一樣，一直覺得自己在工作上的成就，都是運氣使然，那你可能可以試試這幾種方式緩解你的焦慮：

1. #### 找到你的擅長的地方

> 在你擅長的地方，拿回你失去的分數。

##### 工程師這個職業不僅僅是寫程式碼，還有許多面向可以討論，比如溝通協作、問題解決能力等等。

##### 而我在初期自己擅長可能是溝通能力的部分，初期寫不出高品質的程式碼，我就在溝通需求，問題釐清上拿回分數，起碼讓跟我合作的人感覺自己仍是有專業的地方，所以找到你擅長的地方，並專注於發揮它們時，你會發現自己在團隊中的定位越來越清晰，對自己的信心也會逐漸建立起來。

2. #### 接受自己可能沒那麼好

##### 剛入職難免會期待自己能在所有事情上表現優秀，但試著接受「自己可能沒那麼好」這個事實，應該是我覺得最重要的一步，這跟「我就爛」的心態有所不同，而是當我們能坦然面對自己的限制，不再過度苛責自己時，反而更容易擁抱成長的機會。

3. #### 別人可能也沒那麼好

##### 剛入職時，每天在跑　Scrum　總會很驚訝別人做事的方式，覺得我可能到不了那個高度，但事實是，大家都有自己的弱點和不完美，只是他們的問題可能不像你的那麼明顯，或者他們更擅長隱藏自己的不安與挫敗。

##### 我也想推薦一本對我意義很重大的書：無*瑕的程式碼 番外篇－專業程式設計師的生存之道 (The Clean Coder: A Code of Conduct for Professional Programmers)*，你會發現許多優秀的工程師也會在一些小地方很烙賽，但還是無損他們的偉大。

---

### 二、*到底該怎麼問問題*

> 他以為他可以，他想問得得體

這句來自蛋堡「關於小熊」的一段歌詞應該講到很多 Junior 的心聲吧，遇到一個技術問題或是規格不明確的時候，往往需要求助於同事，但又害怕自己的問題是不是太過簡單，會讓人覺得自己怎麼拿到這份工作的，所以後來自己稍微想了一下甚麼是「**該問的問題**」，而甚麼又是「**不該問的問題**」。

#### **該問的問題**

1. #### 影響團隊或專案進度的問題

影響團隊進度，且已嘗試基礎排查。
例:
> 我在部署新功能時，發現伺服器突然無法連接到資料庫，導致整個服務中斷。我已經檢查了連線設定和防火牆規則，但還是找不到問題。

2. #### 團隊或公司內部規範問題
例:
> 我們團隊在Git流程中，是應該用rebase還是merge來整合分支？文件裡提到兩種方式都可能用，但不確定具體情境。

#### **不該問的問題**

1. #### 未嘗試Debug的模糊問題

例:
> 我的程式碼跑不動，可以幫我看嗎？
:::info
這應該是最致命的問法，直接把問題轉嫁給下一個人而已，在問此類問題盡量提供錯誤訊息、上下文或自己嘗試的過程。
:::

2. #### 明顯可自己驗證的問題

這類型的發問通常會發生在 Junior 明明自己可找到方法驗證，但懶得自己動手做一次，想要拿其他同事的建議或經驗當背書，應該避免發生這種情況。
例:
> 如果我修改這個參數，會發生什麼事？

## 我目前是怎樣的工程師？

說實在，非本科跨考仔一開始擔任軟體工程師，我的[冒牌者症候群](https://womany.net/read/article/13322)真的超級嚴重，幸運的是，當時 TL 跟其他同事給我很大幫助，才漸漸走出那種恐慌感，在擔任 4 年的軟體工程師，自己的技能樹大概點成像這樣：
### 技能樹

目前的自己可能更接近Mid-Level SE，以下列出我認為 Juinor 跟 Mid-Level 的差異，基本上最大的差異就是對於手上的技術善用的程度，跟獨立完成作業的程度。

#### **1. 技能對比**

| **能力範疇** | **Junior 工程師** | **Mid-Level 工程師** |
|---------------------------|-------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| **Java 基礎** | 理解核心 Java（如 OOP、集合、異常處理）。 | 熟練掌握 Java，並對 Java 8+ 特性（如 Lambda、Streams）運用自如，能優成程式碼性能。 |
| **框架和工具** | 了解基本框架（如 Spring Boot），能跟隨指導完成簡單的 REST API。 | 深入掌握 Spring Boot、Hibernate，能獨立設計和實現複雜功能。 |
| **資料庫** | 能執行基本的 SQL 查詢，對 RDBMS 有基本理解（如 MySQL）。 | 熟悉 SQL 調教、索引、事務。 |
| **問題解決** | 需要較多指導，能解決簡單的 bug，但面對未知問題可能需要幫助。 | 能獨立解決中等複雜度的問題，熟悉調試和性能分析工具，對程式碼有更深的理解。 |
| **架構理解** | 對整體系統架構的理解有限，僅專注於所負責的功能。 | 理解系統的設計原則，能參與架構設計，並在必要時提出優化建議。 |
| **工具熟練度** | 能熟練使用基本的 IDE（如 IntelliJ IDEA）和版本控制工具（如 Git）。 | 對工具有深入了解，能配置 CI/CD 流程，熟悉 Docker 和 Kubernetes 等部署工具。 |
#### **2. 責任與角色期望**

| **範疇** | **Junior 工程師** | **Mid-Level 工程師** |
|---------------------------|-------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| **專案參與** | 在指導下完成分配的任務。 | 獨立負責開發，並協助指導 Junior。 |
| **設計與規劃** | 很少參與設計與需求分析，主要執行分配的任務。 | 參與需求分析，對系統設計提供建議，並能計劃解決方案的細節。 |
| **Code Review** | 主要是接受 Code Review ，學習改善程式碼的方式。 | 主動參與並進行 Code Review ，並提供反饋以幫助 Junior 成長。 |
| **問題解決與支持** | 需要頻繁請教同事解決問題，獨立處理問題的能力有限。 | 能獨立解決問題，並幫助 Junior 工程師解決技術障礙。 |
| **軟實力** | 學習團隊溝通與合作，努力融入項目流程。| 具備良好的溝通能力，能主動分享知識。

## 未來的路在哪？

整體來說，現在的自己與四年前相比，在專案開始或系統開發時，開圖能力已經大幅提高了，當 Team 上的 Junior 遇到技術困難時，可以給出適當的建議，但這都屬於比較像是經驗是累積後的結果，若要從 Mid-Level 到 Senior 的話，可能還必須有更多的成長，所以這邊也列一下自己認為若要往下一階段前進的話，自己可能還有哪些地方可以持續成長。

**1. 系統設計與架構能力**
* 精進方向：
* 學習分散式系統設計（如微服務、事件驅動架構）。
* 練習設計大型系統（uber or X）。
* 閱讀經典書籍，如《Designing Data-Intensive Applications》。

**2. 專案品質與完整度**

* 精進方向：
* 在開發過程中，注重需求的理解與實作的完整性，避免功能缺失或半成品交付。
* 確保程式碼的可讀性、可維護性，並遵循最佳實踐（如 Clean Code、SOLID 原則）。
* 導入自動化測試（單元測試、整合測試）與 CI/CD 流程，確保每次交付的品質穩定。
* 在專案結束後，進行回顧（Retrospective），分析哪些地方可以改進，以提升未來專案的完整度與品質。

**3. 探索外部職缺與挑戰**
* 精進方向：
* 定期更新 LinkedIn 和履歷，並設定職缺通知。
* 參加技術面試，了解自己的市場價值。