| Hi hi 讀者好， 前陣子看到一個有趣的網站「Untools」，它把 22 種思考工具跟跟用於分析的框架按照「系統思考」「做決定」「解決問題」「溝通」等分類做整理，並且一一附上簡易的圖文說明和近一步的參考資料（書籍或文章）。例如被歸納在做決定的工具有 Cynefin framework、second-order thinking 和 ladder of inference 等等。 Untools 的作者 Adam Amran 是一位來自捷克的產品設計師，網站的概念來自於他希望加強自己的思考力，因此開始尋找、收集各種工具和框架。Untools 最近也在測試他們的 app，假如你想試試看用這種方式去解析手上的問題，也許可以考慮加入他們的 beta 測試。 Titan |
| [英] 麵包屑、吐司機與收音機按鈕－常見的 UI 元件為什麼這樣命名？ 本文作者 Megan Ng 探索了常見的 UI 元件命名起源跟演變過程，為什麼導覽列稱為麵包屑呢？單選按鈕（radio button）跟收音機有什麼關係呢？其中編輯覺得最趣味的，就是被稱為「吐司（toast）」的浮動通知訊息框啦！從此看到浮動訊息，腦中就會出現吐司機跳起的聲音跟畫面。了解螢幕上的設計元件起源，可以幫助自己在現實中發現各種設計線索哦！ |
| [英] 換個角度思考「微管理」，讓新成員順利上工 在遠距工作愈來愈流行的時代，管理者應該怎麼做，好讓新人能順利上手呢？遠距工作知識管理服務 Slite 在本文中分享了他們的做法。監控式的「微管理」雖然名聲不好，但若換個角度思考，帶領新人時，如果先把工作拆分成細緻的任務，這些「微任務」，對新手來說應該能夠更順利地上工、建立自信以及當責態度；文末作者也分享了 Slite 開發者是怎麼引導未曾謀面過的實習生一步一步上手的。 |
| [中] Nelson／我的 Mac 設定 本文是 iOS app 開發者 Nelson 分享個人 Mac 的設定，包含開發環境、各種軟體（瀏覽器、通訊軟體、編輯器和終端機等等），作者還列舉了許多工作時使用的生產力工具與使用情形，除了他自己常用的之外，也會一併列出其他類似的選項給讀者參考，或是進行簡單的比較。相當適合也從事 iOS app 開發的讀者參考。 以通訊軟體來說，作者就偏好 Franz 這類整合型的通訊軟體，就不必開那麼多 app 和視窗；作者以前常用 Chrome，但後來改用 Vivaldi，主要考量點是：「多組帳號切換」「設定可同步」「套件多」。作者也另外寫了兩篇文章談瀏覽器和和 VSCode 的必備擴充套件。至於一些不常用的需求，他就會以線上軟體解決。其他像是 Git 的 GUI、API 文件、Markdown、視窗管理、筆記軟體、檢查軟體版本等等也都有介紹。 |
| [Podcast] 星箭廣播 EP164 | 思考本身比寫下什麼更重要：卡片盒筆記實戰經驗分享（ft. 小朱） 先前在 162 集我們跟工程師小朱聊到《卡片盒筆記》一書，這次要跟大家分享他如何運用書中的方法搭配各種軟體工具去寫筆記、整理筆記，對他學習知識的流程和效果產生什麼影響。小朱會先回顧過去的方法和工具有哪些缺點，後來怎麼用魔改之後的子彈筆記去處理工作筆記、建立有效的長期追蹤系統，以及採用卡片盒筆記之後對他在知識學習上的影響：不僅更早開始消化知識，也提高理解的程度。 在落實卡片盒筆記的過程中，小朱也領悟「思考」其實比寫下什麼筆記更重要。小朱還會分享他是怎麼結合各種工具、實際運用卡片盒筆記，以及他的靈感筆記、文獻筆記和永久筆記是怎麼寫的（文末的連結有他提供的模板）。節目最後，我們也會請他聊聊理想的筆記系統長什麼樣子。 |
| [中] WuPingJu／透過 Zola 建立了新的「筆記與想法快照」子網站 本文記錄了作者從 WordPress 搬家到靜態網站 Zola 的心路歷程。作者說明他對「知識系統」跟「筆記（notes）」的區分，其中裡面提到「想法快照」頗有意思。也因為建立了這個子網站，讓輸出變得更簡單隨意，快樂與成就感跟著提高，形成正向循環。想實際看看他是怎麼紀錄想法、對自己提問的讀者，也很推薦拜訪作者的 notes 頁面。 |
| [中] Yuren Ju／Over-engineering 是軟體開發者職涯中的一部分 本文是作者 Yuren Ju 讀完〈Overengineering can kill your product — Mind the Product〉一文之後綜合自己的經驗所寫出的文章。文中提到的 Over-engineering（過度工程化）指的是在軟體開發時增添「不必要的」複雜度，造成後續難以維護的情況。文章前段分析了四個發生 Over-engineering 的可能原因，除了需求不清楚、與工程師個人的經歷有關之外，還有一個很有趣的：工程師的工作太無聊了，作者建議此時可能需要考慮換工作。 而 Over-engineering 是會有後果的，Yuren 也在文章裡分析各種 Over-engineering 對產品和開發團隊的影響，並且提出如何避免的建議，例如更了解使用者、提高專案執行的透明度，以及團隊成員彼此多交流，也對應到前面分析 Over-engineering 的可能原因。作者也說 Over-engineering 其實很不好判斷，比較正確的態度應該是去了解它存在的原因，不能連「必要的複雜度」也要反對。文內也有列出另外一篇參考文章。 |
（文章代表圖：Photo by Michal Matlon on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出