計畫中陪舅舅去走的草嶺古道之旅，天公不作美，還是硬著頭皮上路。
有了三年前的經驗，這次改變策略，從福隆車站出發，先買好福隆便當做為午餐，然後搭計程車直達步道口 (標準價一趟 200 元，可先和司機談好要進去到步道口，而不是只到遠望坑親水公園的廁所)，節省一個多小時的腳程。
幾乎全程下雨的情況下，出發沒多久鞋子就濕透了，姑且就盡情踩踏，放給他濕透吧！雨中的深山，別有一番滋味，讓人回想起大學時期去爬奇萊南峰的感覺。接近啞口時，由於接近中午，又難得遇到一個涼亭，就前往午餐。啞口附近如預期般風勢增大，索性還有很多山友作伴，大家就在根本擋不了風雨的涼亭下，一起背對著風雨，排排站著吃便當，有點克難又有點好笑。狂風挾帶著雨水之下，在虎字碑和啞口拍一些照之後，匆匆下山。由於比預期還早很多抵達終點大里車站，便臨時起意前往舅舅原定隔天要去的雙溪荷花園。陰雨綿綿的荷花殘枝倒影，正是舅舅想追逐的景象，完美！
風雨中的虎字碑自拍。
別有一番風味的荷花殘枝倒影。
軌跡記錄。
來聊聊 Google 的 code review 文化。
在 Google，要 submit 一個 CL (changelist, 等同於 git 裡的 pull request)，需要經過三關的 code review：1. 自動化程式 review, 2. team/project review, 3. readability review。第一關，由程式或 AI 就能針對不同面向，自動從 CL 裡面挑出一些顯而易見的錯誤，或是可以改善的地方。第二關，就好理解多了，主要是由 team members 去針對功能上部分做檢查。第三關，會依照 CL 裡面用到的語言，而需要請該語言的大神們來 review (由系統自動指定)，針對程式語法上可以改進的部分，給予建議。基本上這是蠻好的機制，強制大家都遵守同一套 coding style，以及套用一些像是 Effective Java 或是 Effective Dart 之類的 best practice。總之，就是無所不用其極地，避免各種髒 code 進到全公司共用的 monorepo 當中。同時，在神人們的指教當中，自己也能從中學到許多實用的技巧。
然而，這不是沒有代價的。這樣嚴格的把關，尤其是 readability review，勢必會大幅拖累開發的速度。有時候，當 reviewer 是其他時區的人，如果不巧對方又是個大忙人，一來一往可能幾天甚至一個多禮拜就過去了。再者，有些 reviewer 的標準之高，到了一種近乎苛求毫無道理的地步。舉例來說，常會有 reviewer 要求所有變數、函式都要寫 comment，即使變數名稱或函式名稱本身已經很清楚地說明了它的用途，於是就配合寫上跟變數名稱或函式名稱很像的 comment，然後又會被要求要多補充一些額外的資訊，不然乾脆不要寫，於是就得硬著頭皮再去扯一些可有可無的東西硬塞到 comment 裡。而 comment 的用字遣詞又暗藏了許多潛規則，像是 boolean 變數的 comment 一定要用 "Whether" 開頭、函式 comment 一定要以第三人稱單數的動詞開頭之類的，繁族不及備載。另外，有時還會遇到不同 reviewers 持相反意見的情況。而有時也會遇到 reviewer 對於選用的 solution 發表意見，早已超越了 readability 該審核的範圍，你如果不照他的建議調整他還不太高興，把你的 readability 分數扣分 (readability 分數是用來晉升到大神的主要參考依據。像我們這種初階平民，如果未來想要晉升大神去幫別人 review code，就要透過不斷 submit code，以獲得足夠多的大神們的分數累積後，才得以晉升)。不誇張地說，整個開發時程，大約只有 1/3 在寫主體，另外 1/3 在寫 test cases，還有 1/3 在搞 code review，而後兩者往往還會佔掉更多比例。
總之，這是一套有利有弊的機制，整體來說絕對是利大於弊，畢竟這麼大的公司，這麼多複雜的系統，實在容不下一點點的污點。這個世界上，能把 code review 做到這種地步，全公司上下都對程式品質苛求到一種變態的程度的，大概也只有 Google 了吧。
進 Google 以來，一直想記錄點什麼，但想記錄的東西好像都散散的，總覺得要累積多點東西，再系統性的整理一下，比較完整。可是時間一長，又有點擔心這樣累積下去，該不會最後就什麼都沒記錄下來。所以不管了，想到什麼就紀錄一下吧！
來聊聊最近的事，每年的這個時候，公司都會有個 Holiday Giving Campaign 的活動，提供每一位員工 US$400 的額度，去捐獻給想要支持的非營利組織。這就體現了一種公司隨處可見的 bottom-up 文化。可能公司本來就有一大筆預算要拿去捐獻，但問題是這麼大一筆錢，面對全世界成千上萬個非營利組織，要捐給誰？要怎麼分配？這實在太複雜了，乾脆交由每位員工去選擇，於是員工就會自己去研究，並在公司內部推廣自己認同的組織，由員工拿著自己的額度去捐獻給自己認同的組織。除了變相達成了群體決策讓資源做最有效的分配，也讓員工多了一些參與感，同時多去認識一些世界上需要關注的議題。
類似的概念，在公司裡還有 peer bonus 的制度。每一季，公司允許員工發送 5 次 peer bonus (NT$3000/次)，給對於自己或團隊有額外特殊貢獻的同事表達感謝。這讓有好表現的底層員工更有被實質認可的機會，也變相讓公司省下不知道該獎勵誰的困擾。
還有，像是大型會議的 Q&A，都會事先用一套 Dory 的內部系統來搜集問題 (曾經一度公開為 Google Moderator，後來又關掉，員工乾脆自己出來開了一間公司)，再由員工來投票，讓重要的議題在集體決策下浮上檯面。
類似的 bottom-up 的集體決策機制，幾乎可以說是整間公司的 DNA 了。我想這也跟公司最一開始的基礎 PageRank 搜尋演算法有關，利用網頁之間相互的集體決策，就能自動產出最好的搜尋結果。同樣的概念，很多東西一旦去中心化，就會有一隻看不見的手，自動調整出最好的資源分配。
懂的放手，反而能獲得所有。
衝著台北表演藝術中心的參觀回路免費到年底，臨時起意去探探路，見識一下號稱很厲害的貢丸造型建築設計。其中個人覺得蠻厲害的是沿途設有許多觀景窗，能看進劇場內部，甚至在劇場演出的同時，可以看到正在看劇的觀眾反應。可惜參觀期間的劇場演出都蠻暗的，沒辦法看的清楚。總之，大概比較確定這應該是小孩不太會感興趣的點了。
運氣不錯，在回路出口出現彩虹。
接連讀了兩本機率相關的書：《機率思考 (CHANGING IT)》、《莊家優勢 (The House Advantage)》。先說總結：正確解讀理論或經驗而來的統計機率數字，然後堅定不移地相信並選擇期望值較高的方向去執行，機率將帶給我們應有的報酬。
在這當中，首當其衝的「正確解讀」，就是一項不那麼容易的課題了。在這個資訊爆炸的年代，各種倒因為果的偽科學推論，很容易就因為標題聳動而快速蔓延。例如車禍事件受害者往往都有繫安全帶，可能就會被錯誤解讀為繫安全帶將導致車禍。更糟的是，有些「異數」事件因此被擴大解讀，更能進一步扭曲事實真相。書中舉了 2008 年英國政府決定，13 歲以下女孩要接種能預防子宮頸癌的 HPV 疫苗為例，當一位女孩接種疫苗後數小時內死亡，於是有人要求終止疫苗計劃。當我們跳回機率的框架，女孩死亡當下已經有 130 萬名女孩接種了同樣的疫苗，這時我們該權衡的，應該是 130 萬分之一的死亡率與大規模解決子宮頸癌之間的取捨。而事後的驗屍結果則顯示，女孩胸部有惡性腫瘤，死因與疫苗沒有那麼大的關聯。這也不免讓人聯想到近年來的 Covid-19 疫苗的種種爭論。
再來，理論或經驗而來的統計機率數字，則通常是相對客觀且一翻兩瞪眼的。以 21 點算牌來說，就是理論能算得出來的機率。透過觀察已經發出的牌，我們就能大概知道還沒發出的牌的大致組成，並藉由這些線索，推算當下自己與莊家的勝率，在自己勝率高的時候多下注，莊家勝率高的時候不下注，只要回合數夠多，機率就就能反應在自己的籌碼上。至於經驗而來的機率，其實說穿了就是大數據、人工智慧同樣一套概念，這裡就不展開細講。
有了正確的解讀，有了統計機率數字，要堅定不移地相信並選擇期望值較高的方向，往往又是另一回事。畢竟，人之所以為人，終究還是有情感、有非理性的部分。以《莊家優勢》作者提到的一個 21 點的狀況為例，當剩餘牌的點數對我們極為有利時，即使拿到兩張 10 點的牌，幾乎穩贏的狀況下，也要違反直覺將兩張 10 分牌，同時加倍下注，因為理論上會有更高的期望值。
除了以上結論，還有兩個小重點也蠻值得一記的：
首先是風險控管。機率之所以管用，就是次數要夠多，效果才會反應出來。所以在 21 點下注策略上，分批進場是很重要的，畢竟一下就把子彈用完，機率再怎麼對自己有利也無法再玩下去了。
再來是常態分配 (normal distribution) 並不常見。「常態分配」聽起來就是很常見的一種分佈，其呈現出來的鐘形曲線也蠻對稱美麗的，因而被廣泛套用在各種機率計算中，殊不知現實世界往往是由許多醜陋的分佈所組成，例如薪資、氣象學、生態學、地質學等領域都有呈偏態分配的情況，金融市場活動更是比較接近極端事件機率相對高的柯西分配 (Cauchy distribution)，此時如果錯用了常態分配，可能就會得到與事實不符的錯誤預測。
常態分配與柯西分配 (source: Wolfram)
