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 國際釋出