軟體工程師的修煉與成長 (1) — 小程序設計 → 軟體工程
源起
我在2008年時寫了「追求神乎其技的程式設計之道」這系列文章，當時我才剛到美國唸博士班，雖然有不少實習和在科技公司打工的經驗，但其實並沒有做過全職工程師。現在14年過去，我花了四年從博士班畢業，後來三年在波士頓創業，接著又到矽谷做了七年軟體工程師一直到現在。
當初神乎其技的程式設計之道這系列文章講了很多我在高中到大學這段時間學習寫程式的心路歷程，現在回頭看覺得很高興當初把這些事情都寫下來並分享出來。不只有很多人說這系列文章給他們很大的幫助，讓他們找到熱情和方向，而且也讓我可以在十多年後重新沉澱和再分享後續的經驗和心得。
我打算接下來開始寫一系列的新文章，名為「軟體工程師的修煉與成長」。如果說神乎其技系列是我作為學生的學習成長過程，這個新系列就是關於我成為軟體工程師全職工作後的修煉和成長過程，某種程度也可以看作是神乎其技的續篇。
和學生時期不同的是，因為公司內部有很多敏感或機密的資訊，所以細節不能講得太清楚。我會盡量用業界通用的語言和原則來描述，特定的人事物可能會忽略或是模糊帶過。
程式設計 → 軟體工程
我從國中自學程式開始，經過高中那段為了奧林匹亞瘋狂練習的時間，一直到後來在G社實習、在博士班做了一個還不少人用的open source軟體，我一直都對自己的「程式設計」能力感到很有信心。但後來到了矽谷，進入D社工作後，我才發現「寫程式」這件事，其實只是「軟體工程」中的一小部分。雖然我自己寫程式可以寫得很好，但在一個有上千個菁英工程師的公司中寫程式可是一件完全不同的事情。
對於一個剛從大學或碩士畢業的菜鳥工程師（以矽谷通用的工程師等級來說就是L3，初階工程師），能夠把想法轉為程式通常是唯一需要的「硬技能」。這時的L3工程師嚴格說來只能說是個程式設計師，基本要求是能夠完成軟體系統中已經定義好的一小部分功能，可能是前端介面上的一個互動流程、後端提供資料讀寫的一個API、或是內部使用的一個小工具。在這個等級的工程師也需要團隊裡比較資深的人帶領，才能知道團隊基本的溝通協作流程，以及「要在哪裡改程式」、「怎樣寫對於這個團隊來說才是好程式」、「怎麼在已經上線的系統裡debug」、還有「怎樣才不會把別人寫的程式搞壞」。
程式設計師和軟體工程師最大的不同也就在這個「個人」vs「團隊」的部分。
從學生時期開始，我一直都很會自己寫程式，只要我有想法，沒有寫不出來的程式。即使學校有專案是需要跟別人合作的，我們也會一開始就找幾個地方把程式切開，讓大家可以分頭獨立做事。例如，一個人各自分頭做一個功能，做完再接起來；或是一個人負責前端介面，一個人負責後端，把API定好後就完全不互相干涉；甚至極端點還有一個人寫全部程式，另一個人做報告XD
雖然我在G社實習過兩次，但兩次我都是在做獨立的新專案，並沒有跟自己mentor以外的人或是其他部分的系統有太多接觸。當時我並沒有覺得這樣有什麼不好，甚至覺得可以做一些新東西很有趣，但現在想想這樣也同樣失去了真正瞭解合作開發這種大規模系統的機會。
後來我進入D社後，才真正了解到一個大規模的軟體工程團隊是什麼樣子。在2015時，D社大約有一千人左右，軟體工程師應該有三四百人，整個code base有8年的歷史。當時我進去時是L4，比剛畢業的新人高一級，但還不到資深(L5)。L4的基本要求是能跟自己所在的團隊合作，可以獨立完成產品中的feature還有解決相關的問題，甚至還要能mentor L3的工程師或是實習生。
我剛開始時沒有什麼特別想專精的領域，比較偏好當個generalist，所以我的角色就是個做產品的full-stack engineer，web前後端都做。寫程式做產品的feature對我來說並不難，我加入後幾個星期就能獨立作業開始有產出了。我有一定的自由度可以嘗試自己想的新idea，但除了做自己負責的部分外，其實我跟這個團隊並沒有融入得很好。我不太關心別人在做什麼，只想著要怎麼把自己的東西做好，總覺得能夠很快把東西做出來推出去給用戶就好了。
現在回頭看，這時候的我，沒有在大型公司的工作經驗，不太知道怎麼跟團隊甚至公司裡其他人合作。在這個時期，軟體工程對我來說大多是書上能學到的硬知識，大概是開發流程（agile、SCRUM）、系統架構設計、Design Patterns、UML這類的東西。簡單的說，除了技術能力外，我在其他面向的軟能力（溝通、領導、協作、培養新人、建立團隊文化等等）其實弱到跟L3沒兩樣，充其量只能說是個不錯的程式設計師，可以獨立作業，但完全不懂大型軟體工程是怎麼回事。
軟體工程是團隊接力馬拉松
一個人寫程式可以很自由，想怎麼寫都行。大多數時候也沒有什麼歷史包袱，如果寫久了覺得程式變得太難維護，隨時可以打掉重來。學生時代的程式更是簡單，沒有真正的使用者，更不用考慮日後維護，程式的壽命只有短短幾個星期最多幾個月，課程一但結束就等於進入墳墓了。
在軟體公司裡工作和上百上千人一起合作寫程式就完全不是這樣了。大型軟體工程比較像是一群人一起接力跑以「年」在計算的馬拉松，這群人會一直變化，有人來也會有人走，一但起跑就不能停下來。除了一直跑以外，還要一邊找目標找方向，因為沒有人知道終點在哪裡。一群人得找方法互相合作，讓大家往同樣的方向前進，中間還要不斷解決各式各樣的問題。幸運的是，軟體工程師的特技是能夠一邊跑一邊製造工具，成功的公司大多是做出車子或飛機讓整個團隊都移動的更快。只是，這些工具也讓軟體工程變得更難更複雜。加入一家已經有規模的公司意味著直接跳上了已經在空中的飛機，只會自己跑步是沒用的，而是得在空中一邊和其他人合作解決各種危機，一邊幫載著整個團隊的飛機升級引擎，才能讓飛機飛得快又久。
軟體工程難的地方就在這是個「持續很久的團體活動」。一個人做得很好的效益是很低的，高等級的工程師的價值不在於能比初級工程師寫程式寫得更快或更好（事實上，越高等級的工程師花在寫程式上的時間通常越少），而是能把周圍人的產出都一起變快變好。如果把這樣的影響力想像成一個炸彈，這個影響力的範圍就是「爆炸半徑」。
L3工程師大多只要做好自己被分配到的部分，能不把系統的其他部分搞垮其實就很不錯了，但這樣的爆炸半徑只有自己一個人。L4可以透過mentor新人或實習生的方式多教一兩個人，但這樣的爆炸半徑也就只多了那一兩個人。L5就是一般所謂的資深工程師了，到了這個層級，不是把自己的程式寫好就好，而是要能繼續擴大爆炸半徑，負責領導需要3、4個人一起合作的小專案，整個時程也會拉長到幾個季度：從初始的設計開始、到把設計分割成比較小又具體的實作任務，實作完後要協調上線的過程和之後的監看、維護。
剛加入D社的我實在太天真，完全沒理解到每個等級的差異和期待。（當時公司也沒有明確說明每個等級的差別是什麼，直到幾年後公司更成熟才有正式文件讓人參考。）過了一年後的績效考核，我還覺得自己一年來做了很多事，表現應該不錯吧，於是就在給自己的評分上選了4分 ”exceed expectation” （表現超過預期）。
當然， 自己的表現從來都不是自己說了算。老闆只給了3分 ”meet expectation” （表現符合預期，不好也不壞），還跟我解釋說4和4+只有非常少的人會得到，大部分的人都是3，要我別放在心上。當然，天真的我還真的沒想太多，就這樣算了，然後回頭繼續做一樣的事…。
(待續)
本文由 vgod’s blog 授權轉載，原文連結
瀏覽 2,052 次
