Нові завдання старшого розробника

У мене є старший розробник з восьмирічним досвідом .NET, починаючи завтра, щоб працювати над додатком 11 000 рядків коду. У колективі є я та ще один програміст. Ми обидва маємо близько трьох років досвіду кожен.

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

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

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

Найважливіше, що потрібно зробити, - це перегляд коду всієї його роботи протягом перших двох тижнів. Ви не хочете дізнатися, що хлопець піде в неправильному напрямку чи не дотримується стандартів кодування компанії місяцями. Краще переконатися, що він знає, що очікується від самого початку, і огляди коду це забезпечують. Звичайно, я думаю, що огляди коду хороші для всіх співробітників (Ми розглядаємо 100% нашого коду перед тим, як розгорнути), але вони є критичними для нових співробітників, і їх слід робити особисто, де ви можете відповісти на запитання та направити їх на документацію, якої вони можуть не мати. бачили ще, якщо потрібно.

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

Одне, що я помітив навіть у досвідчених розробників, - це те, що деякі з них не такі хороші, як здалося в інтерв'ю, огляд коду допоможе вам це швидко дізнатися, тому ви зможете це виправити. Це також заохотить їх насправді щось зробити, я бачив нових співробітників, які не перевіряли код, перетягують проект, не показуючи нікому, що роблять, а потім залишають за тиждень до граничного терміну, коли вони знали, що не збираються вдарити, тому що вони були над головою і фактично не завершили жодну частину проекту. Краще рано і часто перевіряти нових людей, поки ви не переконаєтесь, що вони працюють.

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

Якщо у вас є певний час, коли від нього не очікується повноцінного внеску (і повністю враховує свій час клієнтом), це також може бути час, коли він може почати деякі ті рефакторні речі, які ви хотіли зробити, але не хочете ' не встиг зробити. Іноді, корисно використовувати новий навчальний період для вирішення деяких речей, які відсутні в плані проекту. Вони можуть вивчити кодову базу, і якщо те, що вони хочуть зробити, не працює, ви не вплинули на існуючі розклади, оскільки ви ще не включили їх у існуючий графік. І якщо це все-таки спрацює, можливо, ви отримаєте великий виграш, полегшивши майбутнє обслуговування або покращити безпеку, або будь-яка проблема.

Почніть їх негайно з невеликих завдань - речей, які не потребують більшого зображення.

Коли вони стануть більш впевненими та знайомими з кодовою базою, переходьте їх на більші та більші завдання. Наскільки швидко це відбувається в основному залежить від них.

Мені завжди подобається отримувати завдання, призначені мені справа від кажана, з розумінням того, що копати код буде потрібно набагато більше часу, і протягом багатьох днів / тижнів буде задано багато питань.

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

Крім того ... Як би ви не думали, що ви пояснили, як працює проект, завжди є "о так, я забув тобі сказати", "ми зіткнулися з цією проблемою, і ми зробили це" моменти, які не дратуються до ви фактично починаєте роботу.

Як довго?

Скільки часу триває мотузка?

Коли йому зручно: коли він виправить свою першу помилку -> він готовий .

У спільноті з відкритим кодом кожен, хто хотів долучитися до проекту, спочатку має справу з невеликими проблемами. Якщо він чи вона може впоратись із цією проблемою, то важливіше завдання буде покладено на нього чи на неї. Таким чином вони стануть основним розробником проекту.

Цей старший розробник має вісім років досвіду .NET, тому ви можете призначити йому кілька простих помилок, щоб виправити. Якщо йому легко впоратися з ними, ви можете призначити йому складні проблеми, щоб допомогти йому ознайомитися з усією програмою. Після цього він міг почати писати нові функції та аналізувати дивні проблеми. Просто зробіть це, часу на налаштування немає!

8 років досвіду. Я б просто кинув його. Він повинен вміти плавати. Як зазначають інші, починайте з невеликих легких завдань. Це дозволить йому переглядати процес реєстрації / виїзду коду та будь-які інші процеси розробки, які у вас є.

Я неодноразово міняв роботу, і протягом першого тижня я брав участь у всіх них. Найскладніше мені знадобився тиждень, щоб отримати код для компіляції (принаймні 100 к + рядків коду). Повний збір займав 8 годин для цього проекту.

Я працював щось на кшталт 80 годин перший тиждень (проект серйозно відставав).

Для маленького додатка та досвідченого розробника, я думаю, що дня достатньо для основних помилок. Помилки чи невеликі функції ближче до тижня (як тільки вони зрозуміють проблематичний домен та архітектуру).

Відповідь: це залежить. Якщо ви хочете, щоб він виправив одну помилку на чомусь або змінив колір GUI-елемента, то приблизно 5 хвилин (ось де ми зберігаємо наш код), якщо ви хочете, щоб повністю переробити всю архітектуру програми, яка буде потрібно трохи довше.

Це дійсно залежить від того, яке завдання ви очікуєте від нього.