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

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

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

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

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

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

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

1. Добрый вечер. Напоминаю, что завтра в 20.00 по Москве я проведу вебинар на тему «Функции в JavaScript». Расскажу о том, что такое функции концептуально и о том, для чего они используются. Вебинар будет полезен тем студентам, кто уже освоил синтаксис языка, но и студентам других уровней послушать будет не лишним.
2. Здорово котаны! Завтра в 20.00 по Москве (разумеется) залетайте на вебинар по функциям в JavaScript. Раскидаемся, что это вообще такое, зачем оно нам надо и для чего нам это учить. Если синтаксис JS уже освоили — красавчики. Если отстали или наоборот улетели вперёд, всё равно врывайтесь — пригодится.
3. Привет, ребята! Напоминаю, что завтра в 20.00 жду вас на вебинаре по функциям в JavaScript. Разберёмся, что же такое функции, а главное — для чего они применяются и как помогают нам, программистам, в нашей работе. Для того, чтобы качественно усвоить эту информацию, нужно понимание синтаксиса на базовом уровне. Но если вы пока что его не «добили» или наоборот убежали вперёд — всё равно приходите. Пригодится на будущее или для повторения пройденного. Кто придёт, ставьте плюсики и до скорой встречи в эфире!
4. Завтра вечером новичкам расскажу про функции в ЖС встреча в гуглокалендаре куратор скинет ссылку.

Предпочтительный вариант здесь третий: он не слишком официальный, не слишком развязный и при этом непринуждённый и приветливый. Четвёртый вариант отвечает формальным требованиям к анонсу, но сделан «на отвали» и может вызвать у студентов уныние.

При личном общении со студентом мы придерживаемся нескольких правил:

• Поддерживай и поощряй
• Хвали человека – ругай код
• Не указывай
• Направление, а не ответ

Далее мы разберёмся, что значит каждая из них, но прежде поговорим о психологической составляющей:

1. Приводя в пример плохие практики и неудачные решения, мы не делаем другого человека прямым участником этих событий: «представьте, что вы написали плохой код». Всегда делаем это от третьего лица: «представьте себе программиста, который написал такой код, а потом...».
2. Стремимся избегать интерпретации мотивов поведения. Обсуждаем только сами решения, а не то, почему что-то было сделано.
3. Никогда не сравниваем человека с другими людьми. Это может быть очень болезненно.

Поддерживай и поощряй

Правильная обратная связь включает в себя не только замечания по коду, но и похвалу за правильные подходы и удачные решения. Например:

• Конфигурация проекта выглядит отлично
• Удачное разбиение по модулям
• Функция хорошо изолирована
• Ничего лишнего, код делает свою задачу на отлично
• Мне нравится решение реализовать эту функциональность через <что-нибудь>

Если студент что-то удачно исправил, то скажите ему об этом. Хвалите хотя бы раз за проверку.

Хвали человека – ругай код

Замечания всегда должны быть направлены на код и никогда — на человека. Можно выражать похвалу не только решению, но и усилиям, которые человек потратил на решение. Особенно если трудно найти объективную причину для похвалы.

Так говорить нельзя

• Вы написали плохой код
• Так нормальные программисты не пишут
• Этот код отстой

Так правильно

• Это решение приводит к таким-то проблемам
• Это неудачное решение потому что
• Алгоритм можно реализовать проще, например если сделать так
• Стало лучше, но надо доработать вот этот момент

Стараемся формулировать замечания в положительном ключе, не «это плохой код», а «этот код можно сильно сократить/доработать/упростить».

Не указывай

Студенту важно понимать причинно-следственные связи почему одно решение лучше другого, а не получать установки «делай так, потому что так правильно». Использование слов «должен» нужно сводить к минимуму.

Так говорить нельзя

• Эта переменная должна называться так
• Вы должны реализовать этот алгоритм так
• Вы должны переписать этот кусок кода

Так правильно

• Такое название будет лучше отражать суть
• Имя функции должно быть глаголом (в таком варианте использовать допустимо)
• Этот модуль не может зависеть от источника данных, так как процесс парсинга работает только с данными

Направление, а не ответ

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

• Прочитайте эту статью про цепочки: https://ru.hexlet.io/blog/posts/sovershennyy-kod-proektirovanie-funktsiy она позволит улучшить код модуля.
• Про дефолты рассказывается в этом видео: https://www.youtube.com/watch?v=vkUTX1hruF8 оно длинное, но я рекомендую посмотреть целиком и обратить внимание на фрагмент с дефолтами.
• В этом решении не учитывается один кейс. Что произойдет если сеть начнет тормозить? Попробуйте воспроизвести такую неисправность и ошибка всплывёт сама.
• Представьте что вам пришли такие данные на вход. Как это повлияет на код? Покройте этот кейс в тестах.

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

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

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

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

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

Заключение

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

Дополнительные материалы

1. Хендбук Хекслета. Про эмпатию.

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.