Career

軟體工程師

前言

許多人會把目光聚焦在美國工程師優渥的待遇和誇張的福利。嗯，是真的！在 Amazon 以外的公司挺常見的。社群媒體有大把的貼文帶給大眾如此印象。老實說，我不喜歡這樣的貼文，因為那些貼文過度放大美好的部分，進而讓外界的人忽略這裡的工程師們也只是一般的上班族，他們在自己的工作崗位上也有許多需要克服的難題。

2021十月開始，我升職成為 Amazon 的中階軟體工程師。兩年來的磨練，我從原本新進菜鳥變成團隊裡的一份主力。我回想其中的過程，在 Amazon 經驗確實讓我稍微貼近一點工作究竟是怎麼一回事。這篇網誌我會一一講述以下面向：

  • New Grad 困境
  • High Level Idea
  • 開會
  • 良善的意圖
  • 寫作

New Grad 困境

第一份工作很艱辛，不一定因為工作本身很困難，而可能是因為做事方法不對。學生時期我傾向於自己搜集資料、自己發想、自己實作，最後完成一份作業。然而，進入業界後我發現使用這套方法不適用。

我所在的組負責一個成熟的產品。該產品的系統架構、商業邏輯、實作細節、維護工具、測試框架的複雜程度遠超乎一個人能夠摸索的極限。我敢說任何人即便他再聰明，也不可能獨自熟悉我們組的產品。我獨自 ramp up 所有知識的下場是 burn out。進入 Amazon 的前六個月，我一個人花時間獨自作業完成一些小事。每天很早上班，很晚下班，回到家加班，卻無法順利解決主管交付我的任務。我想向身邊的同事求助，卻開口不知道問什麼。我勞心勞力，卻不見改善。

Mentor 很重要。如果你有機會帶領一個 new grad，他入職前期有沒有辦法施展拳腳全看你們合作得好或壞。好的 mentor 可以帶你認識組裡的環境、產品架構、誰負責什麼。回顧那六個月，我和我的 mentor 合作不順利。他人在西雅圖忙碌，而我也不知道如何跟他開口尋求幫助。當時，我的主管多指派一位工程師帶我，我也沒有起色。我後來才知道這個多指派帶我的人一直以來都不在狀況內。他在其他資深工程師眼中，不應該被招聘進來。也就是說我的前六個月，我什麼都不懂。自家產品、組的運作方式、主管的期待、同事負責的項目、設計和提案、撰寫程式碼、工具的使用，你想得到或你想不到的我都不清楚。腦袋中只有破碎凌亂的知識，沒有一個清晰的架構。

回饋是改善的契機。沒多久組內 reorg，我被分派給一個新的主管 Cathy。Cathy 交接我的時候向許多人打聽我的情況。前主管說我總是獨自作業，卻不知道我究竟完成了什麼。跟我接觸的 principle engineer 說不確定我是否可以用英文溝通。我的 mentor 說我設計思維堪慮。現在回想起來。只要當時 Cathy 想放棄我，我一定捲舖蓋走人。可是 Cathy 沒有，我的同事也沒有，整個組都沒有。我很慶幸有機會去改變。與 Cathy 第一次的 1-1 會議，我們討論該如何改善我的困境。

那次的會議上，我與 Cathy 討論解決方案。Cathy 建議我多閱讀組裡資深工程師們撰寫的設計文件，從中學習用字以及設計理念。同時他也建議我多去參加各種會議讓我的大腦熟悉英語字彙的發音和用字遣詞，然後試著了解講者內容，最後提出一兩個問題。我這邊則提出，我得更完善的背景知識了解組裡產品，也需要重新檢視撰寫程式的能力。我打算多看一點書籍幫助自己建立起 Linux， micro service， 和 design pattern 的概念。我們約好每兩週的 1-1 匯報進步的過程。

這個模式運作兩個月，我的焦慮逐漸減輕。我花了時間去了解我們的產品，去了解有什麼功能，去了解我們的客戶是怎麼使用我們的產品，以及去了解背後支撐這些功能的系統是誰設計，還有產品系統大致的輪廓。我之後找到一位同樣在 Cathy 底下資深工程師 Siva 當作我的另一個的 mentor。他負責許多組裡使用的測試工具，算是與組裡產品一起成長的人。我請他引導我做一個專案，也因為完成這個專案讓我總算建立好足夠的知識庫在組裡站穩腳步。

回顧這個過程，讓我陷入 new grad 困境的其實是學生時代的學習習慣。獨自作業，獨自思考，然後完成任務。現實工作環境中，這套方法無法帶我完成工作，因為我能接觸到的資訊一定不齊全，公司內部的文件也不一定隨時間更新。未知的訊息仰賴開口詢問身邊的人，而問出一個合理的問題則需要仰賴一定程度的背景知識。那些背景知識或是 high-level picture 是身為新進員工應該主動去確認，而我當時沒有意識到這點，所以痛苦了六個月。

如果你們也碰上像我一樣的 new grad 困境，我建議一些方法幫助你融入環境。有些是我自己的經驗，也有些是我觀察到同事們的做法，如下：

  • 當自己是客戶，使用自家產品。去了解自家產品的 input 和 output。
  • 每天和 2-3 位同個ㄧ個 org 的同事或主管約 30 分鐘 1-1 了解他們在組裡做了什麼、正在做什麼，組裡有什麼樣的問題。
  • 寫 ramp up wiki，系統性建立起組內需要的知識。
  • 尋找一個跟你在同一個辦公室且資深工程師當 mentor，完成一個小 project。

High Level Idea

人最容易了解事情的方式是什麼？先給你一個時空背景，再給你一個目的，最後告訴你解決方式大致輪廓。嗯？這聽起來就很像計算機概論，是一個什麼都講一點，卻又什麼都講不清的課程。

High level idea 的精神是給出你想傳達事情的範圍和輪廓。掌握了輪廓後，補足細節知識會變得更容易。我舉一個例子，你們可以感受到有無 High level idea 的差別。

這場展覽裡有企鵝、猴子、狗、貓、螞蟻、老虎、北極熊、長頸鹿、螃蟹、水母化石、鯨魚、鯊魚、海龜、烏龜、猛馬象、暴龍骨頭、三葉蟲化石、劍指虎牙齒、穿山甲、豹、河馬、犀牛、鴕鳥、鱷魚、水母、蜉蝣、帝王蟹、大閘蟹、大西洋鮭魚、阿拉斯加鱈魚、海星、河豚、海獅、獅子、鰻魚、烏魚、雞、豬、牛、羊、兔……。

看完上面的名稱，你是不是知道展覽似乎有某種用意卻又不太肯定。甚至你可能想爆出りしれ供さ小的字眼。不過呢，如果我加上這下面這句在這些名稱的最前方。

因應氣候變遷，展覽裡展示了冰河時期至今海陸生物的動物或化石，讓大家了解不同時期生物的樣貌。

接著你重複閱讀上面名稱，你的大腦是不是會自動歸類這些名稱到一個包括冰河時代、現代、陸生、和海生的四象限圖中呢？於是這些雜亂無章的名稱，變得比剛才多了一點 sense。

這就是掌握 high level idea 的好處。工作上和同事溝通時，同事不一定知道你在做什麼。你需要為他建構一些背景知識以及目的並且提供輪廓，再從輪廓中補足必要的細節，帶著同事了解你遇到的挑戰以及你需要獲得什麼幫助。

High level idea 尤其是在提案時更重要。同組的同事間彼此會略知ㄧ二，可是提案的對象通常會是高階主管、review 的人可能是 principle engineer。他們不一定有提案人腦海中的背景知識和提案的前後關係。失去 high level idea 那些 reviewer 對提案重點無從了解。

如何從別人身上挖掘 high level idea 也是一門學問。我建議「撥洋蔥」方法，由外而內了解。先了解背景知識，從知道問題情境下手。再來將你想了解的系統當作一個黑盒子，用 input-output 的概念定下系統的邊界。然後打開這個黑盒子逐步了解內部有什麼元件、用什麼方法實現、擴展性、可用性……等，逐一檢視。

開會

開會時交換訊息是希望大家都能在同一個步調上行動，有了相同的步調才容易做出大家都滿意的決策。Working as a team and being on the same page.

很多新人會有想法，也有十分的行動力。他們急著想證明自己多會寫程式，毫不猶豫陷入
程式碼的世界修修改改，然後送出一份 code review。你猜怎麼了？沒人 review 他的 code change，進度停擺。新人一個人專注做事，十分危險。他們很容易和組裡的運作方向漸行漸遠。

通常新人的目的沒有不對，只是進行的方法可以更好。新人有想法，請去詢問資深工程師。資深工程師通常能夠站在較高的角度了解新人的想法然後分析可行性，並且提供工具支援。這個方式可以避免新人一頭栽進程式碼，接著陷入見樹不見林的泥沼中，或是重複造輪子浪費精力。

在資深工程師的指引下，新人能夠有較完善的進行的方向。這時候新人可以開會給出提案，讓更多人檢視計畫是否可行。過程中，新人得盡可能解決來自各方的提問和擔憂。當下答不出來的問題，也請記錄下來然後找正確的人 follow up。開會、回顧、修正、執行。這個過程會迭代無數次，過程中同事們也會對新人的計畫有一定的認識。每次迭代呈現成果時，同事們才不會感到唐突，那個成果也較容易被大家認可。

雖然大家不一定是一秒幾十萬的人，每個人的時間仍然寶貴。開會的人越多，所耗費的成本也越高。一個好的會議需要有明確的議程、紀錄、結論。主持會議的人需要確保所有人有效使用會議時間，讓大家在同一個步調上。如果有意見衝突僵持不下，選擇先跳過有時間再回頭。或是紀錄成 follow up 事項，下一次會議前與衝突雙方一起找到解法然後達成共識。

一個好的會議，出席者可以在開會前了解以下事項再好不過：

  • 目的
  • 討論主題
  • 主題的相關背景知識

出席者有了上面三個概念，他們能更主動參與會議中的討論。

開會最少是為了避免分歧，因為意見分歧的後果帶來的成本太高。舉個例子，假如你和另一半準備吃一頓豐盛的大餐慶祝，現在你們訂好了機票、旅館、地獄廚房的座位。這時對方突然說，他其實想吃遠在日本的二郎壽司，早就訂了機票、旅館、座位。這時你一定想，為什麼不早講……

良善的意圖

當有人提問、甚至質疑你的時候，我們先相信他們立意良善。

工作場合中，你的同事會向你提問，你的主管會要你交代進度。開會的時候，你的意見會被質疑。Performance review 的時候，和你共事過的人會給你 feedbacks。如果對方的意見讓你不舒服，第一時間我們不該先入為主認爲他們對我們有敵意，因為更多時候對方只是想知道狀況並且設法提供幫助，而非挑戰我們，而非讓我們難堪。

接受這一點後，再去看待工作環境中身邊同事對你提出的問題和字句，會變得比較能放寬心接受。就我而言，我都是盡心盡力處理工作上的挑戰和困難。對於質疑和提問，我只要說出實際狀況讓對方理解就行。若是對方點出實際的擔憂，正好是我們忽略的部分，那改善就好。我們不需要感到壓力或擔心我們的不足會使我們蒙受損失。

良善的意圖很重要。我們與身邊的同事們在同一艘船上，船上的每個人都希望把事情做好，因為唯有這樣做，所有人才能一同前進。我很幸運來到一個 Amazon 很好的組，這裡的人雖然嚴肅，卻十分友善。我可以相信身邊的人都是為了把事情做好，當提出他們反對的看法時，不是找理由攻擊我，而是想要幫助我。

要小心的是，每個人的工作環境都不同，所以善良的意圖不一定能適用於所有時空背景。 Amazon 也不是每一個組都很健康。政治鬥爭、爭功諉過，只要有人的地方多或少這些都會存在。如果你發現工作環境惡劣，身邊的同事糟糕，我們得收起對方善良的種天真的想法，趕快換環境比較實在。

寫作

精簡寫作很重要。不論是英文寫作還是中文寫作，我們都希望透過文字清楚表達想說明的概念然後推廣。如果寫作的能力欠佳，很大程度上會限制職涯發展。

這裡說的寫作並非文學創作，而是商業寫作。商業寫作的要點其實就是將想法簡潔扼要寫下來，省去冗詞贅字、不明確的形容詞，給出具體的數值，以及運用簡單的句型和例子清楚表達概念。如此一來，寫出來的文章讀者會更容易閱讀。

以下是 Amazon 寫作的一些小技巧，很基本，很實用：

除了這些小技巧外，對於我們將英文當成外語使用的人來說，文法和拼字更要注意。我還記得前一陣子我被一個資深工程師 Amit 叫去小聊關於我寫的文件有嚴重的文法錯誤。雖然我和他在同一組工作，他猜得出我想表達什麼，可是如果文件要交給其他 principle engineer 過目，會造成很大麻煩。他舉出我文章中關鍵的名詞會缺少 the、a 冠詞描述哪一個物件，動詞時態有時會不一致導致敘述前提不清晰，代名詞代表的主詞或受詞模糊容易產生歧義。

精簡寫作的重要性也體現在升職的時候。準備升職前，我已經準備好之前我經手過專案的簡介，也閱讀了 Amazon 內部升職的條件。我用這些資訊大致拼湊出一份大約 10 頁的筆記給我的 manager Kiran。儘管我使用的敘述方式遵守 STAR 原則，然而那份筆記並不精簡，Kiran 之後花了很多時間與我來回確認專案內容和交換意見。最後，他給出一份 6 頁的 promotion document。各項專案，在我的筆記上用不同章節敘述，而在那份 promotion document 裡被精簡成兩三句話交代。Hmm… interesting…

至今，我仍然在磨練精簡寫作技巧。另外，感謝元駿哥推薦的書：金字塔原理 知乎 - 干货：金字塔原理，看这一篇就够了！。

結語

兩年來工作上的磨練，讓我除了適應 Amazon 工作的文化外，也讓我看待工作以外的事變得宏觀。我知道

  • 學習的時候，我得先掌握 high-level idea
  • 一群人合作時，大家得 on the same page
  • 面對質疑時，先相信對方帶著 good intention

除了以上三點外，當然也有許多工作中培養且無法言明的習慣淺移默化進入我的生活。我覺得蠻好的，因為我知道這些習慣幫助我化解工作壓力。生活壓力和工作壓力也略有相同之處，像是時間管理和與人相處，它們也都能套用相似的解法。

這幾年來，我不斷地尋找一個適合的價值觀當作判斷是非對錯的原則。有趣的是，我發現善良的意圖對我來說似乎是一個可能的答案。儘管真實世界沒有什麼絕對的原則，每個人的標準都是浮動的光譜，可是我想用善良的意圖當作檢視以後遇上事情時的切入點，建立我評斷那些事情的參考點。