Поради для наставників

Нотатки наставника

Однією з найбільших підмог у наставництві може стати файл із нотатками для кожної вправи, з якою ми працюємо. Багатьом рішенням можуть допомогти ті самі поради, тож, ведучи нотатки, ми не мусимо щоразу згадувати й записувати ті самі поради заново. А тримаючи поради в одному місці, ми можемо з часом удосконалювати їх, роблячи дедалі зрозумілішими.

Якщо ми не знаємо, з чого почати свої нотатки, можна знайти файл mentoring.md для вправи свого треку в exercism/website-copy/tracks. Якщо він є, у ньому можуть бути приклади прийнятних рішень, а також поширені поради й теми для обговорення, які допоможуть розпочати розмову. Якщо його немає, можливо, варто повернутися й створити його після того, як ми зробили власний файл нотаток для цієї вправи.

До того ж, навіть якщо зараз ми наставляємо лише однією мовою, згодом їх може стати більше. Може допомогти впорядкування нотаток і за треком, і за назвою вправи, адже різні треки, найімовірніше, потребуватимуть різних порад для тієї самої вправи.

Нотатки наставника стають у пригоді незалежно від того, часто ми працюємо з цією вправою чи рідко. Якщо часто, вони звільняють від потреби щоразу набирати все з нуля: достатньо скопіювати й вставити з нотаток. Якщо рідко, вони нагадають поради, які ми могли забути за тижні чи місяці відтоді, як востаннє працювали з цією вправою.

Нічого страшного, якщо нотатки різних наставників відрізняються. Ось один зі способів їх структурувати, але це не єдиний спосіб.

Привітайте студента з тим, що тести пройдено (якщо їх пройдено).

Якщо вправа вже кілька днів лежить у черзі, можна почати з чогось такого:

Вибачте, що відповідь довелося чекати так довго. Зараз бракує активних наставників із JavaScript для вправи Resistor Color Duo.

Перелічте все, що подобається в рішенні студента. Наприклад:

• Мені подобається, що рішення стисле й читабельне.

• Мені подобається використання indexOf.

• Мені подобається підхід (first * 10) + second, який дає змогу уникнути перетворення числа на рядок тексту (англ. string) і назад.

• Мені подобається, що тут немає циклів та ітерації.

• Мені подобається деструктурований параметр.

Далі можуть іти поради, які ми даємо найчастіше.

Хоча нам не хочеться розкривати рішення, іноді студент найкраще вчиться на прикладах. Фрагмент коду в згорнутому блоці <details> може дати такий приклад, який студент може розгорнути або залишити згорнутим. Наприклад:

<details><summary>Приклад зі спойлером</summary>

<pre>

export const decodedValue = ([firstColor, secondColor]) => COLORS.indexOf(firstColor) * 10 + COLORS.indexOf(secondColor)

</pre>

</details>

Ближче до кінця нотаток можна додати посилання на опубліковане рішення, у якому всі ці поради втілено повністю.

У самому кінці нотаток можна розмістити докладніші пояснення, про які студенти іноді питають. Ці пояснення трапляються нечасто, але все одно варто записати їх того разу, коли ми їх використали, щоб наступного разу, а він може настати за тижні чи місяці, не довелося вигадувати пояснення заново. Наприклад, студент іноді питає, як підхід із множенням працював би для вправи «Дует кольорів резистора», якби чорний був першою смугою й давав провідний нуль:

Чорний як перша смуга - слушне зауваження, тож розгляньмо його. Колір резистора має позначати кількість омів опору, а провідний нуль не використовують для резистора з кількома смугами. Тож чорний не буде першою смугою. До того ж і parseInt, і Number теж приберуть провідний нуль.

Необовʼязкова категорія даних для нотаток наставника - це записи результатів бенчмарків для різних рішень чи підходів.

Бенчмаркінг

Студентів часто турбує те, наскільки швидким є їхнє рішення. Особливо це стосується «низькорівневих» мов, як-от C, C++, Go та Rust. Поряд із тим, наскільки ідіоматичним є їхній код, студентів інших мов часто турбує й ефективність коду.

Трек Go особливо зручний для бенчмаркінгу, адже бенчмарки часто вже є у файлі тестів. В інших мовах, можливо, доведеться пошукати, який метод підійде найкраще. Наприклад, якщо ми користуємося лише онлайн-редактором, то шукатимемо місце, де можна запускати бенчмарки онлайн. Наприклад, JSBench.me - це онлайн-інструмент для бенчмаркінгу JavaScript.

Якщо ми запускаємо код локально, то можемо завантажити програмне забезпечення для бенчмаркінгу й запускати його на своїй машині. Наприклад, у Rust можна скористатися Criterion або cargo bench разом із тестами для бенчмаркінгу.

Є принаймні кілька способів вести облік бенчмарків. Один зі способів - вести список усіх, які ми вимірюємо, але він може стати надто громіздким, якщо список виросте. Інший спосіб - вести список показових бенчмарків для різних підходів. Студенти часто хочуть побачити код швидших підходів, тож якщо швидший підхід опубліковано, посилання на нього, найімовірніше, буде дуже доречним.

Нотатки наставника, не привʼязані до конкретної вправи

Буває, що якусь можливість мови ми згадуємо в кількох різних вправах. Перш ніж копіювати пораду з одного файлу в інший, варто замислитися, чи не винести її в окремий файл. І знову ж таки: тримати пораду в одному місці вигідно, бо так легше її з часом удосконалювати. Також її легше знайти, коли вона потрібна для вправи, де ми ще не використовували цю пораду. Замість намагань пригадати, у якій вправі ми вже давали цю пораду, можна одразу відкрити її окремий файл.

Коли в студента є запитання

Студентів заохочують зазначати, що саме вони хочуть отримати від сеансу наставництва. Часто вони формулюють це як запитання. Якщо ми не знаємо відповіді на запитання й воно нам нецікаве, цілком нормально залишити запит на наставництво іншому наставникові.

Якщо ми не знаємо відповіді, але хочемо її знайти, краще не брати запит на наставництво, доки ми не знайдемо відповідь. Якщо за цей час запит уже розберуть, то принаймні ми дізнаємося щось нове й не змусимо студента чекати.

Один виняток може бути, коли запит на наставництво лежить у черзі вже кілька днів або довше. У такій ситуації можна взяти запит і дати ті відгуки, які ми можемо, та повідомити студентові, що ми повернемося до його запитання. Звісно, важливо потім справді повернутися до цього: або повідомити студентові відповідь, або сказати, що знайти її не вдалося. Якщо відповіді знайти не вдалося, студентові може допомогти розповідь про те, якими шляхами ми її шукали. Студент може відповісти й підказати інші способи пошуку відповіді. Спільними зусиллями відповідь може знайтися.

Якщо ми вичерпали всі відомі нам способи знайти відповідь, можна порадити студентові завершити обговорення й подати запит заново, сподіваючись, що відповідь дасть інший наставник. Якщо студент захоче, він може написати в завершеному обговоренні й поділитися відповіддю, коли її знайде. Так само, якщо ми дізнаємося відповідь пізніше, можна повернутися до завершеного обговорення й повідомити студентові.

Якщо ми знаємо відповідь і хочемо її дати, добре місце для цього - між розповіддю студентові про те, що нам подобається в його рішенні, і порадами щодо інших підходів.

Код, що не працює

Код може не працювати з двох причин: він не проходить усі тести або не компілюється чи не задовольняє інтерпретатор.

Різні наставники мають різну схильність і/або терпіння до роботи з кодом, що не працює, і це певною мірою залежить від того, як його подано, адже такий код подають не завжди однаково.

Іноді студент каже, що спробував інший підхід, і той не спрацював, і питає, чому. Коду може не бути взагалі, або його вставлено в майже нечитабельний коментар, а не в ітерацію.

Рішення, перевірене у вебредакторі, можна подати на запит на наставництво, лише якщо воно пройшло всі тести. Одна з причин - щоб наставник міг зосередитися на порадах щодо покращень чи інших підходів до наявного робочого коду. Налагодження коду - не обовʼязково те, чого наставник хоче чи мусить робити. Однак рішення, яке не проходить тести, можна подати через CLI на запит на наставництво, якщо студент просить допомоги з ним.

Якщо коду, що не працює, не надано, а описаний невдалий підхід не видається добрим, можливо, досить порадити замість нього третій підхід, який не є ні невдалим, ні тим, який студент використав і який пройшов тести. Або досить пояснити, чому використаний підхід кращий за невдалий, не заглиблюючись у те, що саме пішло не так у невдалому підході.

Наприклад, поширена ситуація: студенти мають труднощі з вправою «Імʼя робота». Або тести перевищують ліміт часу, або не вдається згенерувати достатньо імен, і студент хоче знати, як це виправити. Якщо є бажання й терпіння, цілком можна проаналізувати код і підказати, як розвʼязати проблему. Або пояснити, що перевірка випадково згенерованих імен дає більше збігів, чим більше імен згенеровано, і порадити інший підхід: генерувати імена послідовно, а потім перемішати їх.

Якщо код, що не працює, вставлено в майже нечитабельний коментар, можна дати ті відгуки, які можемо, щодо рішення, яке проходить тести, і порадити студентові подати код із коментаря як окрему ітерацію. Можна також порадити студентові подивитися помилки тієї ітерації, де код не працює, щоб зрозуміти, де саме проблема.

Якщо код у невдалій ітерації, може допомогти, якщо ми скеруємо студента до помилок із запуску тестів. Деякі мови потребують більше пояснень щодо читання помилок чи результатів тестів, ніж інші. Може допомогти процитувати одну чи кілька частин помилок і пояснити студентові, що вони означають.

Зрештою, виправляти код студента, який не працює, - не обовʼязок наставника, але наставник, якщо захоче, може підказати студентові способи виправити його самостійно.

Робота з чергою

Буває, що ми стаємо наставниками треку, але в його черзі не бачимо жодної вправи для наставництва. Може здатися, що щось не так, але для цього є принаймні кілька причин. Одна з причин - люди просто зараз не подають запитів на наставництво з цього треку. Іноді в треку бувають періоди затишшя. Інша причина - запити можуть розбирати інші наставники ще до того, як ми їх побачимо. Так зазвичай буває з популярним треком, де багато активних наставників.

Якщо в черзі багато запитів, є кілька способів з ними працювати. Можна брати їх від найстаріших до найновіших, щоб тих, хто чекає найдовше, розібрали першими. Або навпаки, від найновіших до найстаріших, особливо якщо найстаріші чекають уже давно. Так люди, які нещодавно були активними, не чекають, поки розберуть увесь завал.

Якщо надійшло кілька запитів щодо однієї вправи, їх варто розбирати групами за однією вправою, щоб не втрачати зосередженість, а не перестрибувати з вправи A на вправу B і назад.

Буває, що запит щодо вправи, яка нам нецікава, лежить там днями чи тижнями. Можна його не брати, сподіваючись, що його розбере інший наставник, або ж він стане приводом самому спробувати цю вправу. Одна річ, яка може допомогти, - подивитися на подане рішення. У ньому може бути підхід, про який ми не думали, і цей підхід може зробити розвʼязування вправи привабливішим. Але якщо ми подивилися на код і вправа все одно нецікава, нічого страшного не сталося. Те, що ми подивилися на запит на наставництво, зовсім не означає, що треба натискати кнопку «Почати наставництво».