这里总结下自己 2022 年春季的季度总结，对照下自己 1 月初的 2021 年的总结和计划。

2022 Q1 总结

• 3 Offer, 6 Fail
• EAD
• Tax
• E to A

具体细节我就不写了，毕竟个人博客，我自己做自己的总结，不需要和外人道。

对照 2022 计划进度

• 入职，工作: E2A
• Tax Return: 04/10/2022
• Reviewer: 5 MICCAI
• XPCS: Focous!
• LeetCode: 543 -> 583
• Wegiths: 5 lbs

下一阶段计划

下一个阶段入职了新公司，可以说任重道远，所以列下自己的计划，提醒自己，警钟长鸣！

• 公司任务，升职加薪。现在的低 Level 工作是很容易的，还是要尽快适应，进入状态，出成果，出影响力，出计划。
• XPCS 快速完成
• 租房,预计 6 月中搬家，所以现在开始联系房子，签订合同。
• 6 月搬家
• Leetcode Hard 题目增加
• N?B 5月咨询

Check List:

• 入职，工作: E2A
• Tax Return: 04/10/2022
• Reviewer: 5 MICCAI
• XPCS: Focous!
• LeetCode: 543 -> 583
• Wegiths: 5 lbs
• House Renting
• Moving to TX
• N?E1?2 Info
• Family
• OPT Extension

有价值的事情，更多的在于产出性的工作，而不是支持性的工作。判断自己技术工作是否具有产出性，不妨问自己三个问题：事情无论大小

1）我是否简化了什么？ 2）我是否自动化了什么事？ 3）我是否对外输出了什么？ 一代表进步和创造力 二代表效率和生产力 三代表引领和影响力

一个很有用 职场新人入職快一年的升職省思與心得

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

對於很多剛入職的人來說，接到任務後緊接著去執行看起來是一個非常合理的流程與決定。

事實上，我認為更好的選擇其實是在接到任務與執行間多加入一個思考的步驟，多了這些步驟可以大大的提升你對於這些任務的認知、任務完成後的成就感與新人最重要的：減少後來不必要的重做時間。 我認為思考這個步驟可以詢問自己的問題有但不僅於此：

1. Why we need this task?
2. What are the problems we expected to solve?
3. What is the business impact?
4. 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 一段時間後回頭發現自己的水平有著肉眼可見的飛速成長。

能夠飛速成長的底層邏輯是：

1. 很多東西的應用與解決方式你可能本來都不知道，透過看別人的程式碼你能實現快速的學習。比起之後遇到你可能還要在網上搜尋好久，邊review邊學習就是最好的方式。
2. 你看到新的名詞、新的library或是新的packages時，通常會自己上網學習其相關知識點，一個由點擴成線在到面的過程，有時這樣反覆的學習你會越來越老練，對之後的review也會有所提升
3. 在comment欄中與同事的提問、討論中會提升自己的思維視野或是本來沒有想過的點。

Advocate your work and find some customers for it

這個是我近期學到的點，對於主管交代的任務，什麼時候叫做完成是一個看似簡單，一般新手容易誤會的點。曾經我以為，程式碼完成了叫完成，ship到了prodution叫完成，事實上這些只能說是達標式的完成。

比如你拿到建立一個系統的任務，系統建立完了的當下並不能叫完成，你還需要：

1. 告知你的組員們你完成了這項任務，你可以給他們一些demo，你可以邀請其他組的人來參加會議秀給他們看，說不定不只 benefit 你們組，也能 benefit 其他組，這個主是為你的成果打廣告，這點非常重要，默默的完成任務並不會凸顯你的價值，實作與宣傳都是不可或缺的東西。
2. 你需要找到使用者來用看看，其實跟第一點類似，你弄了一個feature，說不定其他組覺得不錯，用的人開始多起來，能擴大他的影響。

其實上述的邏輯就是，你需要幫你的項目找到他的價值，並且將它發揚光大， empower other、contribute to others success 都是新人非常容易忽略的點，這個也能為你在主管心中，其他組員心中留下深刻的印象。