在比《薩爾達傳說》還自由的世界裡，我要當哪一種玩家？
覺得日本 youtuber 的生活 vlog 調性跟台灣 youtuber 差異滿大的，日本人有一個派別的 vlog 幾乎不說話，定點拍攝一天中造訪的店面、光影、人物攢動，剪輯上字幕、滿常使用英文的美術字體，配以大量的英文輕快音樂。先前 WFH 的日子裡常用外接螢幕看他們的影片，不得不說有點嚮往那樣的步調。（不過清醒時就覺得，怎麼每支片都在咖啡店跟選品店流連 XD）
發摟一個時尚 youtuber 一陣子了，幾乎只會五十音的她最近去日本留學，我好奇片中總是把自己打理得精緻的她，會怎麼記錄自己在日本的生活，不知不覺看她影片的頻率遠比她在台灣時高了。
這位女生也如那些日本 vlog 一樣，拍起了自己起床盥洗的儀式、備菜下廚的畫面。不過與日本人不同的是，她在刷牙、洗臉、煮水、倒牛奶倒麥片的期間，一覽無遺的是厭世、無神的面容，我簡直看到台灣人的自信跟不扭捏、簡直從中得到了救贖。說起來，誰早上能看起來精緻、誰早餐能日日做出早午餐般的擺盤。
面對自己的粗糙與疲乏也很重要啊。
Nintendo Switch 的《薩爾達傳說‧王國之淚》上市後，我花了兩個週末、6 個小時終於打完新手村，然後把這款遊戲交給男友繼續破完。《薩爾達》主打開放世界，主線僅僅是從魔王手中救出失蹤的薩爾達公主。但正因為是開放世界，你可以不被劇情阻擋，自由地穿梭在天空、陸地、地底的地圖之間；妳當然可以直接衝去救公主，但在路上永遠會瞥見還沒解開的神廟、哭夭著想回朋友身邊的克洛格，你可能還想解救各個村落的困難、組出災厄般毀天滅地的鋼彈⋯⋯總是會有支線任務吸引你去做，這就是海拉魯王國的迷人之處。
最近我也覺得自己的人生像在玩《薩爾達》了。
自工作開始，總覺得自己在無盡地奔跑。因為缺乏前後端技術知識，無法快速理解及傳遞工程師的訊息，我買了計算機概論的線上科普課程、聽完了又去聽哈佛的 CS50，像是從大一資工開始學起，但是我沒能有系統地學會，總是覺得自己在落後；最近要學著追蹤網站數據，要再花週末的時間了解 GA、GTM 原理，才能夠知道如何提出易於執行的分析計畫。
不只如此，始終認為忙著在養成各職能 LV 0 技能樹的自己，沒能像資深的他人一樣在會議中提出關鍵觀點，每當工作出錯、忘記先前提過的事，就在心裡再記自己一筆愚笨。
停止無限的支線任務
不知不覺間，我好像陷入了無盡的支線任務，今天在努力賺錢農裝備、明天在幫村落的人趕雞，絲毫沒有推進主線劇情的同時，還為自己沒辦法在支線任務馬上派上用場而焦躁。簡單來說，就像隻神經兮兮、過度反應的吉娃娃。
然而世上玩家的玩法各有不同，有人會挑戰 speed run（最快破關速度）、有人會組出左納烏工業革命（近期看過最帥的是戰鬥陀螺）、有人只在乎海拉魯王國的沿途美景。
如果想要走遍地景，就無法 speed run；想要蒐齊所有裝備，勢必存不了充足的盧比（遊戲貨幣）蓋房子；喜歡沉浸在故事裡找彩蛋，就不要限制自己遊玩時間。
當然啦，工作裡很難不收到支線任務，但是不為此喜悲會比焦慮更好吧。
過度追求卓越
朋友推薦聽的 Podcast 失職日記在 EP99 提到了這個概念。
致力追逐卓越的問題在於，基於過去努力就克服了關卡的成功經驗，認為所有的挫折都應該靠努力克服，以致遇到再怎麼努力都克服不了的難關時，會無法消化這等絕境。
在過去求學的經驗裡，意志力能戰勝一切、勤能補拙、抓到訣竅就能一通百通。但是工作有一堆難題就像在《薩爾達》解不開的神廟，我可能已經用盡自己的能力、甚至耗費額外的時間學習，卻仍不足以破解難關。為此，無法接受我已經不是優秀、聰明的。
可是卓越是比較而來的、是出於他人嘴裡的。這又回到我的海拉魯王國，我是追求得到帶得走的技能，還是績效考核裡的卓越？
下次遇到難關的時候，我要設好自己的破關目標，即使這一關的怪打不過，我也要在心裡默默喊給自己：「至少我換到一把比較強的弓！」
在自由的世界裡，我要當哪一種玩家？
總是默默地看著他人的 career path，欣羨他人的薪水區間、職涯範疇、生活方式，那是種可怕的想像，像是把他人的光鮮全部綜合到一點上，然後螫得自己滿身。
Youtuber 們都知道想要在《薩爾達》的遊戲直播海裡殺出一條血路，就必須有出眾、專門的玩法，可能是超會組鋼彈、或是解析出全部食譜的配方，才會得到幾聲「有神快拜」。因此要求自己又會 speed run、又要破完全部神廟跟劇情、連沿途風景也拍遍，這樣完美的優秀是種無謂的想像。
我覺得光是在海拉魯王國走來走去就夠好玩了，也不用非要當什麼專門型的玩家。
有天我跟男友抱怨著無法享受《薩爾達》時，他回應了這番話。專注地走向目標也許是破除焦慮的其一方式，但人生是比《薩爾達》還要廣闊的開放世界，我決定嘗試接納他的觀點，也許改天再跟他拿回主機，試著享受這款遊戲吧。
這一週是學到開 mail spec 的進階觀點。為了讓系統信與使用者的 life cycle 綁得更緊密、並以更少的成本達成，公司使用了 Amazon 的服務，這些發信邏輯都可能與 client — server 的溝通相關。
我們計劃在使用者完成消費後的後續數天收到關心與問題排除的信件，接著遇到幾次的靈魂拷問。
1. 使用者是 lifetime 收一次這封信嗎？
是，不然每消費一次就要被問候也太煩了ㄅ。
但要在 DB 另外存一個 boolean 只為記這封信寄過了沒，感覺非常不實用；相對好很多的作法，可以是判斷使用者是否有先前的消費紀錄，若為空才發信。
2. 如果使用者先前是買方案 A、現在是買方案 B，這兩種方案內容很不一樣，他應該再次收到信嗎？
要欸，不然他可能這次就遇到問題了啊！
取得共識後，把規格從判斷先前的消費紀錄，改成當該 user 先前沒有這個產品的消費紀錄時才會收到信。
3. 這樣這封訂閱後 3 天的信是否應該要有產品名才夠客製化？
對喔，每個產品的 onboarding tips 可能不一樣嘛！
哇，不過這樣就會有針對各個產品的信件模板、文案出現，無論設計跟翻譯都會得加上 a 封信乘以 b 個語言的成本。
4. 訂閱後是第 2 天統一判斷發信，還是在訂閱當下計算 48小時後發信？
嗯，這沒有最好的答案。
- 第 2 天找個時間讓 server 統一發一次信感覺滿合理的，但是如果使用者凌晨收到信可能超問號；若想在使用者當地的下午時段寄信，就需要記當地時間。然而簡單撈了一下 DB，並不是所有 user 都有被記錄到國家代碼，暫且作罷。
- 訂閱當下計算 48 小時後發信，感覺也滿合理的，不過就得有另外的 worker 記憶這類短期的工作，避免打擾主要運算用的 server。
沒想到就乖乖地每週噴一篇了～
