Как наставлять младшего программиста

Попробуйте выделить между 30-60 минутами в день, чтобы просмотреть их код вместе. Если вы не можете этого сделать, то попробуйте собраться вместе, чтобы просмотреть их код всякий раз, когда они делают фиксацию кода, если только это не было очень простым. Попросите их объяснить, почему они выбрали тот подход, который выбрали вместо других. Такой процесс помогает установить отличные отношения, а также действительно стимулирует студента думать самостоятельно и уметь отстаивать свои решения. Мало того, что студент в конечном итоге получает доступного человека, которому он может доверять, но вы почти сразу заметите улучшение качества его кода и логики.

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

У меня была возможность работать стажером (одним из двух) в небольшой компании по разработке программного обеспечения и иметь возможность работать над проектом "almost new", который они имели. Они заставили меня настроить все необходимое и дали мне представление о том, что на самом деле представляет собой проект (основные вещи, такие как требования и т. д.).

Сначала мы должны были выполнять мелкие задачи, такие как исследование вещей, которые имели значение для проекта (они дали нам список тем). Это было, я думаю, чтобы увидеть, как много мы могли бы справиться сами, так как вещи, которые нам нужно было искать и исследовать, были не такими уж тривиальными, и это заняло добрых 2 недели или около того (считая основные демо-версии, которые мы должны были создать для этого). Эта фаза тестирования на самом деле была сделана действительно без особого 'coaching'.

Однако после этого периода мы могли бы работать над самим проектом. Это был также момент, когда мы начали тренироваться вместе , в том же стиле, что и парное программирование, за исключением того, что нас было трое (2 стажера и 1 'coach').

Мы многому у него научились, но это было в неофициальной манере, и он вел себя совсем не так, как тот парень "27". Когда у нас появлялись предложения, он выслушивал их и вместе с нами обдумывал, хороши ли они. или изложите свою точку зрения на то, почему идея не должна быть реализована таким образом... Теперь, когда я думаю об этом, он активно поощрял нас делать предложения и думать о лучших способах делать вещи, а не просто сидеть там 'taking orders' от кого-то, кто, вероятно, знает, что делать лучше, чем вы.

Так что вкратце:

• Пусть младший программист работает (в основном) самостоятельно, изучая имеющиеся материалы, дайте ему список незначительных вещей, таких как поиск информации или создание небольших демо-версий.
• Проверьте работу, которую он регулярно выполнял, и посоветуйте ему, есть ли лучшие способы сделать это. Также укажите на предметы, которые он действительно сделал хорошо, чтобы он запомнил их на потом.
• Пусть он работает над реальным проектом и наставляет его, работая вместе в одном проекте, давая ему советы, когда у него есть вопросы.
• Усилия должны исходить с двух сторон: побуждать его задавать вопросы, бросать вызов "тому, как это делается в настоящее время". Задавайте ему вопросы о том, как, по его мнению, это должно быть сделано, а также дайте ему свое мнение.
• Сделайте это 'enjoyable' - не позволяйте ему выглядеть так, будто вы отдаете приказы.

Во время стажировки w/ в крупной компании, у которой было много в доме IT, я был в паре w/ наставником. Эта практика определенно способствовала моему карьерному росту, как с точки зрения технических навыков, так и деловых навыков. Вот некоторые из причин, по которым наставничество сработало так хорошо:

• Заслуживающий доверия: наставник имел более чем 8-летний опыт и опытную подготовку, на которую можно было опираться в руководстве и обучении. Он прошел через разные испытания, работал в разных условиях, поэтому у него была отличная перспектива.
• Подлинное: наставничество поощрялось руководителем, но не настолько формально, чтобы сделать его упражнением в выполнении движений. Наставник хотел быть наставником, а я хотел у кого-то учиться.
• Страсть: наставник любил ту область, в которой он был, проблемы, которые он решал, и технологии, которые он использовал. Когда я попал под его крыло, то обнаружил, что это заразительно.
• Острый и четкий: наставник подходил к вопросам критически и кратко формулировал их. В наших дискуссиях не было много неясности; мы добрались до сути вопроса, и он направил меня на мудрые пути решения проблем и действий.
• Значимая: работа, которую я выполнял w/ наставник был значимой работой, а не просто упражнением, чтобы продолжать заниматься или наращивать набор навыков. Совместными усилиями работая над задачей, которая ощутимо помогла организации, что помогло сфокусировать мой интерес и узаконить процесс наставничества.

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

Я был бы младшим, я думаю :) я думаю, что буду ценить неформальный подход. Это, вероятно, во многом зависит от характера вашего подопечного, но я бы сказал, что вы учитесь лучше всего, если у вас нет эго на пути. Сломайте лед, убедитесь, что есть обратная связь в обоих направлениях. Такие вещи, как просмотр кода (в обоих направлениях?) и иногда парное программирование может работать, и если есть хороший матч, это может быть очень весело, а также!

Поскольку мне пришлось объяснять, почему я хочу co-op (помимо того, что мне нужны деньги) во время моего интервью, мой менеджер убедился, что мой первый проект позволил мне работать над тем, что я определил как слабые области: очень мало опыта Linux (я выбрал команду Linux-только R&D, чтобы я был вынужден учиться), не зная полезного текстового редактора (я действительно хотел выучить Vim) и как выучить другой язык программирования (совсем другой подход, чем изучение языка, когда вы учитесь программировать). Он сказал мне, что мне платят за то, чтобы я какое-то время учился.

Я лучше всего учусь, читая книги, поэтому после смеха над Unix для чайников (ура! Я был не единственным, кто считал это непонятным и иногда тупым) я начал с Unix в двух словах и практического руководства Собелла по Linux командам . После этого я распечатал документацию Vim и начал ее просматривать. Затем я просмотрел пару книг по Python, языку моего первого проекта. Мне дали все необходимое время, чтобы чувствовать себя комфортно в этих вещах (что было настоящей проблемой, как я теперь понимаю), а затем начали добавлять функциональность к предыдущему проекту co-op.

Теперь я понимаю, что было бы здорово встречаться с кем-то каждый день или два для проверки кода, как сказал наемник-камикадзе.

Вот был бы мой короткий список:

Парное программирование-это полезно для многих вещей, таких как подкрепление различных идей и практик. Привыкнуть к Resharper гораздо проще, когда вы соединяетесь с кем-то, кто часто его использует.

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

Обратная связь и предложения-Вот что происходило в обоих вышеперечисленных случаях. Такие книги, как "How to Win Friends and Influence People" Дэйла Карнеги, могут помочь в понимании различных динамик человеческих отношений, которые, хотя это звучит довольно технически, на самом деле просто о том, как мотивировать кого-то еще различными способами. Ключевой момент здесь заключается в том, чтобы знать, как оставить trail хлебных крошек, чтобы забрать некоторые практики, например, давать намек за намеком о чем-то, а не просто давать ответ. У меня были разные учителя математики, у которых был дар к этому для того, как я развил некоторые из этих навыков.

Таким образом, часть этого просто мотивирует другого человека и пытается направлять его, поскольку, когда кто-то что-то выясняет для себя, это может быть вдохновляющим и просветляющим опытом. "I did it! That's right, moi, yours truly!" вид самовыражения очень хорош, когда это происходит.

По моему опыту, при наставничестве кого-то очень важно, чтобы подопечный действительно WANT узнал больше.

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

Спросите их, что бы они попытались сделать дальше, чтобы выполнить эту задачу. Это может дать представление о том, где от категории "I don't know what to do" до "Well, I would try this but..." находятся они с точки зрения наличия своей собственной идеи, которая может быть полезна для отправной точки.

Быстро взгляните на то, что они хотят сделать, и предложите подсказки, чтобы они поняли проблему. Это вместо того, чтобы дать ответ, "Just take out this line of code," предложите им посмотреть, что там есть и все ли это нужно

Я бы рекомендовал начать давать части реальных заданий, которые у вас есть, и сделать все, чтобы иметь возможность использовать его код. Другими словами, тренируйте его как замену себе.

Таким образом, вы возьмете на себя обязательство выделить время для работы с младшим, и он сможет увидеть "real life". Работая над реальными заданиями и слушая живую обратную связь, он сможет довольно быстро заставить p ускориться.

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

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

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

Я уже наставлял нескольких младших сотрудников под моим началом. Мой подход немного менялся в зависимости от человека, немного в зависимости от того, как он учился.

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

Надеюсь, это немного поможет.