我升職了！入職微軟10個月的省思(五條建議)
今天在打文章的當下已經是我入職微軟正職的第十個月了，很高興在最近與主管的 1 on 1 會議中，拿到了今八月的升職許可。每個月我都會整理當月的省思跟學習記錄，趁著這次小升職來統合一下我做對了哪些，我做錯了哪些，還有那些我希望我早點知道的事情，不僅是對入職這些日子的整理，也是對之後新人的一些啟發。
首先這次的升職並不是如同 Google L4 到 L5 或是 Mete E3 到 E4 那樣跨越的升職，由於微軟分級比較細緻，這次的升職比較像是 L4 晉升到 L4.5 的感覺。
Look through the wiki first before asking questions
剛剛入職的時候很多東西都不懂，需要一段時的學習，比如：要去哪裡申 permission、engineer design doc 要怎麼寫、design spec sig off 要怎麼做等等很多事情，可以很大也可以很小。對於不懂的事情很多時候我們都會先詢問自己的 mentor 或是 onboarding buddy，但是時間久了也會對對方造成困擾，我認為最佳解應該是詢問組上有沒有 wiki document 可以參考，很多時候大家會把一些知識點統一寫在組的 wiki，最好從那邊下手。
如果很幸運剛好組上有記錄下來，great！你省下了很多麻煩別人解答的時間，如果不幸組上並沒有相關知識點的記載，another great！你多了一個剛入職時就能 contribute 的機會：幫忙寫下那些知識點。記下這些東西看似有點無聊，但是你不僅成了那篇文章的 owner，也因此更明白當初要問的問題的答案，對於你抑或是整個大組的進步是非常有幫助的！
Always thinking before doing the development
對於很多剛入職的人來說，接到任務後緊接著去執行看起來是一個非常合理的流程與決定。事實上，我認為更好的選擇其實是在接到任務與執行間多加入一個思考的步驟，多了這些步驟可以大大的提升你對於這些任務的認知、任務完成後的成就感與新人最重要的：減少後來不必要的重做時間。
我認為思考這個步驟可以詢問自己的問題有但不僅於此：
- Why we need this task?
- What are the problems we expected to solve?
- What is the business impact?
- Does this meet the company standard and requirement?
我們組的任務通常是 PM(product manager)，提出後經過層層把關檢核來到我們手上，”通常理論上”是沒有什麼爭議的項目，我們通常只需要好好地執行即可。但如果你有時間與興致去了解我們為什麼需要這些項目、這些項目是要去解決什麼問題或是對目前的產品有什麼影響，這會對你對於目前的工作內容有著意義上的補充，還可以從中了解到一些制定項目跟設計產品的邏輯，很多人搬磚(在大公司底下做事)了一陣子會有的疲勞感，或是沒有進步的感覺都很大概率會因為你多了些思考的舉動而消失。
但其實我認為最直觀也最第一時間受用的其實是能減少出錯而重來的不必要的時間浪費，你若能好好的思考前兩個問題，那我認為在 implement 的過程上會比較清楚這個任務的目標與期待，我自己初期拿到任務馬上行時，確實經歷過幾次做了好一大半卻發現有點偏題的情況，而需要花費幾乎相同的時間重頭來過，這些都是可以避免的，也會讓你看起來比較成熟，比較謹慎。
Always exam our assumptions
我們常常對於事物都有著許多預設與假定，不管是我們自己有意識到的或是沒有意識到的，我認為我們需要常常得去檢視自己的這些預設，去省思這些假定，如同銜接傷一個建議，這是一個相對廣義的延伸，拿到任務時我們常常假定它是有用的，事實上這個假定卻是需要被檢視的，你或許能從驗證的過程中發現其實我們組並不需要這個任務而達到節省時間。
對於報告時，我們時常假設大家都聽得懂我們說的那些術語或是簡稱，但很多時候 audience 並不一定那麼了解我嗎的產品，說的自認再好，可能也會因為他們在小地方不了解而對於你的報告大打折扣。
對於目前公司的開發工具、制定的規矩、參加 standup 的時間大大小小的東西，如果有機會一定要去反思去質疑既有的種種假設，即便不會不同，你卻能了解他的背後邏輯，如果你覺得不合理，說不定大家都有著相同的疑問，提出來讓，能讓你從中突起，出現在大家的視野中。
Frequently review others code
code review 在當今現代軟體科技公司中，應該是相對常見的存在，善用它，你將能進步的突飛猛進，也能在組上有存在感。
對於技術這塊，我認為能夠最大幅度提升能力的方法，應該就是頻繁地去 review others code。我也聽過別人這樣說過，直到我堅持頻繁地去 review 一段時間後回頭發現自己的水平有著肉眼可見的飛速成長。
能夠飛速成長的底層邏輯是：
很多東西的應用與解決方式你可能本來都不知道，透過看別人的程式碼你能實現快速的學習。比起之後遇到你可能還要在網上搜尋好久，邊 review 邊學習就是最好的方式。 你看到新的名詞、新的 library 或是新的 packages 時，通常會自己上網學習其相關知識點，一個由點擴成線在到面的過程，有時這樣反覆的學習你會越來越老練，對之後的 review 也會有所提升 在 comment 欄中與同事的提問、討論中會提升自己的思維視野或是本來沒有想過的點。
Advocate your work and find some customers for it
這個是我近期學到的點，對於主管交代的任務，什麼時候叫做完成是一個看似簡單，一般新手容易誤會的點。曾經我以為，程式碼完成了叫完成，ship 到了 prodution 叫完成，事實上這些只能說是達標式的完成。
比如你拿到建立一個系統的任務，系統建立完了的當下並不能叫完成，你還需要：
告知你的組員們你完成了這項任務，你可以給他們一寫 demo，你可以邀請其他組的人來參加會議秀給他們看，說不定不只 benefit 你們組，也能 benefit 其他組，這個主是為你的成果打廣告，這點非常重要，默默的完成任務並不會凸顯你的價值，實作與宣傳都是不可或缺的東西。 你需要找到使用者來用看看，其實跟第一點類似，你弄了一個 feature，說不定其他組覺得不錯，用的人開始多起來，能擴大他的影響。 其實上述的邏輯就是，你需要幫你的項目找到他的價值，並且將它發揚光大，empower other、contribute to others success 都是新人非常容易忽略的點，這個也能為你在主管心中，其他組員心中留下深刻的印象。
自己總結與思考了一下，覺得上述五點是我認為能夠使我在入職過程中頻頻受到主管認可，最後在我詢問升職細節後，主管主動提出我的升職許可的原因。曾經走過許多彎路的總結，也希望能對看到這篇文章的你有所幫助與啟發。
如果覺得小有收穫，不要記得按鼓掌喔：）