技術實務教育者的瓶頸、窘境與挑戰（3）

技術實務教育者的瓶頸、窘境與挑戰（2）  << 前情

（編按：原始出處來自 〈技術實務教育者的瓶頸、窘境與挑戰〉的留言）

其實蠻好奇以「技術實務教育者的瓶頸、窘境與挑戰」為作文的題目大家會寫成什麼樣子。 我的想法，只有主觀的思考。所以，先提醒想追求公平客觀者，可以放棄這篇文章

由於存續者偏誤的原因，我們實在很難真的明白為什麼有些人無法被訓練，但我也不想要輕易地將他們歸納入學習態度不佳、沒有熱情、沒有邏輯，或是簡單一句沒心當作這些結果的原因。即使遇到的當下，這真的為自我安慰的藉口，但得試著捨棄這些易懂的答案來重新論述一番。

社群的 meetup 都在做些什麼事呢？剛開始講一些基礎入門，再來是進階到 library 或 framework 怎麼使用。運氣好可以請到一些成功者來進行案例分享，或是談談國外研討會的新概念，或社群間的八卦。能來持續參與的人基本上都能跟得上「話題」能溝通，聊得上幾句，或是在旁觀聆聽也不覺得無聊。這類的人，相信都有能力提昇自己的能力，來參與能多讓知識與資訊流通。加速個人成長的循環階段（認識新知、知道有人在使用某個技術或概念、自己開始使用某個技術或概念，最終能將相關經驗用在工作上）。
有另一大群人，就是沒有在社群活動中存活下來的部分。不管是沒有勇氣踏出第一步，或是來過了，覺得繼續參與不會有新的收穫而不再參加的人們。去掉那些強到可以飛天鑽地的大濕，多數是與我們一般平凡的「勞動者」，就算我們做的是「腦力活」，但多數時間就真的只是「勞工」而已。

面對「技術實務教育」這個議題，我會先排除一部分的人作為無法訓練的群體：生活重心不放在提昇職能者。得注意這是個「動態」的標準，這並不是將人貼標籤，說此人永世不得錄用。只是他可能這幾個月有別的生活重心，過一陣子又有自我提昇的志向。
動機先決是我的基本條件，但站在有權決定教育內容者的角度，好球帶的拿捏是很難的。面對這些最多數的，程度不上不下的需求者他們需要什麼？
教基礎初階的是能當複習，但對於實務的幫助可能有限。介紹新的 library 或 framework 認識新知也許不錯，但工作上能不能用得到還得看公司文化與個人手腕。不過，這幾個項目卻是社群 meetup 的大宗。

身為一個寫 code 維生的工作者，回過頭來面對工作現場的情況，盡是一些被視為陳舊的遺物。這樣的反差，會有使用新東西才是好並跟得上時代的錯覺，並增強了面對現狀的挫折感。
以「實務」的要求，應該如同「野外求生訓練」一般，教人如何各種環境存活下來（包含棄戰或投降輸一半）。

例如：今天看到這樣的例子 [請益] 該離職嗎!?。其實 Struts, Hiberate 算是 Java 內較常見的 Framework，但他們都已經出很久了，對於社群的 meetup 來說不算是感興趣的材料。不過，只要公司的產品有點年紀，這絕對是避不開的東西。產品在什麼年代開始，技術的 stack 往往就停留在那個年代。隨著產品的生命週期長，後來再進入的人們就越覺得他陌生。
像這樣在要不要離開緣邊的有一定的比例，這也是這一行需要面對的宿命，因為活得越，就只會有新東西加進來，而舊的技術還不一定拔得掉。除非是遇到整個產品線廢止，才有可能發生部分技術債歸零的事情。在這裡我雖然用「技術債」這個詞但並不非指東西被寫爛的情況，而是後繼的維護者越來越無法掌握這產品組成的技術。

所以「實務」為中心的主題選擇，應該要貼近現實工作環境。即使內容看起來不再新穎，但這就是工作現場需要面對的事物。由於每個人工作的技術可能略有差異，這只能靠工作技術範圍相近的人互相分組，再由有經驗的人當作「mentor 與教練」一般的存在。這即不是社群 1 對多分享，也不是補習班的大班教學，而是進行工作模式的修正。其實要寫出東西不是難事，但寫得好不好，整件事情進展的是否有效率，關係到最終的工作品質（工人快不快樂、舒不舒適，結果是否易於被接納）。

mentor 的角色是點出個人的不足，教練的角色是輔助工作方式的修正。開啟 IDE 把 code 寫出來，能跑出一些結果是簡單的，但獨自苦幹練習進步有限。要能有進展是技藝的提昇，但如何提昇正面表列顯得籠統，不如用負面表列的方向走：盡可能以良好習慣，取得導致工作效能低落的壞習慣。mentor 重要的功能即可點出個人不足之處，並建議替代方案。舉個實例，我一直到第 1 份寫 code 的工作才真的知道 eclipse debugger 怎麼用。在那之前，我都是靠著 System.out.println 在進行除錯的工作。有人點出了這個壞習慣，我也厚著臉皮說我不會用 debugger，於是就順便教了我一下。從此，我就稍為進階了一些同時捨棄了一點壞習慣。後面那個「教人」基本動作的人，即為教練的角色。先修正觀念，再養成新習慣，捨棄缺點，補上好習慣。

在這個「實務」的主題中，得面對工作現場的難處，並有人提供經驗指出破綻，再授以基本動作。最初的境困來自於無視工作現場，而窘境乃是目標群眾失散。這無疑是個艱難的挑戰。

想來想去，其實最能切合這主題的，應該是 refactoring 與 tdd 相關的 training，因為 bad smell 的聞嗅訓練是一種很好的「眼光」培養，又加上有固定套路的練習。只是這些主題又被包含在 agile 相關的訓練之內，又面臨了如何由工作現場轉換工作模式的困境。真是處處路難行啊…