Стиль общения — Наставник Хекслета

Рекомендации
Проблемы и замечания
Заключение

Теперь мы знакомы с ролью наставника, но какой же характер у нашего героя? В этом уроке мы разберемся, какой стиль общения принят на Хекслете и разберем на примерах, как общаться стоит, а как — нет.

Счастливый студент – это главный показатель нашей работы и ключевой приоритет Хекслета. Со студентами наставники Хекслета общаются нейтрально, с позиции экспертов, но при этом приветливо и уважительно. Представим идеального (в том числе и с точки зрения софт-скиллс) тех- или тимлида — примерно таким нам и необходимо стать при общении со студентами. Базовые принципы:

Наставники Хекслета общаются на равных, но не допускают фамильярного обращения. По умолчанию в общении используется «вы», а не «ты». Однако, если мы обсудили этот вопрос со студентом / студентами и договорились общаться на «ты», то общаемся на «ты».
Наставники Хекслета доброжелательны и никогда не заставляют испытывать чувство вины.

Наставники — не друзья студентов и не врачи (психотерапевты). Мы не оцениваем личность и не погружаемся в личную жизнь студентов. Наставник — это профессионал, задача которого — поддерживать студента в его желании научиться. При этом мы сохраняем человеческое лицо. Итак, разберемся, как же найти баланс.

Рекомендации

Общаясь со студентом или группой студентов, мы можем выразить одну и ту же мысль разными способами. Сравним четыре варианта анонса мероприятия:

Добрый вечер. Напоминаю, что завтра в 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 оно длинное, но я рекомендую посмотреть целиком и обратить внимание на фрагмент с дефолтами.
В этом решении не учитывается один кейс. Что произойдет если сеть начнет тормозить? Попробуйте воспроизвести такую неисправность и ошибка всплывет сама.
Представьте что вам пришли такие данные на вход. Как это повлияет на код? Покройте этот кейс в тестах.

В любом случае, каждое замечание должно быть обосновано при помощи небольшого описания либо ссылки по теме.

Проблемы и замечания

Бывает, что наставники словно переносят опыт из школы на студентов, как бы черкая красной ручкой по их работам: «в этом коде проблемы тут и там, нужно исправить мои замечания». Даже если текст составлен в целом хорошо, но содержит много слов негативного окраса, это портит общее впечатление студентов. На Хекслете слово «проблема» фигурирует только в контексте «какую проблему человека мы решаем?». Все остальное на пути студента должно вести к решению его проблемы, быть средствами для достижения цели, но не должно становиться проблемой само по себе. Иногда полезно об этом вспомнить и объяснить студенту.

По возможности стоит использовать больше слов положительного окраса:

«Ревью, улучшения, рекомендации» — вместо «замечания»
«Ситуации, сложности, особенности» — вместо «проблемы»
«Ошибки», как сущности из кода, но не «ты ошибаешься»

Заключение

Как это часто бывает, любые хорошие рекомендации можно использовать во вред и довести до абсурда. Наставнику не следует превращаться в сфинкса, который говорит загадками и доводит студента излишней дружелюбностью. Нормально попросить обратной связи от стороннего наблюдателя — куратора или своих студентов, насколько им комфортно. В ситуациях, когда проблемы в общении наставника становятся видны невооруженным глазом, на помощь приходит команда Хекслета и делает ревью наших ревью, дает предложения по улучшениям, помогает наладить коммуникацию. Люди становятся наставниками по факту работы над собой, а не просто по названию должности.