Member-only story
軟體工程師的修煉與成長 (4) — Product vs Infrastructure
做產品的日子
新手工程師要選哪個領域開始一直是個萬年問題。前端還是後端？web還是mobile？產品還是基礎建設？
我一開始進D社有很大一部分的原因是有可以做一個全新產品的機會。在產品還沒成形前，還有很多創新和嘗試的空間。所以，剛開始時我算是個產品工程師，web的前後端都做。
做產品的好處是離使用者很近，在產品上做的改變可以馬上被看到，對使用者的影響很直接。但我也不想只做前端，因為在公司裡做產品，前端的使用者流程和體驗大部分都有專門的設計師在負責。他們有更多時間可以好好思考和琢磨使用者體驗，前端工程師雖然也可以提點子和想法，但比起專業度的確還是不如設計師。
於是我當時就這樣前後端都做，要做新功能時我可以只靠自己一個人就把整個功能交出去。雖然這樣可以做得很快，但我也因此少了很多跟別人合作的機會。當時我和我的manager都沒有察覺這是個問題，所以我就一直這樣持續了好一段時間。但現在想想，這雖然得到了短期的效率，可是卻犧牲了促進團隊知識分享和交流的機會。
現在我在團隊裡有新人加入時，都要特別小心，不要讓他們自己變成一個silo，只做自己的事卻不跟別人溝通合作。尤其是L3或L4的人，如果都沒有跟別人合作，會少掉很多成長的機會，也會跟團隊失去連結，最後很容易就會失去信心或熱情而離開。
就這樣做了一年後，雖然我東做西做了很多東西，但卻都不是多重要的部分。團隊中比較資深的人，都可以很容易看得出來他們對系統的一大部分都有很強的ownership。簡單的說，如果有人對某個系統有問題，馬上就會想到那個人 (go-to person)。
這種ownership以及變成某個領域的go-to person是需要花時間培養和建立名聲的。我在第一年做得太雜，雖然做了一些自己覺得有趣的專案，但我做的東西跟別人的交集太少，沒有什麼在底層或是核心的組件是可以被別人重複使用的。這讓我很難在別人有問題時幫助他們，別人有問題時也不太會想到我。
Technical Leverage
在好幾年後，我才了解我當初缺少的是「technical leverage」，也就是一個工程師有多容易可以透過技術能力產生影響力。簡單說，如果你寫的程式被越多工程師使用，你的technical leverage就越大，你就越容易透過好的設計或實作讓其他工程師變得更有效率或是做一些他們本來做不到的事。
在一個產品或系統中，通常越上層的部分就有越多的商業邏輯和特定的目的，像是實現特定的產品功能或使用者介面。這部分是很難重複使用的，需要工程師和設計師一個一個的設計和實作出來。但如果往下走，越下層就越會一般化，可以被多個不同的上層功能重複使用。
一般產品的frontend在最上層，第二層會有一些產品專用的API endpoints，也就是一般常說的backend。比較大一點的產品或公司，下面還會多一層通用的backend或platform服務，處理使用者帳號、權限管理、檔案/文件等會被不同backend共用的data entity。
這些entity不管上層的商業邏輯怎麼設計都一定會有，而且還要有大量的公用函式或服務來處理entity的基本操作(CRUD)和他們之間的交互動作。這些公用的服務是可以被不同產品功能重複利用的，而做這些部分的工程師自然也有比較高的technical leverage，可以做一點改變就影響到很多上層的工程師或團隊。
如果走到了更下層，也就是基礎建設層(infrastructure)。這一層做的事情就更抽象和一般化了，例如建立資料庫系統本身（但不管裡面存什麼資料）、網路架構、資料倉儲系統等等。這類的基礎建設有的是為了某個產品才特別做的，但也有些是跟產品無關的，也就是說他們可以服務多個產品，也跟單一產品的成敗沒有直接的關係。
這一層的工程師有最高的technical leverage，一個微小的改進（例如說改進資料庫的讀寫效率）都可以讓上面所有的產品和使用者受益。（但出錯時也很容易讓整個產品都掛掉…。）可是，這層也有相對的缺點。做基礎建設的人的能見度通常比較低，合作的對象大概都是在同一層或上一層的工程師，非工程師基本上都不會知道基礎建設層在幹嘛。而且，如果不是有特別需求的公司（規模特別大、或是需要對某一方面做特別的最佳化），這一層因為是最一般化的，也就最容易被取代或外包給其他公司或第三方服務（像AWS或GCP）。
對於工程師來說要選哪一層發展，並沒有一個標準答案。在上層發展雖然technical leverage比較低，但相對的有比較好的product leverage，比較有機會影響product走向。如果未來想轉職成product manager或是累積跨領域(product, design, marketing, etc)合作經驗的人，在產品開發的團隊裡會比較有利。
我剛進D社時覺得基礎建設離產品的使用者太遠了，做的事情經過好幾層才會對使用者有影響，所以覺得這樣的影響力不如直接做產品來得大，就沒有想往這方面發展。但後來在公司裡接觸了各種不同的團隊，學了更多事以後，我發現我似乎比較適合往下層走。一方面是我只想專注在engineering，所以越底層的工作規模越大越有挑戰性。另一方面是，產品層很多的工作是實作特定的商業邏輯，未來換工作或換團隊的話，這些知識很大程度是沒辦法轉移的。
最後，我還發現公司裡的Staff Engineer（當時D社工程師的最高等級）很大一部分都是做基礎建設的(!)，也就是說做產品的想產生足夠大的影響力來升職似乎比較困難….。
（待續）
