Как включить новичков в свой проект?

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

Мы используем Python / Django, у которого есть некоторые из самых дружественных документов и простой способ учиться.

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

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

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

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

Является ли общепринятой практикой обучение людей программированию на уровне общего / хобби? Как «продвижение вверх» в софтверной компании работает для программистов младшего уровня? Когда они начинают работать над основным кодом?

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

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

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

Парень был измученным переутомленным беспорядком и худшим перфекционистом микроуправления, с которым я когда-либо работал. Я должен был облегчить его работу, но он потратил почти столько же времени на беспокойство, проверяя меня и мою работу, сколько я тратил на работу (он почти никогда не уходил из офиса, я думаю, он презирал свою семью). Если бы я сделал хотя бы одну ошибку, он бы полностью потерял рассудок и начинал рассуждать: «Я знал, что не должен был доверять тебе это, это было бы слишком важно!» и другие ранты.

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

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

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

Я работал в магазине программного обеспечения, где мы кодировали большой проект (значительное время разработки).

С новичками обращались как с ветеринарами. Они были назначены техническим лидером и начали функции "самостоятельно". Архитектурный стиль был продиктован, но они могли свободно придумывать свой чистый дизайн. «Странные шаблоны проектирования» были отсеяны во время (ежедневных) проверок кода.

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

Удачи!

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

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

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

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

Единственное, что я когда-либо делал в этой области, - это учил людей, как использовать программу составления отчетов или какой-нибудь VBA / Macro-код для Excel. Я обычно даю наборы данных для повторного использования. Заставить их изучать SQL довольно сложно, но я видел, как это было сделано (заплатили за то, что они прошли внешнее обучение). Большинство из этих людей были финансовыми аналитиками, у которых была возможность научиться кодировать, но, возможно, не нашли время. Попытка сделать это с некоторыми людьми в операциях - это длинный путь.

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

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