《科技創業週報》是由 Star Rocket 於每週三發送的免費電子報，內容涵蓋創新故事與觀點、產品開發技術與經驗的分享、值得一聽的 Podcast 節目與歷久彌新的經典好文。
每則選文都會加上編輯精心撰寫的引文，非常推薦給工程師、產品經理、設計師，或者是所有對科技產業感興趣的讀者訂閱。（訂閱連結附於文末）
| 哈囉讀者： 上週六是每四年才會出現一次的閏日 2/29，不知道大家有沒有在社群媒體上發文呢？（然後四年後才會收到回顧通知 XD）但也因為閏日所帶來的例外狀況，許多程式服務就出現了 bug： 像是美國知名的股票交易平台 Robinhood，在 2/29 之後的兩個工作天，就發生大規模的系統不穩定。雖然他們表示系統不穩定並非因為閏年，但是也有網友指出四年前的同一時間，Robinhood 系統也曾不穩，暗指這四年來他們並未針對這問題做改進。 若想知道閏日在今年為科技業帶來哪些災難，任職於微軟的工程師 Matt Johnson-Pint，有整理一篇在 2020 年因閏日而發生的 bug 列表。而他的部落格中也有一篇頗有意思的文章，在討論閏日 bug 的生命週期。XD by Matt |
| [中] PCMan／在大公司或新創公司工作，會發展出不一樣的技能 不少讀者可能常常在思考要去新創公司還是大公司的經典求職問題，而知名的自由軟體開發者 PCMan，在回覆 PTT 軟體工作版（Soft_Job）上的文章〈如果可以，真的建議不要再去創業公司了〉，就以親身經驗分析大公司跟新創公司的工作環境的異同。 像是新創的步調較快，雖然資源跟時間有時感覺不夠，需要高度彈性、抗壓性，但有較多的機會帶領專案；相反地，大公司雖然制度完善，軟體工程的工作方式與程式碼品質也比較紮實，是學習基本功的好地方，但缺點是個人能展現能力的空間有限。因此 PCMan 也在文末強調：「不同的訓練，有不同的價值，應該兩者並用互補，而不是爭大公司或小公司哪個技術好。」 |
| [podcast] 星箭廣播 EP45｜科技圈重要文件特輯 2：網路女王 Mary Meeker 與她的年度趨勢報告 繼《星箭廣播》43 集之後，這回我們要來聊聊另一份每年都在科技圈獲得高度關注的文件：Mary Meeker 的年度網路趨勢報告。 我們除了跟大家介紹 Mary Meeker 其人，還會告訴大家去哪裡找到這些報告、報告裡有什麼、看不懂那些縮寫該怎麼辦⋯⋯ 當然，還有聽眾關心的問題：我該讀 Mary Meeker 的報告嗎？閱讀這些報告我可以得到什麼？ |
| [中] Andy Chang／有關前端技術的那些 UX 事 – 口罩地圖篇（GIS） 本文作者 Andy 是位前端工程師，這段時間也有參與口罩地圖的社群開發。在這篇文章中，他針對在這次開發口罩地圖的時候他所面臨到的問題：一次讀取過多藥局的地點資訊，導致網頁效能低落。他在文中就從前端開發者的角度，提出在 UX 上能帶來明顯改善，且技術層面也辦得到的解決方案。 作者在文中不僅整理出其他開發者所使用的取捨方式，像是使用熱點圖聚合相近的藥局，或者只呈現離使用者最短距離的藥局；他也一併提出在開發過程中，針對程式效能與 UI 呈現上的思考思路。 |
| [podcast] 資深科技記者對談，一本關於 Facebook 的書是如何寫成？ 資深科技記者 Steven Levy 最近出版了《Facebook：The Inside Story》這本深度爬梳 Facebook 發展故事的書籍，並在出版後引起科技圈的熱烈討論。而他日前在《Recode Decode》也接受 Recode 的共同創辦人 Kara Swisher 專訪，分享有關這本書的寫作過程與內容。 像是因為 Levy 跟 Swisher 兩人都曾專訪過 Facebook 的 CEO Mark Zuckerberg，在節目中也針對 Zuckerberg 這幾年來的轉變交換了彼此的意見。Levy 也針對本書的內容不夠「真實」，對 Facebook 太「溫和」的論點（因為多數訪談是在 Facebook 同意的前提下進行）進行反駁。他們也針對書中的精彩片段進行討論（像是 Zuckerberg 的那本消失的筆記本），很推薦給對 Facebook 或 Zuckerberg 好奇的讀者朋友收聽。 🎧《Star Rocket 科技創業週報》的 Podcast 推薦播放列表，可以透過常用的 podcast 播放器直接訂閱！ |
| [英] Homebrew 專案領導人：開源專案維護者別再燃燒自己，照亮他人 Mike McQuaid 是知名的開源套件管理工具 Homebrew 的專案領導人暨主力貢獻者，而他從自己超過十年的開源參與經驗中，得出一項很深的體悟就是：「開源專案維護者並沒有欠任何人什麼。」會這麼說是因為他發現到，許多開源貢獻者常常面臨過勞的問題：他們覺得有義務要儘速解決使用者所遇到的程式錯誤，但不斷犧牲自己照亮他人的結果，就是導致開源維護者最終失去熱情，並停止維護這項專案。 針對這點為開源圈的活絡帶來負面影響的問題，Mike McQuaid 在文末也提供給維護者、貢獻者與使用者幾項建議。而若對 Homebrew 開發故事有興趣的讀者，也歡迎閱讀我們之前寫過的一篇文章。 |
| [英] 如何成為一名優秀的技術管理者 許多的管理者往往會對工程師有各種負面的刻板印象，像是他們都很自我中心、反社會、很難管理⋯⋯但往往也因為這些先入為主的偏見，導致他們在帶領技術團隊時遇上重重困難。本文作者 Jeff Ello 曾任職於科技業，目前也是美國普度大學管理學院的教授暨 IT 副總監。 他表示，其實管理者應該要先擺脫這些刻板印象，並從技術層面的角度來觀察與思考與工程師的互動，也將工程師跟醫師作對比，指出兩者都是需要在該領域有一定專業，且仰賴持續聯繫與學習知識來維持專業。技術管理者只要尊重並理解工程師所關注的議題，就能有效管理技術團隊。 |
| [英] 透過 DIET 法則，評估並展現設計團隊的價值 在產品開發的過程中，設計團隊的貢獻往往是最難以被評估的：工程師可以透過程式的效能或 bug 數量，PM 可以比較專案結果的完成度與達標程度，而行銷也有像是轉換率等指標。但是設計團隊對產品的貢獻，卻少見有明確的指標作為評估。 資深設計師、DesignOps 經理 Dave Cunningham，根據過往帶領設計團隊的經驗，在本文中中提出了 DIET（Design Impact Evaluation Tactic，設計影響評估手法）這項法則，鼓勵設計團隊在產品開發中的三個階段，針對各 5 個問題進行自評，讓設計團隊一方面能釐清自己對產品開發的貢獻，一方面也向其他成員證明設計所帶來的價值。 |
| [英] 怎麼評估是否引進新技術？Slack 架構師的真實案例分享 在過去的週報中，編輯曾分享過購物平台 Shopify 如何評估採納新技術的時機點。而本文則是由 Slack 的系統架構師 Keith Adams 與 Johnny Rodgers 所寫，他們借用經典的「科技採納模型」（The Adoption Curve），將新技術引入 Slack 的過程分為探索、擴張與轉移三個階段，搭配實際在 Slack 發生的幾項新技術採納案例，如 React、Hacklang，或者是最終喊停的 LibSlack，分享他們認為在不同階段應採取的策略，以及要注意的事項。 文末他們也提供幾項建議給正在煩惱是否採用新技術的讀者。他們認為「在嘗試帶來改變時，要抱持著使用者中心的心態，來面對需要去理解與使用新系統的團隊。他們高興與否，是評估成功的唯一指標。」 |
