Недавно мой менеджер поручил мне больше играть ведущую роль в помощи в формировании некоторых новых разработчиков в команде. У меня большой опыт работы с кодовой базой, с которой они имеют дело, поэтому иногда он просто позволяет мне распределять проблемы.
Чаще всего возникают вопросы разной сложности. У меня нет проблем с раздачей очень простых, но для тех, которые требуют понимания большего количества частей кодовой базы, я обычно добавляю некоторые мысли в заявку, чтобы дать им лучшее понимание того, что может происходить.
В последнее время по некоторым проблемам некоторые из новых разработчиков, естественно, задают много вопросов. У меня есть очень плохая привычка неизбежно говорить им, что должно быть исправление.
Что такое хороший баланс для этого? Хотя я действительно хочу, чтобы они сами разобрались в проблеме, я также чувствую себя странно, скрывая от них информацию. В то же время я думаю, что стоит позволить им разобраться в этом самостоятельно, даже если это означает, что им может потребоваться некоторое время, чтобы понять, что происходит. Кроме того, как правильно ответить тому, кто задает очень простой вопрос, который, как мне кажется, он должен решить самостоятельно?
У вас есть документация, или вы документы? Если последнее - очень плохо, они будут ссылаться на документы столько, сколько смогут, и вам придется ответить. Конечно, вы можете начать записывать все, что знаете, а затем ссылаться на это, чтобы со временем в вас не было необходимости.
В другом случае отправьте их к документам и укажите области кода, которые им нужно изучить. Если вы добавите некоторые архитектурные знания, которые помогут, но затем, как только вы покажете им, где искать, оставьте их. к этому.
Еще одна полезная вещь — проверка кода. Скажите им, чтобы они придумали любое решение, которое они считают лучшим, но принесли его вам для проверки перед началом любого кодирования. Это помогает им обрести уверенность в том, что они все сделали правильно, прежде чем устроить беспорядок. Когда они лучше узнают систему, переместите свой обзор кода на фактический код после того, как решение будет закодировано, и используйте возможность объяснить любые области, в которых они ошиблись или (что более вероятно) можно было бы сделать лучше или больше в соответствии с кодовой базой. .
Со временем они станут более уверенными и автономными.
Похоже, у вас врожденные педагогические наклонности. Но также похоже, что вы либо немного новичок в их применении, либо вам не хватает поощрения, чтобы придерживаться своих принципов. Быть преподавателем (или руководителем группы, что имеет много общего) требует от вас настойчивости, чтобы не давать ответов. Вы можете использовать несколько позитивных образовательных подходов:
- Действовать как резонансная доска для тех, кто выражает проблемы. В этом случае вам может даже не понадобиться активно реагировать, а просто пассивно получать.
-Обсудите проблему , поставленную перед вами вашими коллегами. Либо притворяясь, что ищу разъяснений по этому поводу, либо искренне подтверждая, в чем проблема. Через это косвенно может возникнуть ответ.
- Когда вам задают вопрос, упомяните, что вы «не уверены» и что они, возможно, захотят попробовать или проверить то-то и то-то место, а затем извинитесь и скажите им, что вы скоро вернетесь; когда вы вернетесь, спросите их, достигли ли они чего-нибудь в своих поисках.
-Последний пункт - и это золото. Мне почти не хочется раскрывать это здесь. Озвучивайте свои внутренние мыслительные процессы, когда вы на работе. Ваши коллеги услышат, что вы говорите, и научатся быть более независимыми.
Лилиенталь
Килиси
Кевин Сюй