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