在a8c，每年年末會有一次秘密聖誕老人(Secret Santa)的交換禮物活動，也就是「小天使小主人」遊戲。雖然我幾乎每年都參加，突然想到我好像沒有寫過這件事。

活動進行方法是：

1. 當年主辦人會在約11月中於watercooler p2宣布開始登記，有興趣的人就自行到內部一個名為"Automattic Gift Exchange"的WordPress網站登記。
2. 登記時間截止。Automattic Gift Exchange會發送Slack ping，告訴你今年的送禮對象已經決定了，這時去該網站就會看到本次送禮對象的寄送資訊，以及一個可以匿名發送訊息給送禮對象或是你的秘密聖誕老人的表單。
3. 收到禮物，是時候去watercooler p2發文炫耀啦！一個不成文的規定是最先收到禮物的人要開一個新的p2討論串。

因為公司的人遍布全球，所以玩這個好玩之處就在會有機會收到世界各地的東西。我曾經收過來自瑞典的節慶食品，其中一條焦糖醬因為真的太甜了現在還躺在我家冰箱；來自亞利桑那州的各式仙人掌特產以及當地小咖啡店的重烘焙豆，那支咖啡的風味之好我至今還念念不忘(我常常覺得台灣咖啡師大多對重烘豆過於歧視，不過那是題外話)；還有一年某熱愛烘焙的同事因為沒辦法寄她自己的作品來，居然訂了Biolove的蛋糕給我，她不通中文也沒到過台灣，令我印象深刻。

今年收到的是來自英國的恐怖漫畫：Ghost Island: The Complete Collection：

這本書來自一位曾經在grand meetup合作過的同事。他事前有寫匿名信給我，想多了解我的喜好來選擇。
「你最近一次追劇是追了什麼？」
「魷魚遊戲」
大概是這樣，他選了一本恐怖漫畫給我。我收到沒多久就看完了，作畫呈現相當精彩，雖然整體故事張力和人物表現深度似乎礙於篇幅有些不足，但仍然是部佳作。

至於我送的禮物呢？過去每次我都是精選台灣美食大禮包寄送，但今年抽到印度同事，很不幸沒有任何運費合理的方式可以寄送，我只好上Amazon.in去買了一個我出外工作必備的收納神器GRID-IT，從當地商家送去，雖然氣勢不足，起碼顧到實用性與價值感。

如果2022年末全球物流能恢復正常，抽到我的人就賺到了。兩年悶氣集成的兩倍大禮包，必定要他一次從台灣頭吃到台灣尾，看到MIT字樣都會怕。

LeadDev是Reboot之外另一個我們公司常送人去的領導管理conference，今年因應疫情，也全面移師線上。今晚歹丸時間8點會登場的就是LeadDev Live，6個小時雙軌的內容看來相當精實，但全面免費！

登入專用Slack channel後看到主辦人在邀請大家插國旗，毫無懸念地插上第一支，感覺人生圓滿。

希望今晚不要邊聽邊睡，就更圓滿了。

自從4月初MarTech team首度以squad模式嘗試分層運行這個日漸壯大的團隊，不知不覺也4個月了。Squad和Team在a8c是很不同的概念：team就是傳統上我們認知中的團隊，而squad是針對某個專案組成的小組，通常是跨團隊甚至跨部門的，沒有特定的運作規章，在專案完成後就會做鳥獸散。

由於要組成新的team有許多正式流程要進行，當時我們也不太確定這樣對整個MarTech是否合適，因此就先以squad模式運行看看。而這項實驗也終於在上個月塵埃落定：MarTech正式分成兩個子團隊。順帶一提，我們這次用了變形金剛主題來命名，因為我丟銅板丟輸了，我所屬的團隊就成了狂派(Decepticons)。

Continue reading ➞ 在a8c做leader初期小感

過去寫了這麼多在Automattic工作的好事，今天趁著在等程式碼發佈的空檔，來寫個數年來懸宕未解的問題：維護孤兒 —— 發佈之後，儘管使用者眾多，也永遠拿不到資源維護的專案。

會下這麼聳動的標題，是因為我覺得這是我們鬆散、高彈性、強調速度、根源於開源專案的工作文化的一體兩面。我們內部同時啟動的專案非常多，一個專案也通常短則1~2週，長則2~3月就發佈了，發佈之後呢？人就四散去做別的事情去了。在剛開始的一兩個月，要找到原班人馬處理後續維護還算可行，但隨著時間過去，要追溯愈來愈困難，優先序也逐漸受到新的專案擠壓；issue延宕的時間從本來可能2到3週，逐漸推進到2到3個月，當開始出現超過半年也沒人解的issue，我們便又多得到一個維護孤兒，可喜可樂、可喜可樂。以前曾讀過某篇文章論中國的高速經濟擴張弊病，裡面有一句神比喻：「步子邁太大，扯到蛋了」，差不多就像這種感覺吧？衝太快，掉好多包了。

一個很好的例子是calypso專案的自動化end-to-end測試。概念上，每當有一個PR被標上"needs review"，我們的系統會自動在calypso.live上設立起一個docker container來跑該分枝的calypso，再用tests/e2e下分類為canary tests的自動測試去確認基本的正確性。如果進一步標上"needs e2e tests"，那就會有好幾卡車的桌面版與行動版end-to-end測試對它這捏那拉、上沖下洗的，跑到PR吱吱叫。

這聽起來很美好，但有個問題：calypso.live相當不穩定，所以就會常常發生automated e2e tests不過，打開一看是calypso.live起始失敗：

這造成很多問題。開發人員常常被迫去檢查這個false negative，一開始大家還會想說重跑一下，久而久之大家就開始留下「此錯誤與本PR無關」等話，然後就忽視過去了。結果呢？曾經發生過有些不該忽視的也被忽視，造成好一段時間帳號註冊無法使用。由於一旦出錯，CircleCI會自動通知該repo的所有人，這類訊息看久了大家紛紛設inbox filter直接把它濾掉，試問這樣CI的意義還剩下多少？

這樣天天在用的東西，應該很快就會被修好吧？很遺憾，大概快一年了都還是這樣。像這樣即使很多人在用仍然成為維護孤兒的內部工具多到不行，今天舉calypso.live為例只是它會出現在公開的源碼庫中，比較方便講而已。

換個角度想，這也是為什麼一旦組織大起來，自幹前要三思 —— 長期維護成本難以估計，自己能投入多久亦未知。