Есть ли у кого-нибудь предложения о том, как наставлять младшего программиста? Если вы наследовали кого-то, вы следовали любому процессу или были ли это довольно неофициальным?
Если вы были наставниками в прошлом, какие вещи вы считаете наиболее полезными?
Попробуйте выделить 30-60 минут в день, чтобы просмотреть их код вместе. Если вы не можете этого сделать, попробуйте собраться, чтобы просмотреть свой код, когда они совершают кодовое коммитирование, если только оно не является очень простым. Попросите их объяснить, почему они выбрали подход, который они использовали вместо других. Подобный процесс помогает установить отличные отношения, а также действительно стимулировать ученика мыслить самостоятельно и быть способным отстаивать свои решения. Студент не только получает доступ к кому-то, кому можно доверять, но вы сразу заметите улучшение их качества кода и логики.
Изменить. Кроме того, если вы не можете совершить это много времени для совместного просмотра с вашим младшим, то вы, вероятно, не должны наставлять их, а вместо этого видите, есть ли у кого-либо еще расписание, это позволит. Весь смысл наставничества - активно содействовать профессиональному развитию ученика, и они не собираются многому научиться, если им не уделяется должного внимания и наставлений.
У меня была возможность работать в качестве стажера (одна из двух) в небольшой компании-разработчике программного обеспечения и имела возможность работать над "почти новым" проектом, который у них был. Они заставили меня настроиться на все необходимое и дали мне представление о том, что на самом деле было проектом (основные вещи, например, какие требования были и т.д.).
Сначала нам приходилось выполнять второстепенные задачи, такие как исследование вещей, имеющих значение для проекта (они дали нам список тем). Это было, я думаю, посмотреть, как много мы могли бы справиться с собой, поскольку вещи, которые нам нужно было искать и исследовать, были не такими тривиальными, и потребовалось две недели или около того (считая основные демо, которые мы должны были создать для него), Эта фаза тестирования была фактически выполнена без особого "коучинга".
Однако после этого периода мы могли бы работать над самим проектом. Это было также в тот момент, когда мы начали тренироваться вместе, в аналогичном стиле парное программирование, за исключением трех из нас (2 стажера и 1 'тренер').
Мы многому научились у него, но это было неформально, и он не действовал как парень "всезнающий-слушай меня". Когда у нас были предложения, он слушал и думал с нами, были ли они хорошими. или дать свой взгляд на то, почему идея не должна быть сделана таким образом... Теперь, когда я думаю об этом, он активно поощрял нас делать предложения и думать о лучших способах делать что-то, а не просто сидеть там заказы "от кого-то, кто, вероятно, знает, что делать лучше, чем вы.
Короче говоря:
Во время стажировки с крупной компанией, у которой было много ИТ-услуг, я был в паре с наставником. Практика определенно помогла мне в развитии карьеры, как с точки зрения технических навыков, так и с деловыми навыками. Вот некоторые из причин, по которым наставничество сложилось так хорошо:
В моем первом месте работы был этот действительно пациент, который всегда помогал бы мне решить мою непосредственную проблему, а затем научил меня некоторому важному основному принципу. Мне это нравилось, потому что он помог мне оставаться продуктивным, обучая меня тому, как стать лучшим программистом.
Я был бы младшим, я думаю:) Я думаю, что ценю неформальный подход. Вероятно, это зависит от ваших персонажей и ваших персонажей, но я бы сказал, что вы учитесь лучше, если у вас нет эго в пути. Разбейте лед, убедитесь, что в обоих направлениях есть обратная связь. Такие вещи, как просмотр кода (в обоих направлениях?) И случайное программирование на пару, могут работать, и если есть хорошее совпадение, это тоже может быть очень весело!
Поскольку мне приходилось объяснять, почему я хотел сотрудничать (помимо того, что мне нужны деньги) во время моего интервью, мой менеджер убедился, что мой первый проект позволил мне работать над тем, что я назвал слабыми: очень мало опыта Linux ( Я выбрал группу R & D только для Linux, поэтому я был бы вынужден учиться), не зная полезного текстового редактора (я действительно хотел узнать Vim) и как изучать другой язык программирования (очень отличный подход, чем изучение языка как вы учитесь программировать). Он сказал мне, что мне платят за некоторое время.
Я больше всего учусь, читая книги, поэтому, посмеявшись над Unix для чайников (yay!), я был не единственным, кто думал, что это было неясным и иногда сумасшедшим). Я начал с Unix в двух словах и в Sobell Практическое руководство по командам Linux, После этого я распечатал документацию Vim и начал ее просматривать. Затем я просмотрел пару книг на Python, языке моего первого проекта. Мне все время приходилось чувствовать себя комфортно в отношении этих вещей (это была настоящая проблема, как я теперь понимаю), а затем начал добавлять функциональность к предыдущему совместному проекту.
Я понимаю, что было бы потрясающе встречаться с кем-то каждый день или два для проверки кода, как сказал наемник Камикадзе.
Спросите их, что они поставят рядом с задачей. Это может дать представление о том, где из "Я не знаю, что делать", чтобы "Ну, я бы попробовал это, но...", они относятся к идее, которая может быть полезной для начальной точки.
Взгляните на то, что они хотят сделать, и предложите подсказки, чтобы они поняли проблему. Это скорее, чем дать ответ "Просто выньте эту строку кода", предложите им посмотреть, что есть, и все это необходимо
Я бы порекомендовал начать давать части реальных заданий, которые у вас есть, и сделать все, чтобы использовать его код. Другими словами, обучите его замене для себя.
Таким образом, вы обязуетесь выделить время для работы с младшим, и он сможет увидеть "реальную жизнь". Работая над реальными заданиями и слушая оживленную обратную связь, он сможет быстро получить скорость.
Недостаток этого подхода заключается в том, что возможно, что он будет слишком узко сосредоточен на вашем конкретном проекте. Поэтому обязательно покажите учащимся возможные альтернативы и попробуйте анализ компромиссов, чтобы расширить его профессиональный горизонт.
Несколько лет назад я работал в небольшой компании, где в первый день мне был предоставлен список небольших задач для завершения - сделайте небольшие изменения в коде, найдите и исправьте небольшую ошибку в проекте. Это действительно помогло мне задать правильные вопросы у моего наставника и ознакомиться с окружающей средой, основой кода. Эти задачи были легко завершены, поэтому у меня было немного уверенности в себе, прежде чем обращаться к более крупным задачам.
Этот способ наставничества действительно работал со мной очень хорошо, поэтому я планирую сделать то же самое с нашим новым коллегой.
Вот мой короткий список:
Паровое программирование - это полезно для многих вещей, таких как усиление различных идей и практик. Привыкать к Resharper намного проще, когда вы встречаетесь с тем, кто часто его использует.
Неофициальные чаты. Здесь мы будем выпить, выходить на улицу для того, чтобы кто-то мог отдохнуть, пойти на обед вместе и т.д. Вдали от столов обсуждение может быть связано с работой, выполняемой немедленно или это может быть абстрактная философская штука, которая может помочь принести кому-то игру на ступеньку или две. Говорить о различных предстоящих технологиях или изменениях в том, что может быть захватывающим, и помочь формировать облигации.
Обратная связь и предложения. Это то, что произошло в обоих случаях. Такие книги, как "Как завоевать друзей и влиять на людей" Дейла Карнеги, могут помочь в понимании динамики разных человеческих отношений, которая, хотя звучит довольно технически, - это просто то, как мотивировать кого-то другим по-разному. Ключевым моментом здесь является знать, как оставить след панировочных сухарей, чтобы поднять некоторые практики, например, дать подсказку после намека на что-то, а не просто дать ответ. У меня были разные учителя математики, у которых был подарок для этого, поскольку я разработал некоторые из этих навыков.
Таким образом, часть этого просто мотивирует другого человека и пытается направить их так, как когда кто-то что-то делает для себя, это может быть усиливающим и просвещающим опытом. "Я сделал это! Это правда, мой, твой!" вид саморекламы довольно хорош, когда это происходит.
В моем опыте, когда наставничество кому-то, очень важно, чтобы наставник действительно ХОЧУ больше узнать.
Никогда не кормите их ложкой. Вместо этого укажите их на ценные вещи и попросите их использовать новую информацию, которую они изучают в проектах, которые они используют. Знания бесполезны, если их не применять на практике. Поэтому поощряйте ваш менторский код, код, код, код.
Я наставлял нескольких младших людей под себя раньше. Мой подход несколько отличался от человека немного основанного на том, как они узнали.
Короче говоря, я дал младшим людям небольшие, самодостаточные проекты, когда мог, и дал им относительно фиксированное время для выполнения задачи. По завершении задачи я рассмотрю их подход, код и решение, а также внесет предложения по улучшению или лучший способ справиться с этой проблемой. Я так думаю, что они не чувствуют себя подавленными, будучи частью гораздо более масштабного проекта.
Надеюсь, это немного поможет.