| Hihi 讀者好， 聽一首歌時你能聽得出來不同樂器的聲音嗎？SplitMySong 這個網站，運用 AI 演算法將樂曲中的鼓、貝斯、鍵盤、鋼琴跟人聲分離，可以直接調整各種樂器的音量，例如單獨聽某首歌曲的鼓聲、或者調整個別樂器的音量大小，真正聽懂一首歌！快來上傳音樂檔案試試看 🎸 lily |
[Podcast] 星箭廣播 EP163 | 工程師怎麼在團隊中打造「技術願景」？也談非管理職的職涯路徑選擇（ft. vgod）
這次我們再度連線到矽谷，邀請任職於矽谷大型軟體公司的工程師 vgod 聊聊「tech lead」的工作與「individual contributor（IC）」的職涯路徑選擇。
延續前幾次的話題，先前 vgod 曾經提到工程師晉升的關鍵之一在於發揮影響力，這次他以自己在團隊中擔任 tech lead 的經驗為例，談談工程師如何在沒有人事權的情況下發揮影響力，以技術帶領團隊。vgod 也會談到他怎麼撰寫「願景」（vision）文件，如何與團隊溝通、說服他們。
節目最後，vgod 會談到他的職涯選擇：「individual contributor（IC）」，這個職涯路徑與另一種屬於管理職的「engineering manager（EM）」有何不同？他在節目最後也解答了一些疑問：選擇 IC 這樣的職涯路徑，是否會限縮將來找工作的選擇？小型軟體或新創公司需要資深 IC 嗎？他們可以提供何種價值？工程師一旦選了 IC 這條路就不能回頭當 EM 嗎？
本文是 2019 年的文章，作者先開了一個「Hello World」類型文章的玩笑，表示本文是機械鍵盤的「Hello World」——雖然説他是要從頭到尾自己做一把機械鍵盤。
作者從鍵盤的構造和原理說起，再談到控制晶片和電路板，以及他怎麼修改電路設計，再交由 PCB 廠商印刷，當然還有「軸」的選用，以及焊接、外殼的設計等等，後面還有提到處理彈跳（debounce）和延遲問題。嚴格說起來本文並不是完整的步驟指南，但是可以大略了解打造一把機械鍵盤過程中所需的各種工具。
本文作者 Rohan Kumar 發現，搜尋引擎使用的索引很集中，以英語世界來說，大多來自「GBY」（Google, Bing 和 Yandex），他試圖整理各家搜尋引擎和索引，按照自行設計的研究方法去分類。讀者可能會在本文發現原來有這麼多各式各樣的搜尋引擎，包含最近幾年獲得矚目的 You.com、Neeva 和 Kagi 等等，他們有些使用大公司的索引，有些則是半獨立、混合使用大公司和自家的索引。其中作者覺得最有趣的是 Kagi，他們開發的「Teclis」搜尋引擎索引採取的方法很特別，其中之一是衡量網頁內有多少元件被 uBlock Origin 擋掉，太多的話就把該網頁踢出搜尋結果。
Rohan Kumar 在文末也解釋了他的動機：今日各大搜尋引擎有些身兼內容和廣告公司，其實這當中有很大的利益衝突，或者說誘因，去影響搜尋結果。另一點則是資訊的多樣性，他希望藉由本文讓更多人去嘗試不同於主流、大型科技公司的搜尋引擎，他自己在研究的過程中也改變了上網的習慣。Rohan Kumar 同樣花了許多篇幅解釋研究方法，也表示文章「廣度先於深度」、會持續更新（他還有列出此文的 changelog），歡迎網友們提供意見。
[中] Daniel Kao／管理系統都好爛，如何管理數位專輯？
作者 Daniel Kao 曾在《天下雜誌》擔任前端工程師，參與了許多互動、數據新聞專題，如台灣疫情資訊網頁、選舉即時開票統計頁面等等，他從改良這些專案的製作流程為出發點，用兩年零碎時間中重整了專題內容管理系統（CMS）。
文中他分析了新聞媒體對 CMS 的需求，像是不同的新聞專題之間共用許多類似元素，也提供了他們使用 Archie ML、Figma、Datasette 等工具分別管理內容、靜態圖與資料的心得；文末更分享了自己為何從不太喜歡寫文件，到深刻感受文件必要性，甚至認為沒留下文件根本就是白做工的原因。所有曾歷經過 CMS 之痛的編輯讀了這篇文章，肯定深有感慨 🙈
[英] 一天到晚改變策略，也許只是自我感覺良好－Stripe 產品主管的營運心得
作者 Sam Gerstenzang 曾在 Stripe 擔任設計營運的角色，帶領過 75 個人的團隊，他從三個面向歸納了自己學到的營運心得，包含戰略跟專注力、提高標準，以及讓每一次的會議都比上次更實在的方法。
他對「專注（focus）」的見解很獨特，人們通常認為專注是指對某件事情集中注意力加速前進，但對他來說，「專注」更具體的意思是刻意放下「某件事情最閃亮耀眼，最讓人心動的部分」。他舉 Stripe 支付連結為例，是因為擱置了許多看似顯而易見、不該沒有的功能，像 QR code、可編輯的連結、數據分析、分享到社群等等， 才能在短短半年內上線。
另外他也提到身為主管，每每洞察到新事物，就想調整策略，似乎是一種進步，但常常只是自我感覺良好，彷彿自己有很大的影響力，但通常只是在浪費團隊的時間。他建議領導者多花時間認策略是不是正確的、有無意義，戰術可以調整，但改變策略需要更謹慎。最後他還提到，維護高度的一致性能讓如他一般的設計腦、工程腦心滿意足，但隨著組織擴大，堅持一致性可能得在某些方面付出鉅額代價。
本文作者用軟體的「封裝」概念，比喻我們生活在一個完美而無法被理解的世界，觀點頗具警世意味。從智慧型手機到導航軟體，科技讓所有事物都變得更簡單、操作起來更優雅，靠的是背後更複雜、更細緻的技術跟分工，一般使用者、甚至開發者，可能都愈來愈難掌握技術原理或瞭解事物全貌，導致事物愈來愈難懂，如果不放棄思考的話該怎麼面對呢？推薦給曾經浮現這種疑惑的讀者。
🎧 對這個議題有興趣的讀者，也可以參考〈《星箭廣播》72 集——用手機點個 Uber Eats，也會造成社會「加速」？〉
這是一篇「求救」短文，作者是一位很沮喪的工程師。他說自己 40 歲，很擅長 Java。他知道技術一直在改變和演進，但是他無法接受因為東西要上 AWS，就得把過去鑽研、累積起來的知識跟最佳實務都拋棄，然後重新發明輪子。「我很擅長 SQL，但沒人在乎，大家只想用潮潮的 MongoDB。」他覺得這是一種軟體工程師的詛咒，自己想要的不是每五年就變一次的工具，也懷疑自己是不是太老了。他預言最終大家會醒悟，發現 AWS 是個錯誤，然後再度把新技術當成有史以來最偉大的東西，「因為軟體工程師被詛咒了。」他在結尾寫道。
跟作者有相同疑惑和煩惱的讀者可以點進連結看看其他人的回應，例如有人建議探索新技術時可以先專注於享受學習的樂趣，別去思考要怎麼運用在工作上；也有人不同意作者的觀點，表示並沒有什麼主要的軟體技術正在很快消失或是被取代，它們會持續很長一段時間。還有一位工程師建議大家這樣想：技術會改變，而且改變的方向往往不會是你所樂見的。
（文章代表圖：Photo by Matthew Henry on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出