Hi 讀者，
颱風將至，希望大家都平安。本週我們推出了第一篇 RISE-UP 專訪文章，主題是軟體工程師如果加入「非純軟」公司會遇到哪些文化差異，又該怎麼克服這些挑戰。為此我們採訪了工程師 Ernest Chiang，請他以軟體人的角度分享經驗並且給予建議。
不知道你心中有沒有一張名單叫「這個網站我以前很喜歡」？最近我讀到一篇令人感傷的文章，是關於紐約時報旗下知名的產品評測網站 Wirecutter，最近有越來越多人認為他們的內容品質正在走下坡，原本可以放心購買的推薦商品都成了地雷，於是作者便以 Wirecutter 的精神來研究一番，沒想到事情比他想像的更加複雜。
本週最後一篇文章是由讀者 davipon 推薦，談的是「如何衡量開發者的生產力」，假如你也是軟體開發者，這應該是一個很值得思考的問題。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] Titan／軟體人如何克服「非純軟」文化差異？關鍵在「舉手」心態
原文連結｜閱讀時間：15-20 分鐘
並不是每一位軟體工程師都會加入「純軟體」公司。在台灣，不僅許多傳統產業正著手數位轉型，半導體產業對於軟體工程師的需求也在增加。然而「軟」「硬」團隊從工作方法到文化，其實都有不小的差異，假如一位軟體工程師要加入「非純軟」公司，會遇到哪些挑戰？
我們採訪了工程師 Ernest Chiang，他目前任職於國內專注於健身器材解決方案開發的 PAFERS 派仕科技，擔任產品與技術整合總監，過去曾經任職於台積電、擔任製程整合工程師，在各大技術社群也相當活躍。我們請他以軟體人的角度，談談該如何預期、適應軟硬整合團隊的工作環境與文化。藉由 Ernest 的職涯發展，希望提供足夠的脈絡，讓讀者明白為何他會給出這些建議。
[英] Charlie Warzel／追求規模化毀了產品評測網站 Wirecutter 嗎？
原文連結｜閱讀時間：15 分鐘
成立於 2011 年的 Wirecutter 是全美最負盛名的產品評測網站之一，他們使「推薦型內容」更加受歡迎，讀者在讀完長篇的深度評測後，點擊聯盟行銷連結（affiliate link）購買產品，Wirecutter 就能從每次的產品銷售中賺取一小部分報酬，這種商業模式令他們不那麼仰賴廣告，也更令消費者信賴——唯有信任他們的讀者不斷回來尋求商品推薦，Wirecutter 才能賺錢。他們很有個性，被認定是壞產品的東西他們還會告訴讀者離它遠一點。文章裡用一個玩笑來顯示該網站的態度——當你問：「最好的貓是什麼貓？」Wirecutter 會告訴你：「什麼貓？你有考慮過狗狗嗎？」
Wirecutter 的產品評測可不是隨便寫寫，例如他們的衛生紙評測是由領域專家測試至少五十個小時後的產物，而且不斷更新，幾年前的首選品牌如今已是被嫌棄的產品。Wirecutter 的另一個機制是外部作者稿費「以小時計費」，不是字數，也不是固定價格。然而近年開始有讀者發現 Wirecutter 的內容品質似乎不如以往，導致讀者常常買到地雷產品。網友們將矛頭指向 2016 年紐約時報的收購案，當時他們以三千萬美元買下 Wirecutter。
本文作者 Charlie Warzel 現在任職大西洋月刊，本身也是 Wirecutter 的忠實讀者，買過一大堆該網站推薦的產品。他決定發揮評測網站的精神深入調查這個「走下坡」現象是否屬實，不僅花費 20 小時閱讀大量 Wirecutter 評測文章，採訪網站創辦人、前任與現任員工，甚至取得紐約時報的回應。最終他發現，原來 Wirecutter 的故事不僅與網站內容、紐時經營方針變化有關，還反映了過去這些年來網路的變化。
至於最初的那個問題：Wirecutter 是否變得不可靠？Charlie Warzel 認為答案是「充滿矛盾的『Yes』」。
[英] Zach Lloyd／程式碼優先還是產品優先？
原文連結｜閱讀時間：5 分鐘
這是一篇 2019 年的文章，作者 Zach Lloyd 是終端機軟體 Warp 創辦人，他在創業前曾是 Google Docs 的 principal engineer。本文談到「程式碼優先」（code-first）與「產品優先」（product-first）兩種工程師，Zach Lloyd 說他更喜歡跟產品優先工程師一起工作。
在 Zach Lloyd 看來，程式碼優先工程師著迷於程式本身如何架構、使用的語言和函式庫、測試覆蓋率、追求完美的抽象化⋯⋯簡而言之，他們很喜歡寫程式。產品優先的工程師當然也重視這些，但他們只把寫程式當作一種（做好產品的）手段，程式碼固然重要，卻不是好產品的全部。Zach Lloyd 相信，做出正確的技術選擇、把程式寫好，是為了最終的那個好產品，而不是為寫（程式）而寫。「如果產品運作有問題，那就不是好的程式碼。」Zach Lloyd 寫道。
他在文章後半段還加入另一件事的討論，認為產品優先的工程師重視的是「能不能儘快把東西做出來」，也就是速度。然而工程師們未必同意，Hacker News 上就有不少人認為作者的命題不恰當，追求快速或許是新創公司存活的關鍵，只是求快有副作用，最終還是會回過頭來打擊你；也有人認為這兩種心態可以並存，對彼此都有互補的作用。不知道讀者們你怎麼想呢？
[英] Gergely Orosz、Kent Beck／為何麥肯錫衡量開發者生產力的方法有問題？
原文連結｜閱讀時間：15-20 分鐘
本文的主題有點敏感：衡量開發者的生產力。兩週前，麥肯錫發表了一篇文章，標題是〈沒錯，你可以衡量軟體開發者的生產力〉（Yes, you can measure software developer productivity），此文引起 Substack 上兩大工程師主題電子報作者 Gergely Orosz 和 Kent Beck 的關注，前者我們在這篇文章有介紹過，後者則是有數十年產業經驗的工程師。
簡而言之，他們並不同意麥肯錫提出的方案，甚至你可以在 Twitter 感受到大家對這家知名管顧機構嗤之以鼻。Gergely 跟 Kent 表示他們完全可以理解企業高層如 CEO 和 CFO 為何想要找出一個衡量開發者生產力的方案。Kent 在文章裡很直接地業務主管跟工程主管的進度會議發言做比較，直言工程師作為一個集體，在衡量產出這方面跟其他部門比起來真的比較落後，問責（accountability）程度也是天差底遠。
然而，他們認為麥肯錫似乎搞錯重點。兩位作者先將一個典型的開發週期簡化如下：努力（effort）、產出（output）、結果（outcome），以及影響（impact），把問題重新釐清，從誰想衡量開發者生產力，到為何其他部門的生產力似乎更容易衡量，結果也更加明確，並且比較了 DORA 和 SPACE 兩種框架，再對照麥肯錫的方案，告訴大家後者的作法形同只關心努力和產出，對於結果和影響著墨甚少，這就像 KPI 設定錯誤，後果可想而知。
本文是系列文章第一篇，第二篇將於週四刊登在 Kent 的電子報，重點會放在只衡量產出和結果的危險，以及他們對於「如何衡量開發者生產力」的解方。本文提供大量的參考閱讀，底下的討論也很有意思（例如署名 John Goddard 的留言），有興趣的讀者別錯過了。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
