本系列前二十七天以九組 STAR 故事整理職場轉變;最後三天依序回顧能力變化、整理延伸閱讀,並把下一階段的行動寫成可檢查的計畫。
前一篇 Day 28|九種學生味:我從哪裡開始變得比較可靠,把九條行為收成能力地圖;本篇把它接回既有研究,只列核對過書目的來源。
二十七天的第一人稱有個風險:把既有常識當成自己的發現,或把個人偏好講成通則。所以收束前我逐條問:這條行為背後,有沒有論文、專書或標準早就處理過?打開並核對書目才算讀過,搜尋摘要與 AI 書目不算。
| 菜雞行為 | 想回答的問題 | 已核實來源 |
|---|---|---|
| 沒先確認題目 | 需求該經過哪些正式過程 | ISO/IEC/IEEE 29148:2018 |
| 把 Demo 當交付 | Demo 與可釋出差在哪 | Continuous Delivery |
| 把重構當進步 | 技術債比喻原本在說什麼 | Cunningham 1992 經驗報告 |
| 把測過當證據 | 測試能證明什麼 | Notes on Structured Programming |
| 把程式碼當交付 | 大型專案難在哪裡 | The Mythical Man-Month |
| 把熟練當經驗 | 為何不熟練者容易高估自己 | Kruger 與 Dunning 1999 |
來源分兩層:標準與奠基論文給概念與原始限制,實務專書給可操作做法。兩層都答不了的,是你系統的脈絡與使用者的困難。
以下是我核實過的書目,其中兩筆沿用先前已核實的紀錄,本次未重新開啟:
系列名「粉鳥」出自教育部臺灣台語常用詞辭典,活動規範見 2026 iThome 鐵人賽活動頁。
太早選方案、只設計正常路徑、把溝通當轉交這三題,我還沒核實到能負責任列出的出處,先標為待查證。這不代表沒有文獻,只代表我還沒讀到;核實前,那些整理只是經驗與推論。
從上表挑一條最常復發的行為,花半小時實際開啟對應來源,只讀範圍說明或一小節,產出短筆記:閱讀目的、讀了哪裡、能與不能回答的問題、一項修正。驗收:筆記能分開原作者主張與你的推論。沒對應問題時不必硬讀。
讀完別人畫的地圖,剩下的是自己接下來要走哪裡。Day 30|未來規劃:不急著變老鷹,繼續成為可靠的粉鳥。