《科技創業週報》是由 Star Rocket 於每週三發送的免費電子報，內容涵蓋創新故事與觀點、產品開發技術與經驗的分享、值得一聽的 Podcast 節目與歷久彌新的經典好文。
每則選文都會加上編輯精心撰寫的引文，非常推薦給工程師、產品經理、設計師，或者是所有對科技產業感興趣的讀者訂閱。（訂閱連結附於文末）
| 哈囉讀者： 不知道各位讀者有多少人也經歷過轉盤電話的年代？最近有名工程師突發奇想，把舊的電話轉盤接上微控制器以及手機訊號的收發器，並用 3D 列印製造外殼，做出了一支輪盤式手機！ 有興趣自己 DIY 的讀者朋友，可以在網站上找到她開源的設計圖（包含電路板跟 3D 列印的外殼等），或者直接購買她後來應大量讀者要求而開始販售的套件。只可惜最核心的電話轉盤零件，還是得自己搞定 XD by Matt |
| [中] 意志力不夠才會一直滑手機？前 Google 設計倫理學家：那不是你的錯 當 app 有紅點時，你會急著把它消掉嗎？還是刪掉社群媒體 app 又忍不住裝回來？你可能會想：「我花太多時間在上網了。」但其實這可能不是你的錯。 前 Google 設計倫理學家崔斯坦・哈里斯（Tristan Harris）認為科技巨頭應該改變產品設計目標。他在七年前發起「好好運用時間」（Time Well Spent）運動，期待未來的科技能幫助人思考，而不是只迫使人依照本能與情緒做出反應而已。 |
| [podcast] 用聽的理解 WeWork 的公司興衰史 由 podcast 製作公司 Wondery 所推出《Business Wars》是編輯很喜歡的節目之一，因為能用像聽故事一樣的方式，認識許多商業競爭的案例，譬如 Netscape 與 IE、eBay 跟 Paypal 等。而他們最新推出的迷你系列《WeCrashed》要以六集的長度，聚焦討論 WeWork 這間過去幾年飽受爭議的公司的興衰史。 與《Business Wars》不同的是，因為《WeCrashed》的故事距今不遠（或說仍是現在進行式），所以在節目中不時會穿插相關人物來現身說法，包含 WeWork 的前員工。或者在聚焦討論 WeWork 浮華經營風格的第四集，也邀請到曾猛烈批評 WeWork 的創業家、商學院教授 Scott Galloway，分享他當初不看好他們的原因。 🎧《Star Rocket 科技創業週報》的 Podcast 推薦播放列表，歡迎直接透過你常用的 podcast 播放器訂閱！ |
| [podcast] 星箭廣播 EP43｜有人說這是矽谷最重要的文件：Netflix 超狂的「自由與責任文化」投影片 你的公司會對你說「我們是個大家庭」嗎？Netflix 不會對員工這樣說。本集的《星箭廣播》，Titan 跟 Maxine 要跟大家聊聊一份投影片，還有一本書，最後則是要試著跟聽眾一起回答一個問題。 這份文件是由 Netflix 共同創辦人暨 CEO Reed Hastings 與 Netflix 前人才長 Patty McCord 共同撰寫，曾被 Facebook 營運長 Sheryl Sandberg 稱作「很可能是矽谷最重要的文件」，並擁有千萬等級的瀏覽數；Patty McCord 的著作《給力：矽谷有史以來最重要文件 NETFLIX 維持創新動能的人才策略》則進一步說明了這份文件背後的精神，統領 Netflix 人資部門的她，是怎麼思考 Netflix 的組織文化。 |
| [英] 調查近 12 萬名開發者，2020 年的程式技能趨勢報告 線上免費程式學習平台 FreeCodeCamp 與程式測驗網站 HackerRank 日前釋出一份調查報告，針對全世界近 12 萬名不同專長的開發者（部分也負責人才的招募），調查他們對程式語言開發相關議題的想法。 其中包含：他們最想學的程式語言、公司最常招募會哪種程式語言的工程師（前三名完全毫不意外）、個人職涯最重要的目標、是否也會招聘程式設計訓練營（bootcamp）的學生等。提供給有興趣自學程式的讀者，或者是想要精進程式技術的工程師們作為參考。而除了數據之外，也推薦大家詳讀本文內 FreeCodeCamp 創辦人 Quincy Larson 的深度分析。 |
| [英] 改變既定開發流程，直接在手機上設計 App 有可能嗎？ 有參與過 App 產品開發的讀者朋友，應該時常遇到一個問題：雖然現在智慧型手機的效能越來越好，在手機上能完成的事情也越來越多，但是 App 產品的設計、開發等流程，卻始終不能直接在手機上完成。因此導致既有的工作流程不僅費時，之間也會有不少的落差。 針對這問題，Play 這間 NoCode 公司提出了一種解決方案：打造能直接用手機設計 App 的服務，並且讓設計師直接將設計好的版面，輸出為 Swift、React 或 Flutter 等 App 程式語言。他們在本文中提到：「因為不良的工作流程，往往導致團隊花費太多時間在解決程序而非產品的問題」，也分享他們開發此產品時，所遵循的四點原則。目前 Play 正在募集封閉測試的使用者，有興趣嘗試的讀者也可以到他們的官網上去申請喔。 |
| [英] 第一次 SaaS 創業失敗教會我的四件事 Python 工程師 Matt Layman 的首個 SaaS 創業計畫，最終因營運不善而終止服務。在本文中他分享了自己在這次創業中學到的 4 項經驗：其中編輯覺得最關鍵的一點是：「盡量只用熟悉、最單純的程式語言／架構打造服務（當初他用了太多不熟練的技術，反而拖慢開發時程）。特別推薦給有技術背景，並想創業的讀者參考。 而這篇文章在 Hacker News 上也引起不少網友的討論，不少網友表示他們也經歷過像作者一樣，過度專注在技術層面的錯誤；也有人點出「許多人在公司的工作，並未讓他們準備好踏入創業的世界。你會太過專注在優化產品／功能的某些小細節。但是創業其實需要更多元的技能組，並且要能快速推出產品。」 |
| [英] Stack Overflow 共同創辦人，在開發軟體與服務所遵循的「三的法則」 軟體工程師 Jeff Atwood 是技術問答論壇 Stack Overflow 的共同創辦人，後續也共同創辦了 Stack Exchange 跟 Discourse 等熱門服務。 在這篇文章中他討論到，許多開發者常常會有「能再利用的錯覺」：誤以為自己所打造出來的軟體或服務，直接應用在完全不同的情境或問題，或者能被不同 TA 所採用。 Atwood 認為，打造出真正能被再利用的軟體是十分困難的，因此他從過去的創業與開發經驗中，也領悟出一套「三的法則」：「要打造完全能被再利用的（軟體／服務），首先你必須說服三組不同的群眾能頻繁使用它們。」並透過他自身的創業案例（像是在 Stack Exchange 就有上百個關注不同主題的活躍社群），進而解釋他如何在開發過程中應用、驗證這道法則。 |
| [中] Jasmine Lin／身為產品設計師，我從工程師身上學到的產品開發心法 PM 與設計師在軟體產品開發中常常要與工程師合作，但團隊中擁有不同思維與背景的人，如何能保持溝通與合作的順暢，也成為軟體產品開發的重大議題。 本篇作者 Jasmine Lin 是一位產品設計師，她在本文中分享，她如何從一位沒有工程師合作經驗的設計師，在這次合作之後開始導入「Daily Stand Up 每日站立會議」或 「Sprint planning 衝刺規劃會議」等程式開發常見的工作流程，進而優化他們的產品開發方式。 編輯認為，雖然不少讀者可能很熟悉文中所討論的開發流程。但是透過作者的視角，或許你會對這些流程有不同的思考。 |
