Коли ви заходите на Djinni або DOU і бачите фразу «джуни не потрібні», хочеться виламувати двері. Бо що, серйозно? У вас усе настільки добре, що немає сенсу виховувати нових фахівців?
Я не романтизую — працюю в ІТ понад 20 років, керував командами в Ciklum, Luxoft, NetCracker, створив школу, яка навчає не теоріям, а практиці. І ось вам чесно і без прикрас — чому роль junior розробника все ще має сенс, і чому думка «джуни — тягар» часто шкодить бізнесу більше, ніж допомагає.
Навіщо джуни, якщо є сіньйори?
Мені часто пишуть — джуни в ІТ сьогодні непотрібні, бо один middle plus може все: і код, і архітектуру, і навіть каву собі зварити. Але тут є нюанс.
Сильному розробнику нецікаво робити джунівські задачі. Йому стає нудно. Він втомлюється від дрібниць і… йде. А ви залишаєтесь із проєктом, в якому все знав тільки один. Здогадуєтесь, до чого я веду?
Це і є басфактор — кількість людей, які мають зникнути, щоб ваш проєкт упав. Якщо таких людей у вас один — то фактор дорівнює одиниці. І це погано. У реальному світі така ситуація — бомба сповільненої дії. Зовні все працює, а всередині вже формується криза.
А якщо спробувати інакше?
Я не пропоную набирати купу джунів і кидати їх у продакшн. Але якщо у вас є сильний middle, який розгрібає все підряд — дайте йому помічника. Так, джуна. Так, ще й з ШІ у кишені.
Бо джуни та штучний інтелект — це не жарт. Джуни, які використовують AI як підсилювач, можуть робити задачі у 2–3 рази швидше. І вони вчаться. А ваш middle — зосереджується на тому, що справді важливо. І так поступово ви ростите не лише проєкт, а й команду.
Щобільше, джуни допомагають старшим розробникам прокачуватись у нову навичку: менторство. Пояснювати, передавати знання, делегувати — це теж частина зростання. І дуже цінна, якщо людина планує стати тімлідом або архітектором.
Чим джунів готувати до реальності?
Не всі джуни однакові. І ринок справді не потребує «теоретиків без практики», які не знають, що таке pull request чи як поставити Docker. Але якщо джун приходить із pet-проєктом, з розумінням базових інструментів, якщо він хоч раз працював з реальними API або хоча б імітував роботу з командою — це вже хороший кандидат.
Мій досвід показує: як знайти першу роботу в ІТ — це питання не про вдачу, а про підготовку. Всі, хто готував себе чесно, з практикою і фідбеком, — врешті заходили на ринок. Не завжди з першого разу, але заходили.
Мені подобається приклад із музикантами. Джун — це не «той, хто нічого не вміє». Це той, хто ще не грав на великій сцені. Але вже вивчив акорди, награвся вдома, навчився грати в ансамблі. І якщо ви дасте йому шанс, за рік ви матимете сильного гравця, якого не треба шукати по рекрутерах.
Бізнес не любить нестабільність
Якщо ви — керівник, і у вас вся система тримається на одному розробнику, у мене для вас новини: ви у зоні ризику. І дуже великого, бо люди звільняються, вигорають, іноді просто зникають — фізично чи морально.
Тому команда розробки має бути командою, а не солістом на біс. І тут знову джуни рятують ситуацію. Вони підтягуються, покривають дрібні задачі, навчаються на прикладі. І що важливо — їх легше замінити. Це не образа, це факт. Джунів легше навчити нового, ніж знайти ще одного суперсіньйора, який витягне ваш проєкт з болота.
Плюс — якщо ви вирощуєте спеціаліста всередині, він добре знає ваш продукт. Йому не треба вчитись з нуля. Він у темі. І це теж — перевага, яка недооцінена.
ІТ — це не про мілісекунди, а про стратегічні рішення
Ми — розробники. Ми тут, щоб вирішувати бізнес-проблеми. Автоматизувати, покращувати, підтримувати. І саме це має бути в центрі. Не фреймворк, не мода, не оптимізація заради оптимізації.
А фічі, функціонал, результат, все інше — додаткове.
Передчасна оптимізація коду — це типова помилка. І найчастіше вона забирає не лише час, а й фокус. Людина сидить і вигадує, як зробити краще те, що ще навіть не працює. А бізнес у цей момент чекає на реальний результат. І якщо результату нема — байдуже, скільки там мілісекунд.
Якщо ви — джун, цей розділ для вас
Не вірте в ці «джуни не потрібні». Це неправда.
Потрібні. Але потрібні не просто «люди без досвіду». Потрібні ті, хто вчиться, працює над собою, створює pet-проєкти, не боїться ШІ, бере дрібні задачі й доводить їх до кінця. Це те, що показує працездатність.
Порада проста: навчіться доводити задачі до результату. Покажіть, що ви можете брати маленьку частину великої системи — і не зламати її. Що ви вмієте читати код, питати, коли не розумієте, і не боятись сказати «я не знаю, але розберуся». І розберіться. Інакше — навіщо ви тут?
Висновок
Джуни в ІТ були, є і будуть. Бо ніхто не народжується senior developer’ом. Усі ми колись були «зеленими», плутались у гілках Git’у, боялися pull request'ів і ламали staging.
Тому ті, хто сьогодні задирають носа й кажуть, що джуни — не потрібні, забувають про власний шлях. Або просто не хочуть відповідальності.
Але сильні команди — ростуть із довіри, навчання і передачі досвіду. Без цього ніякий ШІ вас не врятує. Тож підтримуйте джунів. Будьте людьми. І будуйте команду, а не вежу з однієї цеглини