前面聊完了目標與回饋，但除此之外，一個更根本的問題是如何挑對題目練習。其實前面也有稍微提到一點，這篇就讓我們來好好聚焦在這件事上面。
經典學習理論告訴我們的三大區域，舒適區、學習區與恐慌區，應該大家都不陌生了。挑的目標太簡單就是舒適區，反之太難就會引發焦慮恐慌。道理很好懂，但真實情況就是大多數人在大多數時間，都在舒適區跟恐慌區之間來回跳動。
先聊聊舒適區的狀況，你是否有經驗，小時候學習一個新的才藝，例如籃球、鋼琴、圍棋、繪畫、舞蹈，剛開始會覺得有點困難，但接著你花了一些時間克服障礙，到了一個開始覺得他有趣的點之後，就成了你的興趣，或許你還因此持續了多年。
但，其實除了最開始的時候，你有在恐慌區跟學習區停留一陣子，後來的大多歲月，其實你就只是在玩而已，當你時常享受於這個遊戲，某部分也就代表你其實停留在舒適區之內很久了。所以即使你練習了十年，或許技巧仍比不上正規班訓練兩三年的小孩。當然以興趣嗜好來說，這樣完全沒問題，甚至是很棒的，但如果要當成專業來培養，這樣就有問題了。
大家應該也都聽過職場警語：
有些人雖然有十年的工作經驗，但其實只是把一年的工作經驗重複了十年
這是很危險的！
但要一直停留在挑戰區並沒有想像的容易，現實中即使是很優秀又很為下屬著想的主管，也往往會受限於專案的進度壓力，或可供選擇的局限性，沒辦法幫每個人都找到剛好合適的工作項目安排，就更不用說那些只顧產出，不在意員工成長的公司了。因此學會自己找到新的挑戰，自己當自己的教練至關重要，你要不斷發現自己停滯了，然後有意識的去突破，去設計一個挑戰，或尋找一個題目，讓你覺得有挑戰性但又不致於難到不可思議，然後再去突破他。
不要把設計挑戰路徑想成很困難的事，只要學會把現有手頭上的工作做切分到足夠小，小到每一小塊都在掌握內，通常都能找到每個小目標的最佳挑戰方式。
舉個例子，假設你們這個 sprint 的目標是開發一個電商網站的購物車頁面，大多數時候，工作項目都會習慣依照功能拆分，最終你領到手的其中一個 task 可能會類似這樣（以網站後端為例）
完成購物車的新增、刪除、修改商品的 API
這是寫在 scrum board 上的工作（當然可能會更詳細），但我自己通常會試著在自己的筆記本上繼續細部拆解它，例如我可能會寫成：
1. API Design
1. 與前端確認需求
2. 確認有考慮清楚可能的資安問題
3. 確保 Concurrency 狀態下運作正常
4. 確保可以支撐預計的 QPS
2. 更新資料庫欄位
3. 撰寫 API 功能
4. 撰寫 Unit test 與 Integration Test
5. 做 Load Test（optional）
6. Deploy 到 Production 並確保運作正常
拆小的目的在於確保目標明確（還記得昨天我們談的目標嗎？），有了明確目標後應該更容易估計每項需要花費的時間，再經過一輪安排之後，可能會有幾種狀況：
透過這些做法，讓這些有點舒適的任務，重新回到挑戰區內，讓自己成長更加快速。
當然，另一種狀況是，如果你發現自己長時間處在焦慮區，從來都沒有餘裕去做這樣的嘗試，那其實你很有必要跟主管好好溝通一下（甚至考慮換一個團隊或公司）。有些很優秀且負責任的人，可能會把壓力當成成長的燃料，確實，這幾乎是工程師職涯一定會遇到的情境，懂得如何面對也是種功力，但這絕對不是最好的長期成長方式！
長期處在焦慮區，跟長期處在舒適區一樣都對學習有害。焦慮區容易引發的問題在於隧道視野跟錯誤累積。隧道視野的意思是，當你被焦慮籠罩時，往往只能看到眼前的問題，而忽略身旁更重要的事，有時可能有更好的解決方法，但也會直接被你忽略掉，只埋頭砍樹卻不曾發現斧頭該磨了。而錯誤累積則體現在兩個層面，一個是開發本身，很容易寫出有 bug 的 legacy code，導致你未來反而要花更多的時間維護，或在 review 時被來回浪費更多時間，另一個則是你本人知識上的錯誤累積，可能會急急忙忙找到網路解答就複製貼上去完成任務，但其實完全沒搞懂發生了什麼事，甚至搞錯了實際的問題，導致你以為你完成了很多事情，但事實上什麼都沒學到。
如果我請你好好反思前一個月你學到了什麼，但你好像一件事也說不上來，很有可能就是陷入了這個困境。
最好的成長環境，是在你大概在游刃有餘到免強能負荷的這個範圍之中，然後透過良好的設計與自我要求，來達到學習效果的最佳化。只要盡可能讓自己大多數時間保持在這樣的狀態，那偶而進入焦慮區極限衝刺一番，或偶而讓自己鬆懈下來打混幾天找回狀態，都對你有益無害。
另外，如果行有餘力，最好嘗試找到分享的機會，這也是一個極為有用的方式，往往在你為了分享而努力整理資訊的過程中，就會發現一堆自己還沒搞清楚的問題，而這些問題往往都會差不多落在你的挑戰區之中(其實有個更專業一點用詞叫做近側發展區)，等於是現成的、剛剛好為你量身定制的最寶貴教材。
iThome鐵人賽
看影片追技術