從零到工程師2：我的大廠爬梯之路
去年升職時我寫過一篇分享升職的經驗: 我升職了！入職微軟10個月的省思(五條建議)，今年由於公司預算緊缺，本來以為升職沒希望了，還是在新的一個財政年的第一季度成功升職成功，雖然比預期晚了三個月還是非常興奮。
利用年底有時間來整理這一年多來的心得與體悟，希望可以分享給想要在大廠晉升抑或是正在大廠裡尋求晉升的人一寫分享！這不是必勝法則，更多是我用心體會與精練後的經驗分享。
比起去年的五條建議，今年我歸納了三個原則，可以應用在多個場景的原則。
Define The Scope
Define scope可以用在多個地方：以寫design doc為例，當你在設計一個新design或是在對一個feature寫design doc時，如果沒有事前想好這分doc的scope，那你可能會花大多時間在不需要的的地方，或是在做doc review時面對排山倒海而來的問題不知所措。
在做doc review時，同事、主管或是其他參與review的其他人都很有可能會問出很多你本來沒想好的問題，如果未能在present你的doc之前想好你這份doc的scope，那你可能會對於很多問題回以沈默或是不清楚。大多時候，你比其他人都清楚這個feature/design是什麼，大概的成果樣子是什麼，或是你了解他的最終目的是什麼。
設定好scope可以幫助你減少收到一些不相干的feedback亦或是在對於不相干的問題時，給予一個明確的答案：「你的問題不在本次我present的design doc的範疇」。
很多時候我們都知道對於不相干的問題對於你的doc present有著嚴重的影響，有時會讓討論方向偏移，導至為了要回答其中一個問題而沒有機會讓你著重說明你想說的部分，防止討論主體的失焦是define scope的一個重要幫助，這能讓你的present更流暢，事前自己想清楚了scope是什麼時，更能幫助你focus在對的癥結點上。
Define Scope可以應用在多個場景上，不只是design doc。Code review也是一個常見的場景，很容易在給同事code review時收到類似景象：當能你調用到了某個函式，但卻收到希望你能改進那個函式的評論，或是你改了A其他人希望妳能”順便“幫忙改B，面對這種情況，可能導致那個PR越來越大，越容易出錯越難完成，容易不小心投入過多卻不能真實的反映在你的項目完成度上，這很多時候是一開始自己對於”這個” PR的scope不夠清楚而導致。(當然如果你很願意又有時間，don’t leave bad code behind是一個好的mindset！)
最後define好scope的重要性更體現在success metrics上，如果你尚不能define好一個task的scope，那怎麼能正確的量化你的success？也正是你已經事前設定好了scope，在做回顧或這量化時都會變得無比輕鬆與明確，這能有助於你展現自己完成任務的準確度與達成率，讓你的努力更鮮明地展現出來。
Take responsibility
隨著年資的增加這項的佔比應該會愈來越大、越來越重要。也是我認為區別初級與資深工程師的重要指標。當一個task交到你手上時，不管task的大小，如果能馬上擁有task的responsibility，我想應該會對你受益良多。
具體take responsibility是什麼呢，這個一時半會兒說不太清，如果你能回答以下問題或是沒有其中經驗那你應該是已經養成了這個習慣：
- 為什麼我們要做這個task呢？
- 這個task的影響是什麼？產生了什麼impact? 如果讓你建立它的下一步或是following task那會是什麼呢？
- 遇到了完成這個task後產生的bug，積極的處理，而不是說 大家code review時都同意了或是說這個方法我doc review時已經signoff了 (所以不會是我的問題)。
- 回答問題時從不說 「是某某A讓我這樣做的」、「當時大家都同意了」
我想大家(包括主管)應該不是討厭容易寫出bug或是造成bug的工程師(太離譜不在討論範圍 lol)但大家可能不是那麼喜歡推脫責任、不能倚靠的工程師同事。讓take responsibility 成為習慣能讓你從底層了解與學習，更能讓你樹立靠譜的形象，未來對於拿到好的、大的、有vision的任務會有一定的幫助。
Quantifying
「量化、數據化」這些詞我也是到了很後來才覺得重要，因為這是最直接明白的形式以下例子你應該就能明白。
當你在給別人PR comment時，盡量不要寫「我覺得這樣做不好」你應該寫「我覺得這樣不好因為XXX 然後這是我的POC(proof of concept)，其顯示這樣會有問題、改成YYY會更好」
人是直覺的動物但對於工作我們需要做到明確、沒有模糊空間，單單地表明這樣寫不好根本上就像沒有這個comment一樣，對方無法理解哪裡不好是一個最大的問題。若只寫 「我覺得這樣不好，請改這樣」也是不太合適的，大家都是工程師怎麼你的就是對的？最好說服的方法是：點出需要修改的地方，並給出真實的數據作證你的論點，它可以是一個顯而易見的後果，如果沒有如此顯而易見，給出自己嘗試過後的POC會是一個更好的方式。
當你在給主管反饋說自己會議時間太長，會議時間太多的時候，單單前面兩句話是不夠的，「多」只是一個形容詞，每個人的定義不同，主管也很難著手幫助你，更好的方法是 說出自己覺得會議太長會議太多的感受 並給出具體的一週會議時間 以及你都參與了那些會議，這些資料才能真正的使主管了解進而幫助你的問題。
以上都是如何使用「量化、數據化」的實際例子。「量化、數據化」的重要性體現在能更好的與同事們、與主管溝通，能讓你的提議更能被接受，減少中間來回回解釋的時間，也更能體現你的努力與貢獻，不埋頭苦做而忘了用其他人容易吸收的方式傳遞你的貢獻！
以上是我個人的小小心得，作為自身紀錄的同時，希望能幫助到其他人。
如果覺得小有收穫，不要記得按鼓掌喔！
