引導筆記
對引導工作最有幫助的做法之一，就是為你引導的每個練習準備一個檔案來存放筆記。
你可能會發現，許多解答都能受益於相同的建議，所以只要把筆記留下來，就不必每次都憑記憶重新寫出同樣的建議。
而且把建議集中在同一個地方，你就能隨著時間不斷琢磨，讓它們越來越清楚。
如果你不知道筆記該從何寫起，可以在 exercism/website-copy/tracks 底下找到你所在軌道各練習的 mentoring.md 檔案。
如果這個檔案存在，裡頭可能會有合理的解答範例，以及常見的建議和能帶起進一步討論的話題。
如果它不存在，你可以等自己為那個練習寫好筆記檔案之後，再回頭建立一個。
另外，就算你現在只引導一種程式語言，未來也可能引導更多種。
把引導筆記同時依軌道和練習名稱來整理，可能會很有幫助，因為同一個練習在不同軌道往往需要不同的建議。
無論你經常還是不常引導同一個練習，引導筆記都很方便。
如果你經常引導這個練習，就能直接從筆記複製貼上，省下大量從頭輸入的功夫。
如果你不常引導這個練習，筆記也能提醒你那些在距離上次引導的數週或數個月裡早已忘記的建議。
引導筆記在不同導師之間有所差異，是很正常的事。
以下是一種整理筆記的方式，但這絕不是唯一的方式。
恭喜學員通過測試（如果他們真的通過了）。
如果這個練習已經在佇列裡等了好幾天，也許可以這樣開頭：
抱歉讓你等了一陣子才有人回覆你。
目前負責 Resistor Color Duo 的活躍 JavaScript 導師人數不足。
逐項列出你喜歡學員解答的哪些地方。
例如：
接下來可以放你常給的建議。
如果你為每一個新介紹的語言特性附上連結，對學員會非常有幫助。
例如：
這個練習不一定需要，不過也許可以考慮把這個函式改寫成箭頭函式。
雖然我們不想直接給出解答，但學員有時透過範例學得最好。
把一小段程式碼放進可收合的 details 區塊，就能提供這樣的範例，讓學員自己決定要不要展開。
例如：
<details><summary>爆雷範例</summary>
<pre>
export const decodedValue = ([firstColor, secondColor]) =>
COLORS.indexOf(firstColor) * 10 + COLORS.indexOf(secondColor)
</pre>
</details>
在筆記接近尾聲的地方，你可以附上一個已發布解答的連結，那個解答完整體現了這些建議。
在筆記的最底部，你可以放一些學員偶爾會問到的延伸說明。
這些說明不常出現，但第一次用到時就把它記下來仍然很有價值，這樣下一次（可能是好幾週或好幾個月之後）你就不必從頭想一遍。
例如，學員有時會問：如果黑色是第一個色帶、代表前導零，那麼乘法做法在 Resistor Color Duo 上會怎麼運作：
黑色作為第一個色帶，是個值得考慮的點，那我們就來想想。
電阻的色碼是用來表示電阻的歐姆值，而多色帶電阻並不會使用前導零。
所以黑色不會是第一個色帶。
再說，parseInt 或 Number 也會把前導零去掉。
引導筆記裡可以選擇性記錄的一類資料，是各種解答或做法的效能基準測試結果。
效能基準測試
學員常見的顧慮之一，是自己的解答效能如何。
對於 C、C++、Go、Rust 這類「低階」語言，情況尤其如此。
除了程式碼是否符合語言習慣之外，其他語言的學員也常在意自己程式碼的效率。
效能基準測試並不是導師「應該」要做的事。
不過，把自己的解答和其他做法做效能比較，往往會讓學員印象特別深刻。
Go 是特別適合做效能基準測試的軌道，因為它的測試檔裡通常就附有基準測試。
其他語言可能得先做些功課，才能確定哪種方法最適合你。
比如說，如果你只用線上編輯器，就得找個能在線上執行效能基準測試的地方。
例如，JSBench.me 就是一個 JavaScript 的線上效能基準測試工具。
如果你在本機執行程式碼，也可以選擇下載能在自己電腦上跑的效能基準測試軟體。
例如，Rust 可以使用 Criterion，或是搭配基準測試使用 cargo bench。
記錄效能基準測試結果的方式至少有好幾種。
一種是把你做過基準測試的都列成一份持續更新的清單，但清單一長就容易難以駕馭。
另一種是為不同做法各留一份具代表性的效能基準測試結果。
學員常會想看較快做法的程式碼，所以如果有較快的做法已經發布，附上連結通常會大受歡迎。
如果你要附上你做過效能基準測試的解答連結，請務必連結到已發布的解答，而不是引導會談。
並非所有經過引導的解答都會被發布。
不屬於特定練習的引導筆記
有些語言特性，你可能會發現自己在不只一個練習裡提到。
當你準備把某個建議從一個檔案複製貼上到另一個檔案時，也許可以考慮把它放進獨立的檔案。
同樣地，把建議集中在一個地方的好處，是之後比較容易慢慢琢磨。
當你要在某個之前沒用過的練習裡用到它時，也比較容易找到。
你不必再回想自己上次是在哪個練習裡提過這個建議，直接打開建議自己的檔案就行了。
當學員有問題時
我們鼓勵學員明確說出自己希望從引導會談中得到什麼。
他們通常會用提問的方式表達。
如果這個問題你不知道答案，也沒興趣去找，那把這個引導請求留給其他導師是沒問題的。
如果你不知道答案，但想去找出來，那最好等你找到答案之後再接這個引導請求。
如果到時候這個引導請求已經被接走，至少你學到了東西，也沒有讓學員枯等。
有一個例外：如果這個引導請求已經在佇列裡等了好幾天甚至更久。
這種情況下，你可以先接下這個引導請求，給出你能給的回饋，並告訴學員你會再回覆他們的問題。
當然，之後一定要記得回來處理，無論是把答案告訴學員，還是讓他們知道你沒找到。
如果你沒能找到答案，把你嘗試找答案的各種方法描述給學員聽，對他們可能很有幫助。
學員也許能提出其他找答案的方法。
兩個人一起，也許就找到答案了。
如果你已經用盡所有你知道的找答案方法，可以建議學員結束這場討論並重新提交請求，說不定會有另一位導師能提供答案。
如果學員願意，他們可以在已結束的討論裡留言，在知道答案之後跟你分享。
同樣地，如果你之後知道了答案，也可以回到已結束的討論告知學員。
如果你知道答案，也想回應，那麼最好的位置是在「告訴學員你喜歡他們解答的哪些地方」與「提出其他做法的建議」之間。
無法通過的程式碼
程式碼會失敗，可能是因為沒通過所有測試，也可能是因為無法編譯，或無法讓翻譯員接受。
對於如何處理無法通過的程式碼，每位導師的意願和／或耐心都不一樣，這多少取決於它呈現的方式，因為無法通過的程式碼未必總是以同樣的形式出現。
有時學員會說他們試過另一種做法但沒成功，然後問為什麼沒成功。
他們可能根本沒附上程式碼，或是把程式碼貼在一則幾乎無法閱讀的留言裡，而不是放在一次疊代中。
在網頁編輯器裡測試的解答，只有在通過所有測試之後，才能提交為引導請求。
其中一個原因是，這樣導師才能專注於針對現有可運作的程式碼建議改進或其他做法。
除錯並不一定是導師想做或被期待要做的事。
不過，透過 CLI 提交的失敗解答可以提交為引導請求，由學員請求協助解決。
如果沒有附上失敗的程式碼，而且他們描述的做法聽起來並不好，那麼也許只要建議：除了這個失敗的做法之外，還可以採用一種既不是這個失敗做法、也不是他們已經通過的那種做法。
或者，只要解釋他們所用的做法為什麼比失敗的做法好，而不必細究失敗的做法裡究竟有什麼 bug，也就夠了。
例如，學員在 Robot Name 這個練習上卡關是很常見的事。
要不是測試逾時，就是產生的名字不夠多，而他們想知道怎麼修好。
如果你有意願也有耐心，當然可以分析他們的程式碼，並建議如何解決這個問題。
或者你也可以解釋：檢查隨機產生的名字時，產生的名字越多就越容易碰撞；並建議另一種做法是先依序產生名字，再把它們打亂。
如果失敗的程式碼被貼在一則幾乎無法閱讀的留言裡，你可以就通過的解答給出你能給的回饋，並建議他們把那則留言裡的程式碼當作另一次疊代提交。
你也可以建議學員接著檢查那次失敗疊代的錯誤訊息，藉此找出問題所在。
如果程式碼就在那次失敗的疊代裡，那麼引導學員去看測試執行的錯誤訊息會很有幫助。
有些語言的錯誤訊息或測試結果，會比其他語言需要多一點解讀上的指引。
引述錯誤訊息的其中一部分或幾部分，並向學員說明它的意思，可能會很有幫助。
到頭來，修好學員無法通過的程式碼並不是導師的責任；但如果導師願意，也可以建議學員自己修好它的方法。
應對佇列的各種狀態
你可能加入某個軌道的引導工作，卻發現它的佇列裡一直沒有練習可以引導。
你可能會覺得哪裡出了問題，但這至少可能有幾個原因。
一個原因是目前沒有人在這條軌道上請求引導。
有時候一條軌道會有一段沉寂期。
另一個原因是其他導師可能在你看到之前就把請求接走了。
這種情況在活躍導師眾多的熱門軌道上很常見。
如果佇列裡有很多請求，有幾種方式可以著手引導。
你可以從最舊的做到最新的，讓等最久的人先被處理。
或者，你也可以選擇從最新的做到最舊的，尤其是當最舊的請求已經等很久時。
這樣一來，最近才活躍的人就不必等那堆積壓的請求先被處理完。
如果同一個練習有多個請求，你可以把同一個練習的請求分批做完，以維持專注，而不是從練習 A 跳到練習 B 又跳回練習 A。
有可能某個你沒興趣的練習請求已經在那裡等了好幾天或好幾週。
你可以選擇放著不管，希望另一位導師會接走；它也可能成為你自己試試這個練習的動力。
有一件事可能會有幫助，就是看看已提交的解答。
它可能用了你沒想到的做法，而這個做法也許會讓你更想解這個練習。
但如果你看了程式碼之後，還是不想解這個練習，那也沒有任何損失。
看了一個引導請求，並不代表你就得按下「開始引導」按鈕。
