科技創業週報 #324:Google 搜尋正在死亡

| |

Hihi 讀者,

昨天在 BBC 讀到一個荒謬絕倫的報導,一名英國人 Ali Ayad 利用了全球疫情期間「遠端工作」只開音訊的便利性,虛構了一間數位設計公司,在社群網站上捏造了身分,偷走其他公司的作品案例,成功從全球招募了幾十名員工,而且持續運作了超過一年,直到有人因為好奇查詢通勤地點,才發現辦公室地址根本不符老闆所言,後來她與其他同事一起拼湊出真相,並向媒體揭露⋯⋯最後記者還真的堵到這位老闆,大家可以點開報導最後的影片看看。

這個劇情宛如最近紅翻天的美劇《創造安娜》、《Tinder 大騙徒》跟《國王豪華音樂節》,而未曾見面的同事們集體揭穿老闆的過程,又像《別惹喵皇》中透過 Google Maps、查看影片玄機抽絲剝繭追兇手的網友。(這期的電子報搞得好像 22 世紀騙子影集清單呀,如果讀者也有看過類似的作品,歡迎推薦給對這種題材百看不膩的編輯 🥸)

lily


.


[英] 永別了,無瑕的程式碼

寫出「無瑕」的程式碼也許是很多成熟工程師的追求,React 框架核心創造者Dan Abramov 也不例外。讀到冗贅、重複的程式碼,他就止不住想將它改得更精煉、更簡潔的渴望,但多年前的一次自主修改同事的程式碼,並未受到讚賞,反而。這個經歷讓他對追求「無瑕」的程式碼改觀。

Dan Abramov 在這篇文章列出這段程式碼的原始版本與經他修改的版本,說明他犯的兩個錯誤:一是擅自改動程式碼卻未告知團隊,二是儘管程式碼變得簡潔,在未來卻不見得比較好維護,工程師學到「抽象」概念時,自然而然會很熱切地提高程式碼的品質層次,但這並不應成為「目的」。要如何調適對無瑕程式碼的執念呢?來讀讀 Dan Abramov 的心路歷程。


[英] 單飛創業者的生產力妙計——今日事不要今日畢

在公司團隊工作時,總有不同職能的同事隨時可以討論點子或抱怨紓壓,但單獨創業時,雖然自由但也代表大部分時候所有事情都只能一人扛。Zach Holman 結束 GitHub 的工作、選擇單飛創業,在這篇文章中他描述了自己如何處理孤獨感,以及在「一個人」,怎麼維持生產力的方法。

有一點特別有意思,每天他總是會刻意「不完成」某個待辦事項,通常都是剩下 5-15 分鐘就能解決的輕鬆任務。下班時想到這個任務,他會感到輕鬆,而不是工作的苦悶跟壓力;而且這個簡單的任務也會變成隔天啟動工作的暖身操,這種簡單完成一件事的篤定感,對克服一整天的挑戰很有幫助。另外,他也分享,自己在沖澡時就會開始「每日站立會議」,並把一般站立會議的問題從「我今天要做哪些事」重塑成「我今天可以完成哪些事?」,這樣的自問有效解決了事情永遠做不完的泥淖。而在工作的日子裡,難免還是會有崩潰、憂鬱的時候,他又有什麼方式處理這種僵局呢?這篇文章的生產力之道比較少見,但說不定對你有些作用!


[Podcast] 星箭廣播 EP146 |「我們聽什麼?」特輯 3:六檔科技 Podcast 推薦!

這次三位主持人要來跟大家分享他們最近收聽的幾檔科技相關節目。Titan 要分享的是訪談型節目《Lex Fridman Podcast》,主持人 Lex Fridman 是一位在 MIT 工作的科學家,節目來賓們來頭都不小:創業者、明星工程師、學者和格鬥家⋯⋯ 其中不乏諾貝爾獎和圖靈獎得主,Elon Musk 甚至擔任過三次來賓。

Julie 推薦的節目都跟產品故事與矽谷科技公司有關。一個是 Spotify 自製的《Spotify: A Product Story》,聚焦產品幕後鮮為人知的故事,第二個可能老聽眾們會覺得有點熟悉,留給大家自己去發現 XD 第三個則是由一對在西雅圖工作的台灣人夫婦主持、講中文的《矽谷輕鬆談 Just Kidding Tech》 。

Liz 推薦的是《Design Details》,兩位主持人分別在 GitHub、YouTube 擔任設計師,節目大多都在解答網友的疑難雜症,偶爾邀請其他設計師聊天。另一檔節目《Non-Technical》訪問眾多科技圈不同角色,從設計師、記者到創投,什麼都聊、什麼都講,唯一的限制就是「不聊任何跟履歷有關的事情」,訪談氣氛輕鬆,充滿各式矽谷文化笑料。


[英] 特斯拉螢幕介面設計有什麼問題?

「喂,防霧功能到底在哪裡?」Scott Jenson 在 UX 設計領域有著超過 30 年資歷、曾經參與蘋果、Google 大型專案。去年他第一次嘗試駕駛 Tesla Model 3,卻在一開始就遇到難題,瞪著控制螢幕老半天,但選單列只有一排意義不明的圖示,找不到需要的功能,最後才發現要發聲控制。

儘管使用聲控,但螢幕介面的設計當然還是不能忽視。Scott Jenson 提出了幾個設計「駕駛操作介面」時應該注意的地方。例如,螢幕上兩個按鈕同時並存時,其實會造成「負空間」(negative space),這是所謂的「1+1=3」心理效應,對使用者來說,兩個按鈕會多創造出第三個物件,加深困惑感。此外,傳統汽車的按鈕之所以長期維持「實體」而不全面改用扁平化的觸控螢幕,也還是有其作用的。


[英] Google 搜尋快死了

你也覺得最近用 Google 搜尋時,越來越多廣告、內容農場或垃圾資訊出現在比較前面的排序嗎?作者對此有深刻的感受,並在文內分析為什麼 Google 搜尋正在邁向死亡,也指出 Reddit 現在反而是更好的搜尋引擎。比起 Google 搜尋結果的品質惡化,有人點出其實是我們對搜尋結果的「信任度」變低了。本文引起熱烈討論,在 Hacker News 一週累積超過 1500 則留言,文內也有 Google 員工的解釋,不過使用上的直覺感受又是一回事啦😉

💡作者的應對方案是「關鍵字+site:reddit.com」,編輯自己平常在搜尋也是這樣做,並視情況換成其他論壇或社群,例如 ptt。最近則在試用新的搜尋引擎 Kagi,再找機會跟大家聊~也歡迎跟我們分享你的搜尋撇步或是愛用服務📪


[中] vgod/軟體工程師的修煉與成長 (3) — Oncall的挑戰

軟體工程師在大型軟體公司 on-call(值班)最可怕的是時間壓力,因為商用軟體對於服務水準協議(SLA)有嚴格要求,假如要求 99.9% 時間都能正常運作,等於每週故障時間的「額度」只有 10 分鐘,遑論要求更高的系統。作者 vgod 以自己當年的新人經驗為例,指出軟體工程師若只關注自己的工作,對於團隊負責維護的「整個」產品和系統不夠熟悉,on-call 期間若有狀況容易很緊張,他還發生過半夜要向資深同事求救的情況。

當他轉到別的團隊後,發現其實是原本團隊的制度不夠成熟,例如警報要區分等級,要有明確的 playbook 等等,而且很多導致 on-call 令人緊張的原因是可以從團隊開發流程去改進的。vgod 曾經寫過「追求神乎其技的程式設計之道」系列文章共 12 篇,主要是記錄他從高中到大學期間學習寫程式的心路歷程,相信不少讀者讀過,而「軟體工程師的修煉與成長」則是新的系列,分享他到 Dropbox 成為全職的軟體工程師後的成長經驗,目前寫到第三篇。前兩篇談的是從程式設計師與軟體工程師的差異,以及系統的規模與複雜度。


[中] Glen Yeh/前進矽谷:Google 產品經理面試流程 & 策略

作者是商管背景的土生土長台灣人,曾在 LINE 擔任產品經理,也累積三年在美國擔任 Amazon 和新創公司的 PM 經驗後,最近面試了 Google PM 的職位並通過 On-site 面試。本文分享詳細的面試過程和回答策略,其中他提到 Google 和其他如 Facebook 等公司最大的不同在於後續追問很靈活,有時甚至故意引導應徵者脫離既有的架構。

作者認為,雖然 Google PM 必須經歷技術面試,而且是對文組及商管背景投報率極低的系統設計,但也讓他有機會重新複習 PM 的基礎知識,並且從技術角度更了解自己現在做的產品。


[中] Shawn /1 個月內累積破萬使用者:大學科系查詢 LINE 機器人製作過程分享

作者是高三生,因為覺得翻大學申請紙本簡章、整理志願標準和面試日期很麻煩,便在考完學測的寒假期間製作一個 LINE bot,只要傳送指定大學科系就會回傳個人申請和繁星標準的資訊,還可以一鍵加入 Google 行事曆或收藏,不到一個月就有一萬名使用者。他分享了設計架構的思路和寫 code 的過程,包括怎麼抓到同學的痛點、使用的語法和資源、遇到的瓶頸與解法。

像是機器人公開後經過兩次使用者暴增潮,作者後期是怎麼改善程式碼執行速度?另外,像是使用者習慣將資訊工程學系簡稱「資工」,但校系的縮寫太多種難以涵蓋該怎麼解決?這是他第一次自己建立這麼多使用者的成品,也提供想開發類似聊天機器人的讀者參考⚡️


.

(文章代表圖:Photo by Nathana Rebouças on Unsplash

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

星箭廣播 147 集––從 🟨🟩 聊到 Web3:我們進入技術革命的轉折點了嗎?

星箭廣播 148 集——原本要推薦五檔「不科技」Podcast

Next

發佈留言

Share via
Copy link
Powered by Social Snap