Hi 讀者，
近期一大新聞是查理·蒙格（Charlie T. Munger）過世，先前負責重新出版《Poor Charlie’s Almanack: The Essential Wit and Wisdom of Charles T. Munger》（中文版譯為《窮查理的普通常識》）的 Stripe Press 特別設計了一個網站將全書的內容公開，還提供可以調整語速的朗讀功能，對於書籍本身沒興趣的讀者也可以去參觀一下網頁設計（別忘了試試看「波克夏模式」 ）。
另外一個想跟大家分享的是我很喜歡的 Markdown 寫作軟體 iA Writer 最近推出新版本，加入（手動）區別真人與 AI 生成內容的標示設計。使用者可以在 iA Writer 中將那些自 ChatGPT 複製而來的文字標記為 AI 所作（會以淺色呈現），之後由真人作者修改的部分則會自動以深色標記，藉以區分哪些是真人寫的，哪些是 AI 寫的。iA 開發團隊在新聞稿（內有影片）寫道：「By splitting what you type and what you pasted, you can make sure that you speak your mind with your voice, rhythm and tone. （藉由區分親自打字的和複製貼上的內容，可以確保你是用自己的聲音、節奏和語調表達自我。）」以這個功能做為對「在寫作上運用生成式 AI」趨勢的回應，我認為是很不錯的嘗試。對這個設計背後理念感興趣的讀者，也可以參考他們的文章，例如這篇和這篇。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] Teddy Chen／愛上 Mob Programming（下）
原文連結｜閱讀時間：10 分鐘
這篇寫於 2021 年的文章是我以前在找資料時發現的，才知道原來除了 pair programming（結對開發）外，還有 mob programming（群體程式設計，有時也叫 mobbing）。起初我的反應跟本文作者、Agile 教練 Teddy Chen 在系列文章的上篇一樣：「整個團隊綁在一起用一台電腦開發，真的假的？！」所以假如你跟我一樣對這種開發方式感到陌生，不妨讀一下 Teddy 的系列文章，看看他（當時）使用七個月、超過 500 小時後對於 mobbing 的理解與感想。
本文是 Teddy 從敏捷和精實開發的角度來分析，為何 mob programming 很值得。Teddy 先將開發工作（無論多少人一起開發）區分成兩種模式 component development 和 end-to-end development，再分析單人和雙人開發兩種模式的特性和限制，而 mob programming 的特點是「團隊成員每個人同時間都貢獻他自己最強的能力在同一件事情上面」。Teddy 在文中以團隊開發一個 kanban（看版）軟體的註冊功能為例，比較跑 scrum 與 mobbing 的差別。不知道有沒有讀者的團隊也使用 mob programming？歡迎跟我們分享你的心得。
[英] Luke Hsiao／當你的文章登上 Hacker News 首頁，會帶來多少流量？
原文連結｜閱讀時間：5 分鐘
我們知道 Y Combinator 旗下的 Hacker News（下稱 HN）是科技人很常造訪的社群新聞網站，你註冊一個帳號就可以去貼文，而它們使用一套排名演算法來決定哪篇貼文可以登上首頁，成為一段時間內科技世界的焦點。那麼一篇登上 HN 首頁的文章會帶來多少流量呢？本文作者 Luke Hsiao 是一位工程師（有沒有覺得這個名字很熟悉？），他在 11 月底時有篇文章登上 HN 首頁，該文就是我們上週分享過的「為自己的房子寫技術文件」，非常受到大家歡迎，在 HN 累積 715 點、超過 300 個評論。
Hsiao 在文章分享了幾項數據和圖表，包含網站流量、PV、訪客數、地點和流量來源等等。以流量來說，Hsiao 將網站託管在 Netlify，文章的大小大約是 200 多 KB，在文章登上 HN 首頁期間，產生了 83GB 的流量（幾乎快把 Hsiao 每月 100GB 免費方案的上限用掉），相當驚人。至於 PV 跟訪客數，大家不妨可以猜猜看會是多少。另一個有趣的數字是地點，Hsiao 列出了 PV 最高的七個國家，除了第一名的美國之外，大家也可以猜猜看第二名是來自哪裡（提示：不是英語系國家）。不過在辨識流量來源方面出現令 Hsiao 感到意外的問題，或許工作內容與此相關的讀者可以參考。Hsiao 不只分析自己的數據，還收集了十幾個網路上不同時期分享 HN 帶來多少流量的文章。有興趣的讀者可以去找來看看。
[Podcast] In Depth／新手技術主管可以換個角度看待頑固的工程師
原文連結｜閱讀時間：78 分鐘
《In Depth》這集節目的主題與技術主管的領導力有關，包含如何在不同公司運用過去的經驗、建構策略（和文件）、針對工程團隊的指標設定、如何與高層溝通等等。來賓 Will Larson 是股權管理平台 Carta 的 CTO，過去在 Calm、Stripe 和 Uber 等公司擔任過各種技術主管，出版過《The Engineering Executive’s Primer》（工程主管入門手冊）等寫給工程師和技術主管的書籍。Larson 在節目中分享了他在不同類型軟體公司的經驗，提出許多精彩的洞察，相當值得收聽。
Larson 提醒新手主管，轉換到新公司後不要冒然套用前公司的做法，最好先做一些測試，觀察大家的反應再進行下一步。以軟體架構遷移為例，他在 Calm 的時候決定取消從單體式（monolith）遷移到微服務，但是到了 Carta 的時後卻做出不一樣的決定。這一段特別有意思的是他與團隊溝通的過程中，遇到「無法說服」的工程師時帶給他的學習經驗：看似頑固的工程師，可能也是對各種脈絡和前因後果有最深刻理解的人。
另一件 Larson 提出的觀察是，很多公司會把各種小事做成記錄，但重要的商業決定（例如我們為何要收掉某個服務？）、策略和工程文化卻不見得會被寫下來，比如說 Uber 對於不同問題會選擇使用不同程式語言，但 Stripe 卻偏好使用同一種語言，Larson 說自己過去就沒有看過這些事情被寫下來。Larson 也在節目後段提到自己在觀念上的改變，過去他認為身為技術主管要「保護工程師」，也就是說某種程度與公司其他事務隔絕，但後來發現長期而言其實有害，於是改變做法。原文連結有逐字稿，影片版也提供詳細的時間軸，將節目分成二十幾段，讀者可以善用這些內容資訊。
[英] Marty Cagan／你說不想要有「產品經理」，我們來看看有哪些替代方案
原文連結｜閱讀時間：10 分鐘
我們過去推薦過好幾個「沒有產品經理怎麼開發產品」的案例，那麼一般來說有哪些替代產品經理的方案呢？本文作者是 Silicon Valley Product Group（SVPG）創辦人 Marty Cagan，藉由審視產品經理這個角色的幾個替代方案，再次探究真正的產品經理對於產品的成功扮演什麼樣的角色。感謝我的同事 Karen 推薦本文。
Cagan 在文中明確指出產品經理的角色跟工作核心——對（產品）價值（value）與業務可行性（viability）負責——也就是產品管理，在產品開發過程中無可避免，一定得有人來做。（編按：前文的「價值」指的是產品有沒有符合客戶/市場需求，進而讓他們買單；「業務可行性」指的則是從銷售與各種公司業務營運層面相關問題角度來看產品是否可行。）
文中分析了幾個「產品經理替代方案」的利弊，一種是由創辦人和利害關係人負責產品管理，另一種是由團隊的其他成員（例如產品設計師或是技術首席）接掌；不過 Cagan 花最多筆墨談的是產品領袖驅動的產品管理，認為在特定情況下這會是極度有效的替代方案，而這個特定情況的案例之一就是蘋果公司。Cagan 分析了蘋果的業務特性，以及由具備深厚知識與豐富經驗的產品主管肩負產品管理責任，背後的好處以及可能的問題（這些人可能是決策的瓶頸，而蘋果恰好不以快速行動聞名）。
本文與我們在第 16 期和第 17 期的內容有關（關鍵字：產品經理），Cagan 認為 Lenny’s Podcast 訪談 Brain Chesky 那一集為業界聽眾帶來的問題其實與答案一樣多，也可說是促成本文的原因之一。事實上 Cagan 寫了兩篇文章，第二篇是探討產品領袖（product leader）的替代方案，結合這兩篇文章，Cagan 認為讀者應該可以了解他對於 Brian Chesky 說法的回應會是什麼。但我想這兩篇文章也是可以獨立閱讀的，所以千萬不要因為沒聽 podcast 就跳過這篇好文啊！XD 對於產品管理相關議題感興趣的讀者，也可以參考 Cagan 寫的專書。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
