工作的反思：「觀察力」一個被長期低估的能力
最近在工作上，開始覺得有一點無聊。剛 lead 完一個比較大的專案，開始在當自由球員。但因為接的東西也蠻熟悉的，就覺得用到的技術好像也就那些，開始覺得有點無聊、沒動力。
因此開始在思考，到底該怎麼讓自己在工作有更多的學習？
思考一陣子後，我發現其實並不是沒有更多學習機會，而是我缺少「刻意觀察」，並也意識到「觀察」是一個很重要，但被我長期忽略的技能。
大概從幾個面向，紀錄一下這些事情給我的啟發跟提醒。
愛偷看別人程式碼的同事
其中一個，帶我這樣的刺激，是今年剛加入的一個新同事，他加入之後，就時常會發現他出現在別人的 MR（Merge request) 頁面，偷看別人寫的 code ，然後留一些自己的回饋＆意見。
一開始覺得這個人很奇怪，明明這些功能，也不是他負責的，為什麼會願意多花時間去看別人寫的 code，並且給回饋呢？
後來他就跟大家分享說，他很習慣去看別人的 MR，因為可以看大家在幹嘛，學習到不同人的思考/做事方式。
於是前幾天，我就強迫自己（認真是「強迫」），去看別人發的 MR。然後，看到一個同事在做 gitlab CI 的 cache ，用來加速系統部署的流程。
一開始看的時候，我其實內心是覺得很抗拒的。因為快速掃過去後，我對於這個同事改了什麼、為什麼要這樣改不太懂，內心很想要說「算了，也不是我的工作」，就關掉畫面離開去。
但後來我還是強迫自己看下去，並為了給出一些有意義的回饋，我還去找了一些相關文件來研究。仔細看了一陣子，發現「欸，其實真的也沒想像那麼難」「這還蠻有趣的」，等到最後終於看懂全貌後，我發現自己已經學會了怎麼設定 ci cache ，並且認識了 npm 的 cache 機制，體驗到一種「欸！我會了欸」的快樂，覺得很開心。
然後就發現到，其實去看同事的 code ，其實是有很多好處的
1. 可以觀察/學習別人怎麼解決問題：
之前對於「學習」，我都會被侷限在「上課、 side project 、工作上實驗」等方式，但會發現，其實這些學習方式都有一些門檻。
- 上課：通常需要很完整的時間，容易下班後就沒動力去學。
- side project ：單純為了練習，很容易會因為沒有實用價值，最後也沒有動力。
- 工作上實驗：能在實作中學習當然是最好，但又不是所有專案都那麼充裕可以做實驗，很多時候，因為沒做過怕會 fail，最後還是回去用舊方式，不敢嘗試新作法。
但被同事啟發後，發現了其實還有更低門檻的學習方式「觀察同事怎麼解決問題，並嘗試加入一起討論。」這樣透過觀察、單純討論就可以學到東西，也不用承擔專案 fail 的風險。
2. 掌握自己的「主動權」：我覺得這是最重要的一點，可以獲得工作上更多的選擇權。
- 可以認識更多機會：因為嘗試去理解別人在幹嘛，有機會從自己的專案中跳脫出來，用更宏觀的角度，去看到團隊中還有哪些自己可能有興趣的專案＆技術，並且在之後爭取去做做看。
- 別人會主動找你，給更多機會：假設看 code 的過程中，真的有能力給一些回饋＆幫點小忙，未來該專案如果有後續，對方可能就覺得可以找你 review 或跟你合作開發。
像那個新同事，感覺他工作前三個月，就是藉由到處看別人程式和給回饋，然後慢慢就掌握了團隊的狀態，並融入了團隊。然後，很多專案負責人，後續就真的直接請他 review 或一起開發，讓他參與了他感興趣的專案。
想到最近聽一個西雅圖微軟資深工程師的分享，別人問他說「要如何在工作上學習？」，他就說「先從去主動幫同事的忙」。一開始覺得「好普通啊」。但仔細想想，其實也是蠻相關的。
很多時候，我們都是在等待別人 assign 工作，期待別人可以給自己有興趣的專案。但問題是，別人可能根本不知道「你有能力」或「你想要」做這些事情，但是當如果願意主動幫別人（小到只是提供意見，中到幫忙查資料，大到真的下去幫忙做），就可以讓別人知道「欸，你有點想法喔！」、「你好像知道該怎麼做喔！」
這樣釋放訊息後，通常慢慢就會有人主動找你討論相關問題，甚至找你一起合作專案（然後因為幫的忙是「你挑過的」，所以其實也是在幫自己篩選學習機會）
這也讓我意識：好專案真的不會突然掉下來到自己身上，都是自己先願意從一些「微小的地方」（前期討論 / 回饋 / 幫忙想解法 ）多參與一點，展現自己能力和存在感；等專案確立時，才會順理成章的成為負責人或被邀請參與。
而這一切的前提，就是「願意觀察」組織內部有哪些事件和討論再發生。
成為好演員的第一步是「觀察」
最近參加果陀劇團的表演課程時，也有類似的啟發。
在表演課時，同學會輪流上台呈現。然後每次，老師都會跟台下同學說，「欸！要好好觀察別人的表演，不要都在內心想著自己等下的表演喔！」完全的掌握了台灣學生，還沒上台報告時，都不會想聽其他同學報告的焦慮心態XD。
上課時，老師會一直強調「觀察是演員重要的能力之」。要有能力演得好，一是要有足夠的角色資料庫，二是要有能力抓取到不同角色的特徵。
我思考了一下，「觀察」大致包含 2 個面向「搜集資訊」和「分析差異」
- 蒐集資訊：觀察的第一個好處，是可以大量蒐集對自己有幫助的素材。
課堂上，同樣是表達「悲傷」的練習，多數人的做法可能是鬼哭神嚎、大喊大哭。但有些同學的「悲傷」，竟然是完全相反。「不哭不喊，眼神恍神，最後再配上一個勉為其難的一笑」。
這時候就會很驚奇，原來悲傷可以這麼安靜，但其實反而也非常真實，因為很多時候人們展現的悲傷時，確實不是大吼大叫，而很抽離、憂鬱的在悲傷。
但像在這種時候，如果內心都在擔心自己等下該怎麼演，而沒有觀察的「意願」，就會錯過一個很好的學習素材。 - 分析差異：
有了素材之後，再來就是可以分析「目標」跟「自己」的差異。
- 思考對方是怎麼呈現一種「安靜的悲傷」？
- 用了哪些動作、語氣、肢體來呈現這種感覺？
- 自己做得出這樣的效果嗎？
當完成「觀察」之後，演員才是進行「刻意模仿」，去一一克服「目標」跟「自己」的差異，把自己穿入角色當中。
但其實我覺得「刻意模仿」不是最難的，比較多是我們「沒有認真在搜集資訊」，也「沒有覺得這值得分析＆學習」，而是把心力放在「等下我該怎麼辦」。
Read more than you need
上面這些經驗，又讓我想到「Read more than you need」這句話。
這是一個工程師前輩（前台灣 google map 負責人）分享的 mindset。
他說工程師變厲害的秘訣，就是「永遠多讀一點」。例如：同樣遇到一個 bug，別人去 stackoverflow 複製貼上解法，但他會多花幾分鐘，把下面的討論、產生 bug 原因、歷史脈絡、相關的 reference 看完。
所以在職涯前期，其他人可能複製貼上，就把事情做完了。但他可能因為多花了一些時間再研究原理和了解為什麼，確實多花了一些時間。但久而久之，他的基礎功卻因此比別人扎實，累積的問題資料庫也比別人多，因此解決問題的速度反而愈來愈快，跟其他人拉出差距。
之後遇到同個問題，工程師同樣一樣是去 stackoverflow 複製貼上，或是各種 try error。但他因為之前都有花時間多去理解一些技術的脈絡和大架構，更有 big picture，所以都能更快地鎖定問題＆找到解法，然後給出很好的意見，同事們也覺得他很厲害。
當時對於這個「Read more than you need」覺得很印象深刻，因為非常單純但卻很強大。
但回到工作中，會發現其實沒有想像的好執行。因為在工作當中，為了想要有好的表現，時常會被「想趕快解決掉問題，證明自己很棒。」的心態困住，因此想趕快就選擇一個解法，而沒有給予足夠的耐心，多去「觀察」一下其他解法和全局。
最難的不是行動的過程，而是開始的「意願」
綜合以上，我覺得這些事情落實到行動上其實都不難。
- 去看同事的程式碼
- 幫同事個小忙（給點小意見/幫忙一起討論/幫忙查資料/幫忙寫 code)
- 觀察其他同學怎麼表演
- Read more than you need
這些真的都不是難事，我覺得最難的真的是「意願」
- 願意忍受剛接觸新事物時，會產生「不太懂在幹嘛 / 他們在說什麼？」的不舒服。（就像我打開同事的 MR 幾秒，就很想要關掉；或是，有時候打開技術文件，也會有類似的心情 XD）
- 願意放下「我需要先趕快解決自己的問題，沒有時間管別人在幹嘛」的焦慮感
- 願意把注意力從自己移到別人身上，從中發現可以學習或模仿的地方
但正是因為不是能力，而是「意願」，反而不會特別被強調，但確實是我近期覺得自己最該好好培養的重要能力「如何好好把眼光從自身移開，去觀察這個世界。」
(我覺得這會是很不容易的過程... 但希望我下週可以多看幾個同事的 MR >< )