Складно бути Junior'ом

Мені дійсно пощастило – коли я вперше працевлаштувався за профілем у 2010 році, я потрапив у хорошу компанію і працював поряд з професіоналами високого рівня і просто хорошими людьми. Поруч з ними я швидко зростав. Мені завжди показували хороші практики і дійсно приділяли мені час.
Але не всім так пощастило – багато починали свою кар'єру в конторах досить середнього рівня, де їх просто не було кому вчити. Або зовсім не хотілося.
Я просто хочу розглянути кілька реальних випадків із життя початківців розробників, які я чув, і порівняти ці випадки зі своїм досвідом. Я розгляну лише 3 ситуації, кожна з яких буде складатися з 4 маленьких частин:
  • Історія, яку я чув
  • Що в ній не так
  • Як це було зі мною
  • Короткий висновок
Якщо питань немає, то поїхали.
Ситуація 1: оцінка тимчасових трудовитрат на завдання.
Історія: початківець розробник, ще студент, влаштовується в компанію і чує від тимлида: “Ця задача робиться за 8 годин. Завтра чекаю на результат".
Що не так: чути, що ця задача робиться за N годин – це вже стрес, а в стресових умовах наш мозок працює гірше. Джуніор починає панікувати сильніше, коли кількість відпрацьованих годин наближається до N. До того ж, що тимлидом робиться за 8 годин, у джуніора може відібрати всі 40.
Як це було зі мною: коли я трохи освоївся на проекті, мій тимлид просив мене самостійно оцінювати завдання, причому не просто видавати підсумкову цифру, а докладно розписувати, куди йде час. Таким чином він навчив мене декомпозировать завдання на безліч більш дрібних. Він розумів, що джуніору оцінки не повинні ставитися зверху в жорсткій формі, але одночасно з цим він не давав мені завищувати тимчасові роботи. Він завжди просив мене обґрунтувати, чому саме так, і зазвичай це призводило до більш адекватної оцінки з мого боку.
Короткий висновок: потрібно розуміти, що ви взяли новачка. Йому потрібно приділяти час і розуміти, що навіть швидкі завдання часом займають час.
Ситуація 2: переписування коду.
Історія: початківець розробник отримує завдання і виконує її. Тимлид, через якийсь час, бачить написаний в рамках цієї задачі код, тихо лається і править його. Закінчивши редагування, він, задоволений собою, коммитит його і забуває про все.
Що не так: джуніор так і не зрозумів, у чому саме був його косяк. Після рефакторінгу він бачить нехай навіть чудовий код, але він у ньому навряд чи розбереться. Тимлид стабільно витрачає свій час на рефакторинг замість того, щоб витратити його на навчання свого падавана і вирощування сильного фахівця, який навіть через рік вже буде вимагати набагато меншого контролю.
Як це було зі мною: тимлид, після перевірки мого коду, сідав поруч і говорив: «Дивися, а от що станеться, якщо я передам цього методу пустий рядок на вхід?». І я тоді невпевнено відповідав: «NullPointerException?». Він погоджувався і пропонував мені самому здогадуватися, як можна уникнути цієї ситуації. Зазвичай у нас не йшло більше 5 хвилин на обговорення, а потім він за наступні 5 хвилин докладно пояснював мені, що ще мені потрібно врахувати. У підсумку витрачено часу тимлида: 10 хвилин. Результат: варто того.
Короткий висновок: Навчайте своїх підлеглих. Якщо ви переписуєте код новачка, поясніть йому, навіщо це було зроблено і вкажіть на його помилки. Це дозволить надалі уникнути цих помилок і зайвого переписування.
Ситуація 3: code review. Точніше, його відсутність.
Історія: схожа з історією з попереднього пункту. Студент пише код в рамках якогось завдання, потім тимлид одним оком і по діагоналі дивиться на код і перевіряє, що все працює. Потім дає студенту наступну задачу.
Що не так: складно врахувати всі зміни, лише побіжно переглянувши бранч. До того ж, код рев'ю якраз і націлена на те, щоб не пропускати поганий код, а також навчати і вказувати на їх косяки. І, звичайно ж, допомагати їм від цих косяків позбавлятися.
Як це було зі мною: на жаль, коли я починав, цю практику не використали дуже активно на нашому проекті. Тому, тимлид ретельно порівнював мій бранч з основним (тоді ще він називався trunc (svn)), а потім підсідав до мене і говорив: «Дивися, а що трапиться, якщо...». Ну, а далі ви вже знаєте.
Короткий висновок: завжди використовуйте всю силу code review. Це не тільки не дозволить поганому кодом закрастися в систему, але і в зручній і зрозумілій формі допоможе відобразити всі проблемні місця, пояснити джуніору його косяки і допомогти йому подолати їх.
Менторинг
Ще хочу сказати про таку корисну штуку, як менторинг. Річ ця дуже гарна, і справді важко переоцінити його користь. Він так чи інакше включає в себе всі попередні пункти і не тільки. Діліться знаннями – рекомендуйте книги, відповідайте на запитання та допомагайте розібратися в дрібницях.
висновки
Довгих заключних промов не вийде, тому просто – мотивуйте новачків на досягнення вершин і даруєте їм дружню атмосферу. Всім приємно працювати в компаніях, які цінують своїх працівників, нехай навіть наймолодших. Але ці молоді працівники через рік-два стануть вже досить досвідченими і зможуть без додаткового контролю приносити реальну користь компанії. До того ж, завжди приємно, коли хтось перебирає твій досвід, і це допомагає йому стати, хоч в чомусь краще.
Ну, і завжди варто пам'ятати, що в зірвані терміни винен не той джуніор, що довго порпається в коді", а його тимлид.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.