Нужно ли старшим программистам брать наставника младшего разработчика? [закрыто]

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

Я думаю, что это должно поощряться, но не обязательно; старшим не следует назначать юниоров или что-то в этом роде, иначе вы окажетесь в Дилберте. Отношения "наставник-ученик" требуют некоторого уровня дружбы по своей сути, а также здоровой дозы ВЗАИМНОГО уважения. Вы не получите этого, просто сказав людям, чтобы они уходили и «ментали».

Должно ли это быть частью культуры, когда старшие разработчики соединяются с младшими разработчиками в качестве наставников?

Да.

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

Это не случится достаточно часто, чтобы реально помочь кому-либо.

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

Как консультант на протяжении более 30 лет (100-летия привлечения клиентов) я могу утверждать, что новые люди всегда являются аутсайдерами. Это не особенность "культуры" или "атмосферики". Это существенная особенность работы людей. Консультанты формируют свою собственную клику, потому что штатные сотрудники не склонны ни к чему их включать.

Единственный способ установить наставничество - это вводить новых людей в клики.

Традиционное значение слова «наставник» не поддается определению. Вы могли бы также попытаться назначить друзей.

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

Должны ли старшие разработчики быть наставниками младших разработчиков?

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

Или это наставничество должно быть чем-то более органичным и спонтанным, то есть не обязательным, но позволяющим развиваться без искусственного поощрения?

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

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

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

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

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

Мне никогда не нравились термины младшие и старшие программисты. Например, я программировал некоторое время, и хотя у меня есть опыт в некоторых областях, я очень зеленый в других. Например, мы переходим на WPF, и, хотя у меня есть тонны опыта работы с Windows-формами, WPF все еще для меня новичок. Так что, хотя я «старший» программист, вы могли бы нанять кого-нибудь с улицы с гораздо меньшим «общим» опытом, и они, вероятно, могли бы программировать приложение WPF лучше и быстрее, чем я на данный момент.

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

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

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

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

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

Эта индустрия очень отличается. Сеньорство не всегда лучше.

Иногда старшим нужно наставлять юниоров.

Я был в среде, которая делает вещи обоими способами.

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

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

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

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

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

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

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

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

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

Конечно, это поднимает проблему измерения «хорошо» в этом контексте. Несовершенным, но легко реализуемым решением может стать то, что новички через год (возможно, анонимно) напишут имена, скажем, трех лучших людей, которые помогли им интегрироваться в компанию и / или базу кода. После этого вы можете наградить людей, чьи имена упоминаются чаще всего. Денежные вознаграждения здесь не сработают. Лучше найти какую-то социальную награду.

команда руководит структурой, ведущей к проверке кода, должна сделать свое дело ...

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

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

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

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

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

1. Текущий статус - Где сейчас вещи? Какова текущая проблема, которую наставник может оказать помощь в решении?
2. Состояние будущего - Что требуется: подсказка, решение, вопросы, которые нужно задать, кого задавать?
3. Ретроспектива - Что сработало и не сработало при внесении изменений?
4. Будущие изменения - Что в будущем будет испытано, что может сработать лучше, чем было сделано ранее?

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

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

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

IME, вы не можете рассчитывать на развитие отношений наставничества, поэтому предоставьте потенциального наставника путем объединения старшего разработчика и младшего разработчика для набора нормальных парных бизнес-операций (проверки кода, отладка, парное программирование и т. Д.), По крайней мере, в Во-первых, это отличная идея. В идеале, старший член должен быть волонтером для этой роли и уметь воспринимать некоторую личную выгоду. В моей нынешней компании старшие разработчики почти лидируют в своих проектах, и выгода в том, что они создают команду своего собственного проекта. В другой компании наставники часто исследовали путь управления.

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

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

Это требует некоторого сбалансированного управления. Я не уверен, что это распространено.

Для работы любого наставника важно, чтобы руководство осознало, что это важно, и выделило на это время, и активно поощряем это!

Для тех, кто на 100% забронирован с заданиями, буквально нет времени заниматься или получать наставничество, и этого не произойдет.

Обычно корабли наставников являются хорошей стартовой площадкой для перехода от старшего к руководителю команды или менеджеру. Более эффективно связать наставничество с продвижением в PDP (личном плане развития) или в любом другом плане, заслуживающем вашей компании. Связывание увеличения заработной платы и карьерного роста, по крайней мере, частично с их способностью передавать знания и готовить новых разработчиков, является ключом к созданию сильного ИТ-персонала, способного выдержать изменения в управлении и текучести кадров. Постановка ключевых целей и работа с персоналом, чтобы помочь им улучшиться, является частью этого роста в лидерство. Для тех, кто считает несправедливым привязывать оценку старшеклассников к производительности юниоров, которая является частью роста. В большинстве случаев вы говорите не о сокращении зарплаты, а о снижении роста или замедлении роста.

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

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