不少讀者可能常常在思考要去新創公司還是大公司的經典求職問題，而知名的自由軟體開發者 PCMan，在回覆 PTT 軟體工作版（Soft_Job）上的文章〈如果可以，真的建議不要再去創業公司了〉，就以親身經驗分析大公司跟新創公司的工作環境的異同。

像是新創的步調較快，雖然資源跟時間有時感覺不夠，需要高度彈性、抗壓性，但有較多的機會帶領專案；相反地，大公司雖然制度完善，軟體工程的工作方式與程式碼品質也比較紮實，是學習基本功的好地方，但缺點是個人能展現能力的空間有限。因此 PCMan 也在文末強調：「不同的訓練，有不同的價值，應該兩者並用互補，而不是爭大公司或小公司哪個技術好。」

繼《星箭廣播》43 集之後，這回我們要來聊聊另一份每年都在科技圈獲得高度關注的文件：Mary Meeker 的年度網路趨勢報告。

我們除了跟大家介紹 Mary Meeker 其人，還會告訴大家去哪裡找到這些報告、報告裡有什麼、看不懂那些縮寫該怎麼辦⋯⋯ 當然，還有聽眾關心的問題：我該讀 Mary Meeker 的報告嗎？閱讀這些報告我可以得到什麼？

本文作者 Andy 是位前端工程師，這段時間也有參與口罩地圖的社群開發。在這篇文章中，他針對在這次開發口罩地圖的時候他所面臨到的問題：一次讀取過多藥局的地點資訊，導致網頁效能低落。他在文中就從前端開發者的角度，提出在 UX 上能帶來明顯改善，且技術層面也辦得到的解決方案。

作者在文中不僅整理出其他開發者所使用的取捨方式，像是使用熱點圖聚合相近的藥局，或者只呈現離使用者最短距離的藥局；他也一併提出在開發過程中，針對程式效能與 UI 呈現上的思考思路。

資深科技記者 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 播放器直接訂閱！

Mike McQuaid 是知名的開源套件管理工具 Homebrew 的專案領導人暨主力貢獻者，而他從自己超過十年的開源參與經驗中，得出一項很深的體悟就是：「開源專案維護者並沒有欠任何人什麼。」會這麼說是因為他發現到，許多開源貢獻者常常面臨過勞的問題：他們覺得有義務要儘速解決使用者所遇到的程式錯誤，但不斷犧牲自己照亮他人的結果，就是導致開源維護者最終失去熱情，並停止維護這項專案。

針對這點為開源圈的活絡帶來負面影響的問題，Mike McQuaid 在文末也提供給維護者、貢獻者與使用者幾項建議。而若對 Homebrew 開發故事有興趣的讀者，也歡迎閱讀我們之前寫過的一篇文章。

許多的管理者往往會對工程師有各種負面的刻板印象，像是他們都很自我中心、反社會、很難管理⋯⋯但往往也因為這些先入為主的偏見，導致他們在帶領技術團隊時遇上重重困難。本文作者 Jeff Ello 曾任職於科技業，目前也是美國普度大學管理學院的教授暨 IT 副總監。

他表示，其實管理者應該要先擺脫這些刻板印象，並從技術層面的角度來觀察與思考與工程師的互動，也將工程師跟醫師作對比，指出兩者都是需要在該領域有一定專業，且仰賴持續聯繫與學習知識來維持專業。技術管理者只要尊重並理解工程師所關注的議題，就能有效管理技術團隊。

在產品開發的過程中，設計團隊的貢獻往往是最難以被評估的：工程師可以透過程式的效能或 bug 數量，PM 可以比較專案結果的完成度與達標程度，而行銷也有像是轉換率等指標。但是設計團隊對產品的貢獻，卻少見有明確的指標作為評估。

資深設計師、DesignOps 經理 Dave Cunningham，根據過往帶領設計團隊的經驗，在本文中中提出了 DIET（Design Impact Evaluation Tactic，設計影響評估手法）這項法則，鼓勵設計團隊在產品開發中的三個階段，針對各 5 個問題進行自評，讓設計團隊一方面能釐清自己對產品開發的貢獻，一方面也向其他成員證明設計所帶來的價值。

在過去的週報中，編輯曾分享過購物平台 Shopify 如何評估採納新技術的時機點。而本文則是由 Slack 的系統架構師 Keith Adams 與 Johnny Rodgers 所寫，他們借用經典的「科技採納模型」（The Adoption Curve），將新技術引入 Slack 的過程分為探索、擴張與轉移三個階段，搭配實際在 Slack 發生的幾項新技術採納案例，如 React、Hacklang，或者是最終喊停的 LibSlack，分享他們認為在不同階段應採取的策略，以及要注意的事項。

文末他們也提供幾項建議給正在煩惱是否採用新技術的讀者。他們認為「在嘗試帶來改變時，要抱持著使用者中心的心態，來面對需要去理解與使用新系統的團隊。他們高興與否，是評估成功的唯一指標。」