Колонка Сергея Немчинского исходит из простого, но непопулярного вывода: отказ от джунов подрезает команде «крылья» в длинной перспективе. Автор апеллирует к более чем двадцатилетнему опыту в разработке и менеджменте и утверждает, что компаниям опасно полагаться на узкий круг «суперсеньоров». Ключевой риск — bus factor: «количество людей, которые должны исчезнуть, чтобы ваш проект упал». Если этот фактор равен 1, бизнес сидит на бомбе замедленного действия.
«Сильному разработчику неинтересно делать джуновские задачи… А вы остаетесь с проектом, в котором все знал только один».
Дуэт middle + junior: почему это работает
Вместо «искусственной изоляции» команды из одних мидлов и сеньоров автор предлагает дать сильному middle помощника-джуна. Аргумент — разгрузка от мелких задач и возможность фокусироваться на сложном, а также естественное выращивание преемников. Отдельный акцент — продуктивный тандем с ИИ: «джуны, которые используют AI как усилитель, могут выполнять задачи в 2–3 раза быстрее». Параллельно старшие инженеры прокачивают навык наставничества — без него не вырасти в тимлида или архитектора.
Какими должны быть джуны (и какими — нет)
Звучит жестко, но честно: рынок не ждет «теоретиков без практики». Автор прямо говорит, что кандидат с pet-проектом, минимальной практикой по инструментам (Git, Docker), реальными или смоделированными API выглядит совсем иначе, чем тот, кто лишь «прошел курс». Суть проста: покажите работоспособность на маленьких, но завершенных проектах.
Стабильность важна для бизнеса
Компании не любят зависимость от одного «носителя знаний». Текучесть, выгорание, отпуска — рутина, поэтому команда должна быть именно командой, а не сольным проектом. Выросшие внутри специалисты лучше знают продукт и быстрее адаптируются. И их проще найти, чем уникального сеньора.
Фокус на результат, а не на миллисекунды
Немчинский напоминает банальность, о которой часто забывают: мы в IT, чтобы решать бизнес-задачи, а не ради «красивой оптимизации». Преждевременная оптимизация съедает время и фокус — без ощутимой пользы для продукта. Сначала должен заработать функционал, а «полировка» — потом.
«Человек сидит и придумывает, как сделать лучше то, что еще даже не работает».
Метафора с музыкантами удачно объясняет, почему «джун — это не ноль». «Джун — это не тот, кто ничего не умеет. Это тот, кто еще не играл на большой сцене», — пишет Немчинский. То есть инструментальная база уже есть: аккорды, ритм-секция, ансамбль. Не хватает только сцены — и это как раз роль работодателя и ментора: дать первые выступления под присмотром и с инструкциями.
Практические советы для джунов от автора
- Не верьте мантре «джуны не нужны». Нужны — но те, кто учатся и доводят задачи до финиша.
- Умейте читать чужой код, задавайте вопросы, признавайте «не знаю, но разберусь» — и действительно разбирайтесь.
- Думайте о маленьких шагах с измеримым результатом — именно их хочет видеть команда.
YouTube
Вывод
Колонка Немчинского — не «апология джунов», а прагматичный манифест управления риском и роста команды. Младшие разработчики нужны, если вы хотите, чтобы продукт был поддерживаемым, люди — взаимозаменяемыми, а знания — распределенными. Джун — не «расход», если заранее договориться о процессе: наставничество, чек-листы, ревью, прозрачные ожидания и короткие итерации. Команда от этого сильнее сегодня и заметно дешевле завтра — когда «тот самый» человек уйдет в отпуск, сменит команду или просто выключит ноутбук в 18:00.
Если свести все к сути, месседж простой: сильные команды формируются доверием, системным обучением и регулярным обменом знаниями. Ни один инженер не стартует сеньором — все когда-то ошибались и учились на этих ошибках. Поэтому игнорировать джунов — это либо забывать собственный путь, либо уходить от ответственности за их онбординг.
