Hi 讀者，
先前我們曾經分享過 Linear 是怎麼開發產品，最近他們的創辦人 Karri Saarinen 在 X（Twitter）上分享了六點關於他們怎麼做「設計」的貼文，例如「We screenshot the app and design on top of [it].」（我們螢幕截圖，然後直接在上面設計）；每季只有一個（Figma）設計檔案，大家都在裡面建一個新頁面做自己的專案，這樣比較容易看到彼此在做什麼⋯⋯
另外，以系統設計和相關面試教材聞名的 ByteByteGo 最近將他們 System Design 101 教材在 GitHub 開源，還不認識他們的讀者可以參考我們的介紹：〈發展科技職涯，值得你訂閱的三份電子報〉。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] 管其毅、Koo Ping Shung、Angus Kong／數據治理（data governance）該怎麼做？產業案例分享
閱讀時間：10-15 分鐘
上週我們談到企業設立數據長（CDO）的話題，這項工作的職責之一是數據治理（data governance）。本文是我們今年八月「AI Your Summer」其中一場以數據為主題的對談，邀請三位產業專家分享數據治理在金融、醫療等領域的案例。三位專家分別是管其毅（現任 TaskRabbit VP of Data、台灣資料科學社群 TWDS Meetup 創辦人）、Koo Ping Shung（企業數據顧問、新加坡資料社群 DataScience SG 共同創辦人）、Angus Kong（現任 Fintech 新創 FAZZ CTO）。
這場分享的話題涵蓋數據治理的核心精神、企業該在何時導入數據治理、該如何推動數據治理。三位專家也分享了各自在工作上所面臨的經驗與案例，例如管其毅就建議企業若無數據治理經驗，可從資料工程部門開始做好基礎工作；Koo 則指出「數據治理不是技術問題，而是利益關係人的動力管理。」；Angus 談到他在資料敏感的產業中，從技術主管的觀點怎麼去理解數據相關的法規。（例如一家醫院的資料不能離開大樓，甚至是特定的機器。）
[Podcast] Lenny’s Podcast／只看一個指標，Arc 瀏覽器背後團隊如何開發產品？「最佳化人們的感受」又是什麼意思？
收聽時間：約 90 分鐘
我們在第九期介紹過產品開發管理工具「Linear」打造產品的方法，其特殊之處在於沒有專職 PM，也不怎麼依賴數據。本週我們要推薦的是 Lenny Rachitsky 採訪 Arc 瀏覽器背後的公司 The Browser Company 共同創辦人、CEO Josh Miller。Arc 瀏覽器推出後在市場收到不少好評，他們開發產品的風格是更新頻繁，而且常常推出充滿創意而實用的小功能（例如用 AI 自動為那些檔名很奇怪的下載檔案取個人類看得懂的檔名）。Miller 在節目中分享了不少可說是相當獨特的觀點。
過去有創業經歷、（因為公司被收購）在 Facebook 工作過的 Miller 認為矽谷公司長期以來過度著迷於各種指標和數據，這種數據擺第一的開發方式「錯過很多東西」。他以 Disney、Nike 和 Apple 為例，問聽眾：「你覺得這三家公司的創辦人在開發產品時最關注的是什麼？」他說數字固然是一個用來檢視是否達到目標的方法，但是團隊在開發產品時最關心的還是使用者，要最佳化的是使用者的「感受」（feelings）。至於數據，他們只關心一個「D5D7 留存率」指標，D5D7 指的是使用者每週七天是否有五天會打開 Arc 瀏覽器，這個指標按照不同使用者族群大約在 3X%-4X% 之間。
以下是幾個 Miller 分享的做法和觀點：用「我什麼都不知道」的心態開發產品，團隊有參與開發初代 Chrome 的成員，但他的「初學者心態」卻是最強的；他們設置了兩個比較古怪的團隊「membership」與「story telling」；喜歡跨領域人才，刻意避免專職 PM，而是依照專案特性由不同的人來做 PM 的角色，但職稱不會是「PM」，例如與效能有關的專案，就會由後端工程師來做 PM 工作。Miller 認為一般的企業價值都太呆板、充滿宣傳意味，他們的做法是所有人共同參與，花三個月寫出「公路旅行筆記」。
[英] Mitchell Hashimoto／盡快看到小成果、盡快能 demo：我做大型技術專案的五個原則
原文連結｜閱讀時間：10-15 分鐘
當你在做一個新專案，不管是要從無到有開始做產品、做一個大功能，又或者要重構程式碼時，會有以下症頭嗎？一開始雄心勃勃、充滿動力，每天都等不及要上工，接著幾個禮拜後你開始分心，或是幫自己找藉口⋯⋯本文作者是 Hashicorp 共同創辦人 Mitchell Hashimoto，他以自己的業餘專案為例，分享他做大型技術專案的方法，大致上可以歸納為五點，並且告訴讀者「經驗」在哪些地方有用，哪裡會成為阻力，很值得參考。
雖然 Hashimoto 的第一步也是要把大型專案先拆成小塊，不過他的著眼點是可以更快看到成果，維持動力；另一項重點則是一切要以「盡快能 demo」為目標去解決專案裡的問題，demo 可以讓你很快感覺出這個東西好不好，他見過許多資深的工程師會花太多時間去把東西做得很好，但是 demo 時才發現根本沒用。他還建議可以優先做自己想用的功能，讓自己盡快可以採用專案成果。以 Hashimoto 的案例來說，他花了幾年時間斷斷續續做了一個 terminal emulator，然後就拿來當作自己唯一使用的 terminal app。
Hashimoto 的經歷很特別，他先是在 2012 年共同創辦 Hashicorp 並擔任 CEO，三年多後轉任 CTO，再過五年轉任 IC（individual contributor）至今，這樣的職涯發展路徑應該不多見吧？
[英] Arne Brasseur／工程師可以怎麼讓自己「升級」？
原文連結｜閱讀時間：5-10 分鐘
認真的工作者都很在乎如何提升自己的技藝，工程師也不例外。本文是我的同事 Karen 推薦的，作者是工程師 Arne Brasseur，他建議工程師可以朝幾個方向去讓自己「變強」：
- 閱讀大量程式碼。可以優先讀那些你會用到的 library 或程式語言，看他們是怎麼做的。
- 大量閱讀有兩個好處：你可以了解其他人怎麼解決問題，有的 library 之所以受歡迎，就是因為他們做得很好。藉由閱讀這些程式碼，可以知道程度比你好的人是怎麼做的。另一個好處是你可以多了解系統的下一層，了解你程式碼底下一到兩層的運作方式有助於你寫出好的程式。
- 工程師很重視速度與效率，然而打字速度很少會是瓶頸，工程師花最多時間的是觀察每次的改動會讓程式在系統上運作起來有何不同，也就是收集 feedback，看程式碼到底在做什麼。Brasseur認為急著做一堆低品質 iteration 只會導致你用相對暴力的手段在寫程式⋯⋯應該要慢下來，在專案早期就先慢下來，想一下怎麼收集 feedback 會更好、更有助於解決問題。
- 閱讀文件。Brasseur 認為閱讀技術文件跟一般的閱讀不同，是另一種獨立的技能，這種挑戰集中力的技能可能在快步調的今日讓人感到生產力低落，但 Brasseur 鼓勵讀者不要這樣想，在站立會議上告訴大家你昨天下午都在閱讀沒什麼好奇怪的，那就是工作的一部分，高品質的解決方案來自理解與經驗，程式碼只是在其他所有事情都搞清楚之後才要做的事。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
