標題: 「Facebook 內的文化特別之處」
類別: usecase
連結: https://chinese.catchen.me/2022/02/unique-engineering-culture-of-facebook.html

作者作為一個 Meta 工作七年的員工，分享了一些認為 Facebook 頗有特色的文化，這些特色文化並沒有辦法直接斷言是好是壞，一切都是看用什麼角度去看待。

工程師對產品結果負責

年度績效評估時要如何去評估一個工程師的績效一直都是個不簡單的問題，作者提到對於 Meta 內部的高級工程師(不確定正確級別代號是什麼)來說，其績效並不是單單的只去看技術用的好不好，程式寫的好不好
更多的反而是這個產品是否有真正的商業成長結果。

作者認為這種鼓勵從下而上解決問題的思路能夠讓產品的發展更佳有效率與有意義，舉例來說
假如今天工程師的績效是完全基於技術方面的呈現，而專案負責人(PM)的績效可能是該專案對於使用者的黏著度，兩者績效不一致的情況下很容易發展出不同的開發與演進策略
工程師為了達到自己的績效其發展的路線就不一定可以為產品帶來更好的使用者黏著度，反之亦然，為產品帶來更好使用者黏著度的改善並不一定可以讓工程師看到很好的表現績效。

但是一旦當工程師與 PM 的目標一致，整體的合作就會更加融洽也目標，這也是為什麼 Meta 的工程師非常了解自己產品的指標跟數據，還會花時間去分析產品數據與使用者分析報告，透過自己的理解來思考到底要怎麼去改善產品的方向，而不是完全等待 PM 發號司令。

基礎架構被視為一個產品販售

Meta 內部的基礎架構某程度也被視為是一個產品，公司內的其他工程團隊則是該產品的潛在用戶，所以開發該產品的團隊本身也要努力的去推銷這個產品，去說服為什麼要使用這個架構，使用這個架構能夠帶來什麼樣的好處。
作者以早期的 Reat, React Native 為範例，早期該產品於公司內推廣也是四處碰壁，並非外部所想像的一推廣就廣受歡迎與嘗試。

由於基礎架構被視作是產品，所以如果其「商業」表現不如預期的話，該專案也是會被砍掉的，這類型的模式搭配上述的概念其實非常有趣

所有的專案都想要長期存活都必須要證明其有價值，就算是內部架構也要證明其對內部其他工程團隊有價值
這種方式也降低了「只專注技術而不考慮使用者需求的」的開發方式，這讓我想到大家最愛講的「Service Mesh」…. 帶來什麼效應不確定，但是很潮就是享用…，

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程，歡迎有興趣的人參考並分享，裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外，歡迎按讚加入我個人的粉絲專頁，裡面會定期分享各式各樣的文章，有的是翻譯文章，也有部分是原創文章，主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來，裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力