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

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

Я пытался спорить с моим менеджером, что имеет смысл, чтобы младшие программисты, которые проявляют высокую способность, взяли новых программистов под свое крыло. Во-первых, это освободит старших разработчиков для работы над более важными инициативами (не то, чтобы наставничество не важно). Затем, это даст юным программистам немного гордости за свою работу, за то, что на них будут возлагать такую ​​ответственность, и они могут чему-то научиться в процессе обучения. Наконец, это сэкономит компании деньги, так как старшие разработчики стоят намного дороже, чем юниоры.

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

** Мы все можем согласиться с тем, что старшинство не обязательно означает компетентность, поэтому просто предположим, что «старшие программисты» я имею в виду «лучшие программисты».

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

Это сработало довольно хорошо. До этого несколько старших разработчиков начинали искать новые рабочие места, потому что их не оспаривали на работе. После этого они смогли поработать над новыми функциями и выполнить работу. Что ваши старшие разработчики думают о ситуации?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я думаю, что это работает лучше всего, когда наставники добровольно выполняют задание. Здесь у нас нет очень формального процесса наставничества. Иногда наш менеджер имеет в виду что-то конкретное, но иногда он говорит что-то вроде: «У кого-нибудь есть хорошая идея для проекта для нового парня?» и тот, у кого есть лучшая идея, заканчивает заниматься наставничеством.

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