Новые задачи старшего разработчика

У меня есть старший разработчик с восьмилетним опытом работы в .NET, который завтра начнет работать над приложением из 11 000 строк кода. В команде есть я и еще один программист. У каждого из нас есть по три года опыта.

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

Как долго я должен дать им, прежде чем они будут готовы писать новые функции и исправлять ошибки?

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

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

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

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

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

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

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

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

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

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

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

Сколько?

Как долго это веревка?

Когда ему удобно: когда он исправляет свою первую ошибку -> он готов .

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

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

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

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

Я работал около 80 часов в первую неделю (проект серьезно отставал).

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

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

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