原討論串 https://www.ptt.cc/bbs/Soft_Job/M.1548368456.A.60D.html
看標題是寫
[心得] 帶新人的感想
本來期待的是講述關與引導技巧與心路歷程的文件，但選了幾篇看大部分在討論新人合不合適的心得。我會把這個主題重新訂為 On Job Training，而越初級的工程師得需越多的介入，接下來提到的具體方法都是可以調整的，因為每個引導者都得自己面對自家的新人，實際狀況如何我並不知道，得在現場自行調整。
回想起第一次帶新人的情境，那時寫的是標準的 Java Web，使用著當時流行的 Framework 東西雖然不算太複雜，但回想起來要新人在一個下午聽完內容，又不打瞌睡實在有一點難度。
當時的架構可以參考這篇： https://www.ptt.cc/bbs/Soft_Job/M.1419871653.A.224.html
那時大致就是從無到有加 1 個新的功能的解說：
- 怎麼建出後端相關的 Service 與 Dao
- 資料庫與 Entity 的屬性對應
- 怎麼開始實作 View 那一層的事情 (再對到 jsp)
- 怎麼寫 test case
時間挺趕的，這是因為當時我的角色是離職後，回去打工協助新同事熟悉專案開發。雖然後來的同事都天生神力，花一個下午吸收了部分，再透過網路上幾回問答與跟其他同事互相討論後就上手。老實說，這要運氣很好，遇到程度不錯的同事才有辦法這麼做了。不過，日子在走，我們不能光懷念那些有血輪眼的新人們，只要涯職夠長，總是會遇到些需要給些等待的新人。面對需要如養植物般照料的新人，得有較高的介入，至少得出手干擾他們進入迷航的時間。
我相信大部分的引導者都有與新人保持若干程度的對話，而不是多數文章中只寫了給了新人哪些指令或回應（這只是寫文章時，忽略了對話的部分，並非對話不存在）。在這裡特別提出是因為針對引導新人的部分，這是極為重要的一環，因為我們無法知道別人怎麼思考，除非他願意跟我們說他怎麼思考某一件事的。儘可能和善點，不然很多東西你是聽不到的。
像我這們些隨著 Extreme Programming (XP) 年代起步的開發者，很習慣地會自言自語寫程式 (Thinking out loud)，是個極好的開啟對話的方式。一般實作、示範著，一邊把眼中看到的事物報導出來給你的同伴聽到。雖然，新人一開始不太習慣這麼做，或是覺得害羞而不這麼做，但多做幾次就會習慣了。多數情況是不知道該講什麼，這也沒有問題。通常我會採用邊示範邊錄影，讓新人回頭自己找時間模仿我錄一次，我回頭再找時間看一下，並給出 feedback。
讓學習者錄影是我這二三年最喜歡的方式了 (背後的心理學意義就不太是本篇的重點就略過它唄，如果你需要 keyword：後設認知)，它有許多面向可以 feedback：
- 同步術語(term)，因為新人來自不同的地方，過去的學習材料可能會有不同的術語在描述同樣的事，透過回顧我們可以要求他使用團隊習慣的術語
- 練習帶入情境的描述。基本的要求就是避免使用『代名詞』，當我在重播錄影時，只要聽到這個、那個、這段 code，但又沒有進一步說明時都會要求在下一版剔除。這是在練習怎麼陳述事情時，不容易被人誤解，消除容易有歧義的表達方法。同時，我會比較容易知道，新人自己有沒有概念在哪一個元件或組模下工作。
- 觀察未被提起的部分。有時我們會下意識逃避不熟悉的東西，這就是個簡單的訊號，會試著要求補充或當面討論一下特別的概念是否需要補強。
對我而言開啟對話基本上就是觀察與養成新人必要的流程，有的人能接受，有的人無法。那無法接受的人，我只好把他轉給其他人去接手唄。雖然，這個互動型式介入性高，引導者也會比較疲勞，但效果我個人覺得挺好的。
我用對話模式貫穿大部分的訓練，只是隨著新人的成長，漸漸把介入性高的部分抽離。除非，我們又要開始學一個還沒有人熟悉的東西才會再加回來。例如：我們很熟了某個東西後，就不會再特別用錄影與模仿的方式來做 training，它可能會變成單方面要求新人錄影，再給文字回饋或小小的調整一下。其實在思考模式與術語同步後，大致上面對面溝通都會理解了。到這個階段新人幾乎不再會收到需要錄製成果的功課。
談完了互動方式後，我們可以開始來看具體上有哪些建議先做的部分。
首先是由資料流開始理解，若團隊剛好有準備 sequence diagram 那會相當方便。假設是 web 服務，我們可以對照著資料流，透過 debugger 去 trace 資料怎麼進來的，途中經過哪些地方，最後怎麼組出 view 再到前端去顯示出來。
上述的步驟可能就會遇到些引導者覺得沒想過的事：
- 新人沒用過 debugger
- 新人不知道 sequence diagram (團隊先前可能也沒有，那就先畫一個吧)
- 新人不知道 http request 到 http response 中間發生的事情 (我們用 web framework 做的那些事)
這大概是在資料流走訪過程中會有的典型問題，都是適合用『對話模式』來處理的，『解說、錄影、反饋』一直修到理解的品質可用，理解力不要太差的話，應該修個二三個版本就會上手了。
有時我們遇到的新人，未曾使用過 debugger，那他可能無法理解 step into 或 step over 是什麼意思，這時要追加一點補充材料，可以單獨要求他錄製 debugger 功能示範。像先前我就找到一個有趣 call stack 介紹影片：
https://www.youtube.com/watch?v=5xUDoKkmuyw
而 sequence diagram 的部分，儘可能以『元件』或『模組』為單位去展示資料流，新手工程師來說，太細節的內容容易迷路。這東西的意義大致上是遊樂園入口那個比較粗略展示裡面有哪些設施可以玩的導覽圖就行了，未來有得是時間去看細節的內容。在一站一站展示的過程中，得點出我們的 code 是加在哪邊。
這裡設計是指架構層次的，儘管多數的團隊都有用現成的 framework，但還是有些得自行實作的部分。或是由規格需要而產生的設計，這部分是需要特別介紹的。雖然『資料流』會經過它，但資料流的過程是在導覽，而非深入某個特定的設計。這個部分比較多是在輔助新人理解 design pattern 的部分。這裡提的 design pattern 並不單純指的是書上列的那些，而是我們怎麼演化成目前的實作，主要在讓新人習慣 open-closed principle 的概念。
有些經典用來刻 framework 的 pattern 當然是必備的，如 template method pattern。我們會試著把目前的『實作』展開成不用 pattern 的型式，那挺容易的呦，就只要一直 copy & paste 就行了。接著，我們挖出程式的 extension point，讓 hook 成型之類的。因為書上的內容，大多比較靜態，真的體驗過一次後，新人內心的敏感度會提昇不少，也比較能養出看既有程式碼的品味。
只有極少數的情況會單獨講 design pattern，多半會搭著 issue 與規格的定義，來看某些 module 或 class 是如何用上哪些 pattern 的。有時不只是 pattern 也會搭上語言的特性，而形成了目前這樣的實作。
如果想單純知道新人的 coding 能力，那只要排 utility 給他寫就行了，但這樣子的參與感與成就感會比較小一點，因為他的貢獻沒有直接與團隊產出有關。一開始可以這麼排，但最終還是要面對真實的 issue 才行。真實的 issue 又可能壓力太大，那我在真正給實際 issue 前，會試著用影子 issue 來指派。
所謂的影子 issue 就是，讓新人與我平行解同 1 個 issue。但我會事先說明這 issue 大致怎麼解，需要加哪些 code，而它的 test case 是哪隻程式。因為我比較熟悉一點，無疑問地，當然我會先完成實作。這時新人可以選擇繼續埋頭苦幹，或是看一下我的 branch 裡寫的內容。通常落後 1 天之後，我會鼓勵來看一下我的實作，他若理解了那就能完成他的那一份，若不理解了，我們再來討論盲點。經驗上影子 issue 只要一二回就能上手了，只要下一個正式的 issue 是同性質的，新人應該可以沒有障礙地完成工作。
渡過了影子 issue 時期，接下來又是另一個漫長的 tuning，特別是 branch 的習慣，與 commit 的習慣。新手常可能弄成一大包才 commit，這樣我也很難 review，這個得一直溝通才會變得比較好。後續就如同一般工程師的 code review 往來而已，沒有太特別是針對新人的事了。(因為，他已經 qaulified 囉)
除了『對話模式』之外，其它的選項沒有特定的順序，看情況來決定要用什麼。當然，這是針對真正比較『新手級』的工程師才需要。如果是比較資深的，那直接來 code review 搞定會比較快（其實也不會直接到 code review，而是先由實作 planning 開始，請他透露一下計劃是什麼）。
也許這些東西看起來很花時間，但這是個值得的投資。因為我對於 Programmer 的基本觀點：
Programmer 是個稀缺資源，會在各個公司之間流通。不管會在目前的公司待多久，目前是好的是壞的都會影響著未來自己就業環境是否舒適。
大家都喜歡跟專業的人一起工作，如果在帶新人時細緻一些，我們就能讓未來更光明些。同時，我們也有責任去剔除不合格的人。training 不起來的人，當然得跟他說實作他真的不適合做這行。快想點別的出路吧。