為什麼專案時間預估這麼難？具體可以如何解決時程預判問題
發現身為初階打工人其實通常只是看見問題並拼命解決它，但換個角度思考：「如果現在手上專案燒起來，主管定個超乎預期的時程但你也沒有自己一套說法，要如何交代？」，最貼近實作的人其實是最能開出真實預估的人。參考：The work is never just “the work” - Dave Stewart 文章。
發現身為初階打工人其實通常只是看見問題並拼命解決它，但換個角度思考：「如果現在手上專案燒起來，主管定個超乎預期的時程但你也沒有自己一套說法，要如何交代？」，最貼近實作的人其實是最能開出真實預估的人。參考：The work is never just “the work” - Dave Stewart 文章。
開發至今從來都沒有特別去了解如何好好的執行代碼審核，大家都默認會寫代碼就代表你也有能力去審核別人代碼，但我想這是一門額外的學問，因而促使我寫下這篇文章去了解如何進行代碼審核。審核代碼是最直接可以發掘並改善問題的環節，主持得當的代碼審核能夠補足團隊成員間的知識盲區進而提升整體代碼水平。
最近閱讀 Stay SasSy 提到的 Goals, Problem, Solutions 猛然察覺這不是我日常工作拆分問題的方式嗎！簡直是不謀而合，正好也想寫一篇文章來分享這個達成共識的方法，同時這也是一個很好向上溝通的方式，不管是對團隊還是對上級溝通都有幫助。
Continuous Delivery 在 The Biggest Problem With UI 影片中點出了我多年來對於產品 UI 開發流程最大的疑惑：為什麼 UI 設計與開發的流程總是如此不順暢不協調？「有沒有辦法讓團隊穩定高效的產出真實滿足用戶需求的產品？」是本篇文章探討的核心問題。
開發者在記錄或轉移知識方面的「失敗」並不是因為懶惰或缺乏關心。 相反，[環境壓力]促使他們在績效和學習目標之間的複雜緊張關係中找到平衡。當讓學習變得顯見並不安全時，績效文化就會獲勝。透過每日小會的方式，每天花費短小的時間讓學習在團隊中被提倡鼓勵。
開會是一門學問，也是身為團隊領袖必備的軟技能之一，架構差勁的會議會不只影響個人更甚至會整體團隊的生產力，特別是在遠端工作盛行的時代溝通技巧更尤為重要，架構差勁的會議會不只影響個人更甚至會整體團隊的生產力，本篇文章探討開會前中後有哪些細節是可以注意的。