Теперь мы знакомы с ролью наставника, но какой же характер у нашего героя? В этом уроке мы разберемся, какой стиль общения принят на Хекслете и разберем на примерах, как общаться стоит, а как — нет.
Счастливый студент – это главный показатель нашей работы и ключевой приоритет Хекслета. Со студентами наставники Хекслета общаются нейтрально, с позиции экспертов, но при этом приветливо и уважительно. Представим идеального (в том числе и с точки зрения софт-скиллс) тех- или тимлида — примерно таким нам и необходимо стать при общении со студентами. Базовые принципы:
- Наставники Хекслета общаются на равных, но не допускают фамильярного обращения. По умолчанию в общении используется «вы», а не «ты». Однако, если мы обсудили этот вопрос со студентом / студентами и договорились общаться на «ты», то общаемся на «ты».
- Наставники Хекслета доброжелательны и никогда не заставляют испытывать чувство вины.
Наставники — не друзья студентов и не врачи (психотерапевты). Мы не оцениваем личность и не погружаемся в личную жизнь студентов. Наставник — это профессионал, задача которого — поддерживать студента в его желании научиться. При этом мы сохраняем человеческое лицо. Итак, разберемся, как же найти баланс.
Рекомендации
Общаясь со студентом или группой студентов, мы можем выразить одну и ту же мысль разными способами. Сравним четыре варианта анонса мероприятия:
- Добрый вечер. Напоминаю, что завтра в 20.00 по Москве я проведу вебинар на тему «Функции в JavaScript». Расскажу о том, что такое функции концептуально и о том, для чего они используются. Вебинар будет полезен тем студентам, кто уже освоил синтаксис языка, но и студентам других уровней послушать будет не лишним.
- Здорово котаны! Завтра в 20.00 по Москве (разумеется) залетайте на вебинар по функциям в JavaScript. Раскидаемся, что это вообще такое, зачем оно нам надо и для чего нам это учить. Если синтаксис JS уже освоили — красавчики. Если отстали или наоборот улетели вперед, все равно врывайтесь — пригодится.
- Привет, ребята! Напоминаю, что завтра в 20.00 жду вас на вебинаре по функциям в JavaScript. Разберемся, что же такое функции, а главное — для чего они применяются и как помогают нам, программистам, в нашей работе. Для того, чтобы качественно усвоить эту информацию, нужно понимание синтаксиса на базовом уровне. Но если вы пока что его не «добили» или наоборот убежали вперед — все равно приходите. Пригодится на будущее или для повторения пройденного. Кто придет, ставьте плюсики и до скорой встречи в эфире!
- Завтра вечером новичкам расскажу про функции в ЖС встреча в гуглокалендаре куратор скинет ссылку.
Предпочтительный вариант здесь третий: он не слишком официальный, не слишком развязный и при этом непринужденный и приветливый. Четвертый вариант отвечает формальным требованиям к анонсу, но сделан «на отвали» и может вызвать у студентов уныние.
При личном общении со студентом мы придерживаемся нескольких правил:
- Поддерживай и поощряй
- Хвали человека – ругай код
- Не указывай
- Направляй, а не отвечай
Далее мы разберемся, что значит каждое из них, но прежде поговорим о психологической составляющей:
- Приводя в пример плохие практики и неудачные решения, мы не делаем другого человека прямым участником этих событий: «представьте, что вы написали плохой код». Всегда делаем это от третьего лица: «представьте себе программиста, который написал такой код, а потом...».
- Стремимся избегать интерпретации мотивов поведения. Обсуждаем только сами решения, а не то, почему что-то было сделано.
- Никогда не сравниваем человека с другими людьми. Это может быть очень болезненно.
Поддерживай и поощряй
Правильная обратная связь включает в себя не только замечания по коду, но и похвалу за правильные подходы и удачные решения. Например:
- Конфигурация проекта выглядит отлично
- Удачное разбиение по модулям
- Функция хорошо изолирована
- Ничего лишнего, код делает свою задачу на отлично
- Мне нравится решение реализовать эту функциональность через <что-нибудь>
Если студент что-то удачно исправил, то скажите ему об этом. Хвалите хотя бы раз за проверку.
Хвали человека – ругай код
Замечания всегда должны быть направлены на код и никогда — на человека. Можно выражать похвалу не только решению, но и усилиям, которые человек потратил на решение. Особенно если трудно найти объективную причину для похвалы.
Так говорить нельзя
- Вы написали плохой код
- Так нормальные программисты не пишут
- Этот код отстой
Так правильно
- Это решение приводит к таким-то проблемам
- Это неудачное решение потому что
- Алгоритм можно реализовать проще, например, если сделать так
- Стало лучше, но надо доработать вот этот момент
Стараемся формулировать замечания в положительном ключе, не «это плохой код», а «этот код можно сильно сократить/доработать/упростить».
Не указывай
Студенту важно понимать причинно-следственные связи почему одно решение лучше другого, а не получать установки «делай так, потому что так правильно». Использование слов «должен» нужно сводить к минимуму.
Так говорить нельзя
- Эта переменная должна называться так
- Вы должны реализовать этот алгоритм так
- Вы должны переписать этот кусок кода
Так правильно
- Такое название будет лучше отражать суть
- Имя функции должно быть глаголом (в таком варианте использовать допустимо)
- Этот модуль не может зависеть от источника данных, так как процесс парсинга работает только с данными
Направление, а не ответ
Лучший способ обучения — когда студент сам доходит до ответа путем проб и ошибок. Наставники Хекслета дают готовые решения только в исключительных случаях. В основном наша задача — направлять, например, задавая вопросы, прикладывая ссылки или рассказывая про подводные камни. Примеры:
- Прочитайте эту статью про цепочки: https://ru.hexlet.io/blog/posts/sovershennyy-kod-proektirovanie-funktsiy она позволит улучшить код модуля.
- Про дефолты рассказывается в этом видео: https://www.youtube.com/watch?v=vkUTX1hruF8 оно длинное, но я рекомендую посмотреть целиком и обратить внимание на фрагмент с дефолтами.
- В этом решении не учитывается один кейс. Что произойдет если сеть начнет тормозить? Попробуйте воспроизвести такую неисправность и ошибка всплывет сама.
- Представьте что вам пришли такие данные на вход. Как это повлияет на код? Покройте этот кейс в тестах.
В любом случае, каждое замечание должно быть обосновано при помощи небольшого описания либо ссылки по теме.
Проблемы и замечания
Бывает, что наставники словно переносят опыт из школы на студентов, как бы черкая красной ручкой по их работам: «в этом коде проблемы тут и там, нужно исправить мои замечания». Даже если текст составлен в целом хорошо, но содержит много слов негативного окраса, это портит общее впечатление студентов. На Хекслете слово «проблема» фигурирует только в контексте «какую проблему человека мы решаем?». Все остальное на пути студента должно вести к решению его проблемы, быть средствами для достижения цели, но не должно становиться проблемой само по себе. Иногда полезно об этом вспомнить и объяснить студенту.
По возможности стоит использовать больше слов положительного окраса:
- «Ревью, улучшения, рекомендации» — вместо «замечания»
- «Ситуации, сложности, особенности» — вместо «проблемы»
- «Ошибки», как сущности из кода, но не «ты ошибаешься»
Заключение
Как это часто бывает, любые хорошие рекомендации можно использовать во вред и довести до абсурда. Наставнику не следует превращаться в сфинкса, который говорит загадками и доводит студента излишней дружелюбностью. Нормально попросить обратной связи от стороннего наблюдателя — куратора или своих студентов, насколько им комфортно. В ситуациях, когда проблемы в общении наставника становятся видны невооруженным глазом, на помощь приходит команда Хекслета и делает ревью наших ревью, дает предложения по улучшениям, помогает наладить коммуникацию. Люди становятся наставниками по факту работы над собой, а не просто по названию должности.
