Junior — роскошь

.. а не ресурс разработки Junior — человек, которому вы не можете выдать задачу сложностью выше некоторого уровня, если хотите, чтобы задача была решена в нужные вам сроки. Таким макаром в разных монастырях один и тот же человек может быть ранжирован не одинаково. В Кукусофте он middle, в Почтоваре он junior, а в учреждении для общественного воспитания детей дошкольного возраста и вовсе senior. Зависит от задач и сроков.
Ещё три исходящих пункта.
Раз. Джуниор (впрочем, как и любой другой) интересен тогда, когда для него есть фронт задач его уровня. Иными словами, стоимость их решения адекватна.
Два. Джуниор интересен тогда, когда из него хотят и могут [почти] любой ценой сделать что-нибудь другое. Характерно для больших компаний, выращивающих себе кадры, особенно штучные (тот же ШАД Яндекса примером).
Три. Джуниор интересен тогда, когда интересен не задачами и не ростом. Бывают занятные схемы. Скажем, вы аутсорсер, по контракту оплачивают работу с учётом занятых на проекте голов, выгодно эти головы набрать и демонстрировать. Это Вася. У него димплом МГУ, он джавист, уважаемый Джон Смит, похлопайте Васе и перечислите нам очередной транш. Что там за знания у Васи, чем он реально занят… никого не волнует. Такие схемы обсуждать не будем, достаточно того, что оно бывает и к разработке не относится.

Ещё ремарка про стоимость джуниоров. Давайте на пальцах следующую формулу зарплаты изобретём (почти по рынку, хоть для красоты округлил): J(unior) = n, M(iddle) = 2*J, S(enior) = 2*M. Это вот зарплата. Но работодателя интересует стоимость решений. Если junior делает софт 4 месяца, а senior тот же софт за 1 месяц, видим смешное: junior выпустил продукт на три месяца позже при senior’ной стоимости решения.
Слишком чистенько. На деле живые джуны делают ещё дольше и требуют ещё больше вложений. Они перетягивают на себя внимание middle+ (code review, консультации). Плохо интегрируются с нужной бюрократией (тексты коммитов, тикеты в JIRA). Плохо понимают командную работу (тусить в изоляции, забив на состояние мира вокруг — штатное состояние). Понимание ответственности на нуле (для них часто по воображаемым последствиям примерно равны «мама, я застелил постель» (не застелил) и «Аристарх Петрович, я протестировал все изменения перед выкаткой» (не все, не протестировал)), что добавляет рандома в production.
Всё это вместе с исправлением, обучением и банальным надзором замедляет работу остальных, что влияет на стоимость уже их решений. И, что прикольно, всё это в какой-то момент может оказаться пустотой — то вдруг оказывается, что чувак не подходит профессии. Или у него прошло увлечение и теперь он хочет на лыжах кататься. Или просто зайку не ценят и потому зайка уходит в монастырь. Или начитался про успешные стартапы и уходит в загул пилить Super Duper ToDo Tracker, который обязательно поглотит рынок.

Также нередко джуниоров, если они прям юные, надо учить:

  • жить («Сань, давай в будний вечер ты не будешь бухать до похмелья с утра, тебе два критикала срочно разрулить»),
  • общаться («Олег, заказчик не твой друзяшка со двора, давай не бычить и вообще полезно быть вежливым»),
  • взрослеть («Стёп, ты же обещал? Обещал. Не выполнил и знал заранее, что не выполнишь. Давай в следующий раз ты подойдёшь и скажешь заранее, что не успеваешь, чёт придумаем»)
  • и матереть («Филь, вот чего ты молча в пол смотрел? Тебя Иваныч сожрать собирался шоле? Нет. Голову поднять, факты озвучить, логикой задавить, в глаза смотреть спокойно, задачу не ты просрал, не тебе отвечать»).

И ещё куче шняг. Нет, в целом-то это не так уж напряжно, если не вспоминать, что окружающие на работу нанимались не любящими родственниками приёмным детишкам, но разработчиками / лидами. А то же лидство вопреки сладким фантазиям не включает в себя изготовление мужей из мальчиков.


Теперь подумайте и себе честно ответ: нафига всё это работодателю? Обычной софтварной конторе от гаражика до «это здание всё наше». Не приюту. Не благотворительному фонду. Не школе для одарённых детей. Не яростной молотилке кадров, в которой в день сто страниц копипасты. Вот нафига? Middle и senior выгоднее. Головняка с ними заметно меньше. Рандома в проде заметно меньше. Ставить их на путь истинный тоже проще, бойцы уже биты жизнью, могут гонор в карман спрятать и таки сделать то, что надо, а не «я так вижу». Прогноз работы с ними тоже проще — если до middle добрался, есть куда толкать и выращивать. Потому в общем случае джуниоров не нанимают. Убыточно. Проблемно. Результат не спрогнозировать. Нафиг надо.
Исключения бывают, безусловно (особенно когда у исключения «глаза горят», учебники от зубов отлетают и в анамнезе годный код на GitHub’е, тут прям удовольствие смотреть, как талант раскрывается). Но меня подбешивает, когда на голубом глазу говорят «а чё, ну наберите роту джуниоров, воспитайте, вот вам и будут кадры». Нет, спасибо. Сами набирайте. Все люди хорошие, братья, друзья и ромашки, но иногда полезнее тикеты вовремя закрывать, а не переоткрывать по десять раз, выполняя гражданский долг матери Терезы.
PS. Конечно, вы не такой junior. Это какие-то другие такие. А вы самый умный, самый хороший, самый клёвый junior в мире.

Junior — роскошь: 3 комментария

  1. К джуну нужен особый подход: учитывать, что сроки он сорвёт (не всегда, но лучше не надеяться), код с первого раза будет грязным (-1 рабочий час миддла на ревью), к проду допускать только если выстроен CI (вот пускай сам и строит – сроки не горят, а польза будет). А ещё некоторые задачи как сеньор, так и джун делают за примерно одинаковое время: текст у кнопки поменять, в админке поле добавить…

    Я как правило даю _не срочную_ рутину и иногда серьёзные задачи, чтобы проверить уровень. Авось через полгодика джун сможет забрать с меня часть обязанностей.

  2. Для маленькой компании, да 99,9% что это роскошь, для компании, которой нужны люди скорее суровая необходимость.
    О джунах почти целый раздел есть в книге Джоэля Спольски «И снова о программировании», о том как он это видит, как ищет и как тренирует в своей компании.
    Это своего рода лотерея, но может повезти и это будет тот человек, который останется в компании и будет приносить пользу. Если хороших работников всё устраивает, то они не будут просто так уходить из фирмы.
    А еще можно задавать вопросы и хорошие вопросы тоже чего-то стоят. Объясняя кому-то еще лучше начинает понимать тот, кто объясняет.
    Относительно времени, может быть юниор вообще не напишет тот код, который может написать сеньор.
    Про учить, так это везде не только в IT, опыту не взяться на пустом месте.
    Так что и компании и люди, которые хотят быть джунами в обоюдо сложной проблеме, одним надо набрать тех что сможет вырасти, вторым доказать, что именно они нужны фирме.

  3. Капитан Очевидность вопрошает: что же делать всем тем несчастным, которых угораздило не попасть в когорту «Исключения бывают, безусловно (особенно когда у исключения «глаза горят», учебники от зубов отлетают и в анамнезе годный код на GitHub’е, тут прям удовольствие смотреть, как талант раскрывается). «, если их не рекомендуется брать? Вырастать сразу в мидла, перепрыгивая через ступень джуниора?
    P.S. Не подумайте, что с претензией, просто часто такое мнение видел, но на очень многие позиции ищут людей, с навыками, рода: 20 лет. в армии служил, 3 года опыта в разработке.

Добавить комментарий