哈囉讀者，
看電影時偶爾應該會對一兩句台詞印象深刻吧，你會不會好奇這些台詞在其他電影是不是也曾出現過呢？
Playphrase 這個網站讓你簡單實現想聽聽不同人說同一句台詞的願望，只要打入台詞，就會自動篩選出五個出現這句台詞的影片（如果想看超過五個可以贊助開發者），不用再大費周章到 YouTube 搜尋。現在就用《絕命毒師》的經典台詞「Say my name」試試看吧！
lily
‣‣‣ 精彩 Podcast 回顧
科技的歷史並不像我們玩「世紀帝國」那樣總是直線往前、向上升級。《老科技的全球史》書中有個例子：台灣在 1980 年代擁有全世界最大的拆船產業，使用專門的船屋設施，拆卸的船隻超過全世界拆船量的三分之一，到了 90 年代，台灣退出該產業，後來的拆船業是由印度、巴基斯坦和孟加拉主導，在 1995 年拆船量佔了全球的 80%，但是這批新的拆船業者是在海灘上，用最簡單的設備，由數以萬計的赤腳工人去拆船。
眼光放到我們今日習慣的數位科技，你會發現自己其實並不關心是誰發明了第一部智慧型手機，甚至第一部手機是誰發明的、在哪裡被發明的，你知道的是：口袋裡的那個電腦已經大大地改變了你的生活，而且幾乎已經擴散到全球的各個角落。以使用為基礎來看科技的歷史，你會發現原本那個你所熟悉的、以發明作為時間軸線的歷史一下子被攪亂了。我們認為這是一個非常重要而且有趣的觀點，這也是為什麼我們要推薦《老科技的全球史》給關心科技和創新故事的你。
一般新創公司產品開發團隊建置可能很精簡，負責某專業領域的團隊只有一位成員，甚至只是個菜鳥，作者正是這樣的工程師：他一半年前加入公司後才開始每天投入八小時 iOS 開發上，因此第一次正式擔任專案負責人時常冒出大問號：「我寫的程式碼品質好嗎？」再加上新創公司總是與時間賽跑，多重混亂的狀況下要怎麼有效率的訓練自己建立對程式碼品質的「主觀」意識呢？特別是剛踏入軟體開發領域的非本科系開發者，以及超小型新創公司菜鳥工程師（尤其是沒有資深工程師的公司）可以參考這篇文章～
作者提到小公司的優點是對自己的 code 掌控度很高，但缺點就是在缺乏相對完整的軟體開發流程及資深工程師的帶領下，對軟體部署流程、架構導入或效能優化…等的想像空間非常有限。所以當你沒有相同專業領域的工程師協助做 Code Review 時，廖慶麟分享了兩種方式，而他目前大量使用的則是 Test-Driven Development（TDD）——在實現一個新功能前把「如何寫出一份好測試的程式碼？」放在心上，這也是他最推薦的作法。
想像一下，公司出了有著四種價格方案的商品，每種方案都針對不同的目標對象。資訊可能紛亂複雜，但必須讓使用者不必進行太多決策思考，就能一眼辨識出自己或老闆的需求，乾脆俐落地刷卡付費。身為設計師的你，會怎麼打造這個頁面呢？
作者 Vitaly Friedman 搜集了 Basecamp、Dropbox、N26 等大量軟體產品案例，歸納出幾個價格方案的設計原則：功能表格到底要放幾種功能才不會太多或太少？哪些功能才可以突顯差異性？運用不同字眼的方案也有可能打中不同族群，有些主打創意的產品則採用了不尋常的設計風格。來看看有哪些你沒想到的設計細節吧。
儘管每天都列出待辦事項、也通常都能為每件小事打勾勾，卻仍感覺停滯不前嗎？本文作者 Brie Wolfson 開發出的十種以自我為核心的紀錄文件，或許能夠幫助你擺脫這樣的泥淖。
從寫下每日「今天我學到什麼事情」、「什麼事情讓我感到驕傲」，到每月的「影響力追蹤」，每季的新聞稿，甚至每年都會擬出「Brie 的使用手冊」，她發現自己每天都比昨天更加專注、平衡，能夠更敏銳地意識到環境跟自我，也對工作流程愈來愈能掌控；更重要的是無論公司或個人職涯都因之同步成長。
想換種方式記錄生活的讀者，不妨先挑一種嘗試看看（文中提供豐富模板！）。
[中] Jayden Lin／Agile 🏈 聊聊增量，PM：需求要擠牙膏地說還是一次全講完？
產品經理向開發團隊提出需求時，應該都曾因為到底要交代多少細節，而天人交戰，提太少不完整，提得太多可能導致時程暴增。作者建議，不妨轉換思考方向－－怎麼在需求溝通過程中，降低工程師的不安全感？
作者先解釋敏捷開發中「增量」的意思，包含「已整合的 (integrated)、可運行的 (running) 、已測試的 (tested) 軟體」三大要素；並且提供了三種觀察方向，PM 可就這些方向檢視是否資源分配出了問題，幫助團隊平衡開發需求的份量與節奏。
（文章代表圖：Photo by Karsten Winegeart on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出