Hi 讀者，
你是科技樂觀主義者嗎？本週想跟大家分享兩個既是過去也是未來的科技趨勢話題。
「Stay Hungry. Stay Foolish.」是賈伯斯在著名的 2005 年史丹佛大學畢業典禮演講結尾中引用的一句話，來自他稱之為「1960 年代晚期的 Google」、雜誌《Whole Earth Catalog》最後一期。但其實那句話是印在 1974 年出版的《Whole Earth Epilog》封底，但不管怎麼樣，這兩本雜誌和「Whole Earth」系列刊物的數位掃描檔在幾天前上線了，不但可以免費閱讀，你甚至可以下載整本雜誌的 PDF。
《WIRED》雜誌在報導前述「Whole Earth」系列刊物數位版新聞時，稱《Whole Earth Catalog》在當年「是科技樂觀主義者（techno-optimists）的燈塔」，巧的是，就在幾天後，創投 a16z 共同創辦人 Marc Andreessen 發表了一篇文章〈The Techno-Optimist Manifesto〉（科技樂觀主義者宣言），還將 《Whole Earth Catalog》創辦人 Stewart Brand 列入文末的「科技樂觀主義守護神」名單。（Stewart Brand 本人沒有對名單發表什麼意見，但是有些別的回應。）
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[Podcast] 數位關鍵字／數據團隊真重要？公司設置數據長都在忙些什麼？
原文連結｜收聽時間：25 分鐘
繼「公司內部數據團隊被當作『數據 ATM』」議題之後，ALPHA Camp 共同創辦人 Youchi 再度到《數位關鍵字》podcast 102 集擔任節目來賓，從各種角度和層面談到數據長（CDO）這個職務的設置與工作內容，例如數據長與更早就存在的資訊長、技術長，在主要的工作內容上有何不同？又或者在一些公司是由資安長來看顧的「數據」，如果交給數據長來管理，背後的意義有何不同。
當一家公司需要數據長的時候，其實代表公司營運已經到了另一個階段，那麼一家公司在什麼情況下需要設置數據長的職務？或是說「何時」應該要在組織內設計這個職務？對此 Youchi 分享的其中一個思考點是：當你觀察到組織內部各部門「數據孤島」的問題變得很嚴重時，就是一個值得去思考是否需要數據長來改變局面的時機。
[英] Nikita Prokopov／軟體開發者，你必須了解的 Unicode 最低限度知識
原文連結｜閱讀時間：15-20 分鐘
原文標題是為了致敬工程師、Stack Overflow 共同創辦人 Joel Spolsky（他開發的另一個知名產品是 Trello）在 2003 年寫的文章〈The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)〉，該文從 ASCII 和其他字元編碼方案的歷史說起，再談到 Unicode 的基礎知識，文中有一句名言：「There Ain’t No Such Thing As Plain Text.（沒有所謂純文字這種東西。）」（因為要視編碼而定）。本文作者 Nikita Prokopov 是 Roam Research 的軟體工程師，他說當年的問題是「這是什麼字元編碼？」二十年後的今天，問題已經變成是「如何正確使用 UTF-8？」
本文維持 Prokopov 一貫圖文並茂的風格，他先從 Unicode 開始談起，讀者可以看看文章前面以視覺話方式表達 Unicode 有多少碼位（code point）和使用情形。接著 Prokopov 再談到 UTF-8、UTF-16 和 UTF-32 等編碼，還有幾個有趣的問題，例如為什麼會出現�？各種程式語言因為內部字串表示不同的關係導致回答「🤦🏼♂️字串長度是多少？」有不同的答案。文章後段也會以斯拉夫語系和亞洲的 CJK 為例，討論到相同的 Unicode 編碼在不同地區設定下在電腦螢幕前會「長得不一樣」。（大家可以點進原文看看「返」這個字有幾種變化 XD）
Prokopov 在文章最後總結道，Unicode 雖然不完美，但是：1. 的確可以涵蓋所有可能語言 2. 全世界都願意使用 3. 我們大部分情況下可以不用管編碼問題。Prokopov 認為這是一個奇蹟，所以二十年後的今天，他想回應 Spolsky：「的確有純文字這種東西，而它是以 UTF-8 編碼。」我們也很推薦不是工程師的讀者閱讀本文，或是其他 Nikita Prokopov 寫的文章，例如這篇〈Time to upgrade your monitor〉。
[英] Sheon Han／是時候建立「軟體評論」文化了
原文連結｜閱讀時間：15 分鐘
我們有書評、樂評，那麼「軟評」呢？這是一篇今年二月發表的文章，作者 Sheon Han 是 Hugging Face 軟體工程師。他主張：我們應該要發展「軟體評論」的文化，要像評論一瓶葡萄酒、一款汽車或是一座建築那樣去評論軟體，做批判性分析（critical analysis）。文中先點出軟體評論並不是科技評論，告訴讀者為什麼軟體值得被評論，卻又遲遲沒發展出評論文化，以及這樣的評論該怎麼寫、誰可以當評論家等等，更重要的是為什麼是現在去發展這個文化？軟體評論有沒有可能發展出一種新的文體？
軟體評論跟科技評論不同，後者已經行之有年，從以前的 Lewis Mumford（生於 19 世紀末的美國歷史學家、著名文學評論家）、麥克魯漢到「VR 之父」Jaron Lanier 等都可以說是科技評論家，近年大家熟悉的著作《監控資本主義時代》（The Age of Surveillance Capitalism）也屬於科技評論。軟體評論則不同，要更加集中審視單一軟體作品，就像2008 年 Nicholas Carr 寫的文章〈Is Google Making Us Stupid?〉（Google 讓我們變笨了嗎？）
Han 也正面回應一些實際的問題：例如軟體一直改版，永遠不會像一本書或一部電影那樣「完成」，這樣怎麼寫 Han 理想中的評論？他認為可以借鏡葡萄酒或是汽車評論的方法，針對不同年份或款式去評價，又或者像評價餐廳一樣隔個幾年之後回訪，有些令人難忘的評論就是這樣誕生的。
以 Google Docs 為例，Han 說評論家可以從寫作這項勞動的文化史開始寫，再到 Google Docs 是怎麼為後來的即時協作軟體如 Figma 或 Colab 奠下市場基礎，當然還有關於 conflict-free replicated data type（CRDT）的研究，以及 Google Docs 在文化和社會方面又代表什麼意思。事實上，本文發表後的幾個月，Han 自己就在 WIRED 的專欄寫了一篇 Google Docs 的「軟評」，讀者可以看看跟一般的評測有何不同。
[英] Will Larson ／設計工程團隊衡量指標，四個方向與六個常見錯誤
原文連結｜閱讀時間：15 分鐘
本文作者 Will Larson 是股權管理平台 Carta 的 CTO，過去在 Calm、Stripe 和 Uber 等公司擔任過各種技術主管，寫過幾本以工程師和技術主管為讀者的書，本文是《The Engineering Executive’s Primer》（工程主管入門手冊）這本書的其中一章。
當 CEO 要求身為技術主管的你交出一些衡量工程團隊績效的指標時，你該怎麼做？Larson 認為可以先思考：為了讓工程團隊有效運作，你需要哪些必要的資訊？他建議從四個不同面向著手，去思考設計衡量指標的目的：為了規劃、營運、最佳化，以及激勵團隊。（還記得上一期提到的自誇小本本嗎？XD）
文中提到組織內部有許多利益關係人（例如 CEO 或財務部門等）需要你提供各種指標數字。Larson 在文中分析了幾種情況，像是 CEO 未必有技術背景去管理你的技術決策，因此他會把你執行這些目標的能力視為一種評估你領導力的代理指標，有可能還會特別關心這些目標對於公司商業策略的貢獻，這時你應該考慮使用前面提到針對規劃與營運的衡量指標；但他也提醒，別讓 CEO 用你為了最佳化而設計的衡量指標來檢視團隊表現，因為那些指標反映的結果固然在工程上有影響力，在商業上則未必。
文章後半段，Larson 提到六項關於設計衡量指標常見的錯誤。例如第一項：有時候 CEO 關注工程指標的背後，代表的是他跟你這位工程主管之間缺乏信任，所以會不斷跟你要各種指標，你給了一個，他就再要一個新的。不過我們建議讀者在閱讀這一段的時候要注意，因為 Larson 似乎在行文上有些不一致，例如他要談的是常見錯誤，所以會先寫出「錯誤」，再提供解釋和正確做法，但有時他會直接把正確做法或建議先寫出來，例如前面提到的第一項，又或者第二點「別讓完美阻礙進展」其實就是正確的。
對於衡量工程團隊績效議題，我們曾經推薦過相關文章，當時麥肯錫提出的方案在網路上引發很大的爭議，感興趣的讀者可以參考看看。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
