圖文／Luka Huang

本篇文章是閱讀 vgod 撰寫的「軟體工程師的修煉與成長」系列文的心得筆記。

系列文連結

軟體工程師的修煉與成長 (1) — 程式設計 → 軟體工程
軟體工程師的修煉與成長 (2) — 規模與複雜度
軟體工程師的修煉與成長 (3) — Oncall的挑戰
軟體工程師的修煉與成長 (4) — Product vs Infrastructure
軟體工程師的修煉與成長 (5) — 1:1該談什麼才能讓職涯起飛?
軟體工程師的修煉與成長 (6) — 換團隊 x 2
軟體工程師的修煉與成長 (7) — 如何突破資深工程師的天花板
軟體工程師的修煉與成長 (8) — 讓自己可以被取代
軟體工程師的修煉與成長 (9) — 選擇適合自己的公司
軟體工程師的修煉與成長 (10) — 四維的技術能力

軟體工程師的修煉與成長 (1) — 程式設計 → 軟體工程

寫程式這件事只是軟體工程的一小部分

程式寫得好是先決條件，寫好程式以後開始學習

✅ 怎麼寫對於團隊來說是好程式
✅ 怎麼在已經上線的系統除錯 (Debug)
✅ 怎樣不會把別人寫得程式搞壞

高等級工程師的價值不在於能比初級工程師寫得更快或更好

❌ 高等級的工程師的價值不在於比初級工程師寫程式寫得更快或更好
✅ 越高等級的工程師花在寫程式上的時間通常越少
✅ 能把周圍人的產出都一起變快變好。

大型軟體工程除了硬知識，軟技能也是必要條件

硬知識：
✅ 開發流程 (Agile / Scrum)
✅ 系統架構設計
✅ Design Pattern
✅ UML

軟技能：
✅ 溝通
✅ 領導
✅ 協作
✅ 培養新人
✅ 建立團隊文化

— 以上內容引用自原文 —

軟體工程師的修煉與成長 (2) — 規模與複雜度

「Facebook複製品」和真正的Facebook最大的差異

一個學生做的「Facebook複製品」和真正的Facebook最大的差異在哪？其實就是「規模」兩個字。

一個學生網站用現成的open source系統拼接起來，通常也就在期末demo時可以「自己一個人」操作一下，證明基本功能都能運作就結束了。好一點的專案可能還會真的放上線給同學們用，使用者就開始增加，可能到10人或20人。這時應該還不是大問題，因為這十幾個人很少會同時間使用，所以在不同時間點看，同時間的使用者其實還是一個人。

但如果真的有人在用，時間一長累積的資料就會變多，系統的短處就會開始暴露出來。例如說，小專案的資料庫都沒有適當的索引，在資料量小時不會感覺到有什麼問題。但當系統累積的文章變多，就會發現每次取出文章列表時就得要掃過整個資料庫。隨著累積的文章越多，這個列表速度就越慢。隨著使用者變多，這個問題也會跟著變糟。

如果使用者再變多一點，到了幾百幾千人的規模，同時上線的人數也會變多。這時網站平常就不再是同時只有一個人在使用的狀態了，如果程式沒設計好，同時有多人在讀寫資料很容易就會造成race condition，像是有些資料莫名的消失或是被覆寫之類的問題就可能會一直跑出來。

— 以上內容引用自原文 —

系統的規模，決定了實作的複雜度，隨著規模越大，分工越專精，系統複雜度呈現指數成長。

軟體工程師的修煉與成長 (3) —OnCall 的挑戰

Oncall 是現代軟體的標配

oncall是現代軟體公司的標配。很多網路服務看起來很穩定，24小時都不間斷，其實背後都有無數個工程師得24小時oncall。

嚴格的 SLA 所帶來的時間壓力

oncall最可怕的是時間壓力。通常面對business的軟體系統都會有嚴格的SLA (Service Level Agreement)，會有個合約定義好系統至少要有多久的uptime。如果沒有達到SLA，公司需要付出一定的賠償金。

維護 Production 系統的經驗

沒有經驗或是實力不夠時很難看出問題的全貌。

建立好的 oncall 制度

oncall很困難其實根源不完全在於我自己的知識和經驗不足，而是團隊的開發流程和制度還沒有把這件事變得夠簡單。

—以上內容引用自原文 —

這邊小城哥正好有個熱騰騰的演講完善這一部分的知識
SRE Conference 2022 — How to Build a Healthy On-Call Culture

軟體工程師的修煉與成長 (4) — Product vs Infrastructure

小心別讓新人變成一個 silo

現在我在團隊裡有新人加入時，都要特別小心，不要讓他們自己變成一個silo，只做自己的事卻不跟別人溝通合作。尤其是L3或L4的人，如果都沒有跟別人合作，會少掉很多成長的機會，也會跟團隊失去連結，最後很容易就會失去信心或熱情而離開。

原來缺少的是 Technical Leverage

在好幾年後，我才了解我當初缺少的是「technical leverage」，也就是一個工程師有多容易可以透過技術能力產生影響力。簡單說，如果你寫的程式被越多工程師使用，你的technical leverage就越大，你就越容易透過好的設計或實作讓其他工程師變得更有效率或是做一些他們本來做不到的事。

— 以上內容引用自原文 —

做產品還是做 Infrastructure ？

做產品較貼近使用者，然而做 Infrastructure 可能增加 Technical Leverage，沒有固定的答案。

軟體工程師的修煉與成長 (5) — 1:1該談什麼才能讓職涯起飛?

1:1的話題

和manager定期1:1是現代公司都有的流程之一，但大部分人其實都沒想過在這段時間內應該要談什麼話題。

如果不主動，預設就是交給manager來主導話題，所以很常就是「閒聊一下最近的生活」還有「報告最近在做的工作和進度」就沒了。但經過我的直球對決經驗後，我發現我以前犯的最大錯誤就是等到績效考核時才談績效和職涯發展的事情。這樣完全沒有好好利用1:1的時間，浪費了很多機會

最重要的莫過於定期跟manager談職涯的發展

想要什麼一定要直接說，不要有「我默默做好我的工作一定會得到賞識」的心態。

— 以上內容引用自原文 —

軟體工程師的修煉與成長 (6) — 換團隊 x 2

Tech Lead (TL)

TL的scope可大可小，最小的就是專案層級，只負責專案內的技術方向和細節，可以決定要怎麼設計系統、採用什麼技術、還有整體需要的時間。因為scope是在專案內，所以這個TL的生命週期也是到專案結束而已。

如果是L6的工程師（也就是一般的staff engineer等級）做TL，大概就是負責一個團隊(5–10人)的技術方面的方向、決策、還有願景。

Engineer Manager (EM)

值得一提的是，大公司的TL是不管人的，而是把people management完全交給EM負責。所以TL要能「領導」一個團隊，完全得靠influence來推動團隊往他想要的方向前進。

Tech Lead Manager (TLM)

TLM是一個吃力不討好的工作，又管人又管技術很容易會兩邊都做不好，所以TLM的用處就只是讓TL試試水溫，可以有兩三個report來體驗一下EM的日常。如果真的想往管理方面走，大多做個一年就會轉成EM，或是就轉回IC只做TL。

— 以上內容引用自原文 —

軟體工程師的修煉與成長 (7) — 如何突破資深工程師的天花板

第一個抉擇 Manager or Individual Contributor?

前面的文章提過，L5資深工程師是大部分公司的「終端等級」。在這個等級以後，即使年資一直增加，也不會自動就往上升，如果沒有超過這個等級的impact，就會一直停在這。

第二個抉擇 Manager or Leader

在矽谷的公司裡，manager和leader是兩個分開的概念。Manager指的是people manager，負責「管人」，在工程團隊中就是EM扮演這個角色。而leader則是於幫團隊指引出方向，帶著團隊往那個方向前進的人，工程團隊中大多是Tech Lead (TL) 在扮演這個角色。

— 以上內容引用自原文 —

還有幾項，例如提升領導力也是十分的重要。提升溝通能力、發現問題，增加自己在組織中的 Impact，擴展爆炸半徑。

軟體工程師的修煉與成長 (8) — 讓自己可以被取代

先做到，再讓自己可以被取代，保持成長心態。這篇高度很高，要先讓自己足夠突出，然後再把自己可以被取代。

軟體工程師的修煉與成長 (9) — 選擇適合自己的公司

選擇的維度

以我自己來說，選公司有幾個維度是我會優先考慮的：「公司文化」、「個人的成長空間」、「薪資」。也有幾個是其他人覺得很重要但我不那麼重視的：「產業」、「公司未來的成長空間」、「tech stack」。

1. 公司文化

公司文化是我最看重的維度，因為這直接決定了「我每天在這工作會不會開心」。文化包含了公司內的同事如何合作（或是競爭），公司多重視員工的身心健康和工作外的生活，還有公司的價值觀。

2. 個人的成長空間 + 公司的成長空間

個人的成長是我看重的第二個維度，這個決定了「我在這家公司能待多久」。個人的成長空間是一個蠻難判斷的維度，要決定適不適合我通常會看這幾件事：

「要加入的團隊是不是自己想深耕的領域」（目前的適合程度）
「公司需要解決的問題有沒有足夠的挑戰」（深度）
「在公司內換團隊容不容易」（廣度）
「升職容不容易」（職涯的成長空間）。

3. 產業

產業不代表公司實際營運狀況，現在許多的新創嘗試切入，但大部分會失敗。所以與其看產業，不如看公司實際營運狀況。

4. Tech Stack

Tech Stack 是最不重要的東西之一，技術棧會隨著公司演變而改變。不管公司選了什麼 Tech Stack，技術會日新月異，工程師都得跟著學習與成長。

5. 薪資

跟大部分人一樣，薪水也是我選公司會優先考慮的項目之一。雖然不是最重要的，但如果差太多也不行。考慮薪水的主因是這可以看出「公司想要雇用什麼樣的工程師」。

— 以上內容摘要自原文 —

從各種角度頗析適合自己的公司，而非跟風別人說哪邊好就跟著走。筆記一些覺得很受用的地方

軟體工程師的修煉與成長 (10) — 四維的技術能力

深厚 CS 基礎的人 vs Bootcamp 速成工程師

有深厚CS基礎的人對比在bootcamp幾個月的速成工程師，最大的差別就在於對於這些「理論基礎」理解的深度。大學之所以不教表層的開發框架，就是因為像「作業系統」、「網路架構」、「分散式系統」等底層的技術和運作原理是所有表層技術的基石，不管上面的技術再怎麼更新，下面這幾層的原理其實都是一樣的。

— 引用自原文

心得

這一系列文章真的相當地精采，從來沒有人這麼有系統地分享矽谷頂級公司各職等需要具備的能力與心路歷程。

細讀一次之後，對於軟體工程有了不一樣的看法，並且對於職涯選擇、公司選擇等等，比較抓得到重點。如果自己撞牆應該要撞許久才會頓悟，感謝 vgod 用心撰寫這一系列文。

本文由 Luka Huang 授權轉載，原文連結

瀏覽 2,203 次