· 工程實務
i18n 難的從來不是翻譯，是沒有人擁有那份語系檔
多語系的痛不在裝哪一套套件，而在 key 誰命名、字誰擁有、翻譯跟不上 sprint 怎麼辦。這篇把 i18n 治理拆成命名、擁有權、流程、在地化、政治五層，越往下工程越管不到，也越決定它會不會爛掉。
#團隊
共 19 篇
· AI 與工具
溝通的渠道
跨工具、跨協定、跨團隊的溝通一直是難題。我在 Side Project 裡改用自然語言文件當通訊協定，讓 AI Agent 交管 Product 到 QA 的整條溝通橋樑。
· 商業與創業
Side Project 的找人的感想
找 Side Project 夥伴時，「比較閒」不等於「會擠出時間」。我反而覺得習慣花時間在非盈利外務的人，才是真正擠得出時間的那種人。
· 職涯與工作
團隊不是你想怎樣就怎樣
技術強，大家就會聽你的嗎？未必。團隊的技術決策常常取決於最低水平者或平均值，主導不代表握有實權，這是英雄型工程師最難理解的一件事。
· 工程實務
Code Review
Code Review 不是拿來管品質，也不是審核誰寫得好。這篇講它真正該做的四件事、不該做的兩件事，以及為什麼兩人以上協作就需要它。
· 工程實務
關於開發流程這件事
「團隊那麼小，不需要開發流程」——對，也不對。小團隊需要的是「精簡必要的流程」，而不是亂無章法。有機制保障失誤，重構和升級才敢大膽執行。
· 設計與設計系統
設計系統到底是誰的責任？
工程師說那是設計的問題，設計師說 CSS 是工程師的問題。這些工具本來就只是溝通橋樑，而它最有價值的地方是「一致的設計語言」，不是效率。
· 工程實務
每一種寫程式的呈現都是一種「風格」
「這樣比較好維護」其實相當主觀，可讀性跟閱讀者的背景高度相關。只要符合說好的規範，剩下的就是風格問題，我不想干涉別人怎麼寫。
· 商業與創業
帶領不同領域的人
Side Project 做一套 UI Framework，找了七名 UI 設計師。這篇講怎麼靠反覆強調中心思想篩掉走馬看花的人，以及帶領比自己更專業的人要學的放手。
· 職涯與工作
管理就是要放手
看到部屬做事有問題就急著導正，甚至不知會就改掉文件與成品，這是過度管理。這篇講怎麼規劃容錯空間，讓部屬在犯錯裡長出成就感。
· 職涯與工作
只有實力與知識令人折服
會講「PR 發給你了」「Image build 好了」的 PM、會寫自動化測試的 QA、積極學新技術的高年級 CTO。這篇記下一個讓我打從心底佩服的團隊長什麼樣子。
· 職涯與工作
關於我走來體悟到的領導
從志願役基層士官帶兵開始學領導。這篇講兩個階段：想跟部屬當朋友結果管不動，以及靠硬實力壓出天花板之後，卡在跨領域溝通的那道牆。
· 職涯與工作
優秀的PM
一個好的 PM 在開發上的感受有多深刻？光是編輯路徑這種需求，就把輸入方式、互動回饋、驗證規則全寫清楚，看到需求書就有八成掌握度。
· 工程實務
講了很多次，要寫文件！
團隊出走後新人接手，光是研究舊功能的設計理念就耗掉大把時間，Bug 率居高不下。文件真正的用途是給「後手」看的：有文件叫考古，沒文件叫通靈。
· 工程實務
錯的不是技術
一聽到 Wordpress、MVC、jQuery 就聞之色變。但每種技術背後都有它要解決的問題，嚷嚷的人往往不了解新技術想解決什麼，反之亦然。
· 工程實務
文件究竟價值在哪？
朋友的新創團隊急著把 Code 寫出來、拒絕寫文件，兩個月後 PM 和工程師翻臉走人，那堆程式碼沒人想接。最後最有價值的，反而是當初沒寫的文件。
· 議題討論
［議題討論］創業需要夥伴嗎？
團隊要多大，看的是產業別與商業模式。這篇也講什麼情況其實不需要夥伴，以及找夥伴的加分項與地雷項各有哪些。
· 議題討論
［短文分享］各司其職？小心穀倉效應！
分工合作真的沒有缺點嗎？穀倉效應指的是大家各自活在自己的小圈子，因而不知變通、看不見危機。破除它的關鍵是不要把生產力當最高指導原則。
· 議題討論
［議題討論］領導統御
我想帶的是「夥伴」不是「下屬」。這篇分享我的領導風格：親力親為做完首次運作再交手、能力弱的逐步教但絕不代做、能力強的給目標與風險提點。