科技創業週報 #341:誰來告訴我,軟體工程師沒有受到詛咒?

| |

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 嗎?

[中] luikore/Hello,機械鍵盤

本文是 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、可編輯的連結、數據分析、分享到社群等等, 才能在短短半年內上線。

另外他也提到身為主管,每每洞察到新事物,就想調整策略,似乎是一種進步,但常常只是自我感覺良好,彷彿自己有很大的影響力,但通常只是在浪費團隊的時間。他建議領導者多花時間認策略是不是正確的、有無意義,戰術可以調整,但改變策略需要更謹慎。最後他還提到,維護高度的一致性能讓如他一般的設計腦、工程腦心滿意足,但隨著組織擴大,堅持一致性可能得在某些方面付出鉅額代價。

[中] MasterPa/一個被封裝的未來

本文作者用軟體的「封裝」概念,比喻我們生活在一個完美而無法被理解的世界,觀點頗具警世意味。從智慧型手機到導航軟體,科技讓所有事物都變得更簡單、操作起來更優雅,靠的是背後更複雜、更細緻的技術跟分工,一般使用者、甚至開發者,可能都愈來愈難掌握技術原理或瞭解事物全貌,導致事物愈來愈難懂,如果不放棄思考的話該怎麼面對呢?推薦給曾經浮現這種疑惑的讀者。

🎧 對這個議題有興趣的讀者,也可以參考〈《星箭廣播》72 集——用手機點個 Uber Eats,也會造成社會「加速」?

[英] 誰來告訴我,軟體工程師沒有受到詛咒?

這是一篇「求救」短文,作者是一位很沮喪的工程師。他說自己 40 歲,很擅長 Java。他知道技術一直在改變和演進,但是他無法接受因為東西要上 AWS,就得把過去鑽研、累積起來的知識跟最佳實務都拋棄,然後重新發明輪子。「我很擅長 SQL,但沒人在乎,大家只想用潮潮的 MongoDB。」他覺得這是一種軟體工程師的詛咒,自己想要的不是每五年就變一次的工具,也懷疑自己是不是太老了。他預言最終大家會醒悟,發現 AWS 是個錯誤,然後再度把新技術當成有史以來最偉大的東西,「因為軟體工程師被詛咒了。」他在結尾寫道。

跟作者有相同疑惑和煩惱的讀者可以點進連結看看其他人的回應,例如有人建議探索新技術時可以先專注於享受學習的樂趣,別去思考要怎麼運用在工作上;也有人不同意作者的觀點,表示並沒有什麼主要的軟體技術正在很快消失或是被取代,它們會持續很長一段時間。還有一位工程師建議大家這樣想:技術會改變,而且改變的方向往往不會是你所樂見的。


.

(文章代表圖:Photo by Matthew Henry on Unsplash

本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
Previous

星箭廣播 164 集——思考本身比寫下什麼更重要:卡片盒筆記實戰經驗分享(ft. 小朱)

發佈留言

Share via
Copy link
Powered by Social Snap