Привет, Хабр!
Хочу поделится своими соображениями о перспективах роста и развития «пожилых» (в возрасте более 40 лет) разработчиков. Статья будет полна субъективизма и антитолерантности, так что всем желающих похоливарить — добро пожаловать в комментарии.
Подбор кандидатов 40+ на должность разработчика
По роду своей профессиональной деятельности мне довольно часто приходится собеседовать кандидатов при найме разработчиков для новых проектов. В среднем, в неделю я участвую в 3–4 собеседованиях со стороны потенциального работодателя и оцениваю профессиональные и личностные навыки кандидатов.
Недавно я поймал себя на мысли, что при отборе резюме соискателей я всё чаще стал обращать внимание на возраст (конечно, наряду с опытом работы, технологическим стеков и прочим). Если возраст кандидата выше 40 лет, то это трактуется как негативный фактор, снижающий потенциальную ценность кандидата. Причины этого, в общем-то, понятны:
Разработчики в возрасте 40+ менее гибки и готовы к изменениям (читай — менее терпимы к хаосу и возможному бардаку в процессах, который в той или иной мере присутствует почти во всех компаниях).
Таким людям сложно взаимодействовать с более молодыми членами команды, причем речь идет как о разнице в системе ценностей и интересов, так и в готовности подчиняться молодым руководителям.
Люди такого возраста обычно уже обзавелись семьей и у них куча других забот помимо работы. Они не готовы кодить днями и ночами «по кайфу», и по ночам разбираться с критичными инцидентами.
Возраст снижает способность к обучению и замедляет процесс (да и желание) изучения новых технологий.
При прочих равных, скорее всего, выберут более молодого кандидата. У него обычно и зарплатные ожидания ниже, и проблем с ним меньше.
Но есть проблемка: куда деваться разработчикам 40+ (мы все ими станем или уже стали)?
Общие тенденции продолжительности жизни и пенсионного возраста
Я думаю, не секрет, что в условиях развития медицины и качества жизни средняя продолжительность жизни человека растет. Она, судя по данным Росстата (хотя такой себе, конечно, источник), в ближайшие 10 лет достигнет 75 лет.
С учетом того, что профессия разработчика сейчас крайне популярна и «войти в IT» пробуют многие (и у многих успешно получается), можно также предположить, что через несколько десятков лет у нас будет много разработчиков в возрасте 40+, которые периодически будут попадать на рынок труда.
При этом, в силу вышеуказанных причин, они не смогут на равных конкурировать с более молодым поколением разработчиков. А амбиции и ожидания у них будут на уровне сеньоров. Они и были сеньорами… в свое время.
Разумеется, будут исключения, и некоторые разработчики и после 40 смогут насыпать перцу под хвост. Также частично справедливо и то, что язык программирования — всего лишь способ реализации логики, и настоящие программисты смогут писать код на любом языке. Всё это в какой-то степени так, но я говорю о «средней температуре по больнице».
В итоге может возникнуть целый пласт разработчиков, которые окончательно дискредитируют возраст 40+. И даже исключительно талантливые ребята, достигнув такой зрелости, будут сталкиваться с проблемами при трудоустройстве, проигрывая конкуренцию более молодым коллегам.
Свой «сукин сын» и пришлый «сукин сын»
Вообще, в этой ситуации нужно четко разделять две разные истории.
Кейс «Свой сукин сын»
Допустим, в компанию приходит работать скромный молодой разработчик, который успешно работает и развивается до определенного уровня. Волею судеб так сложилось, что он растет сначала до миддла, потом до сеньора, но дальше никуда не двигается — ни в IT-менеджмент, ни в какую-то профильную область. Он работает долгое время (скажем, 15 лет) в одной компании, изредка меняет проекты, и в какой-то момент превращается в деда 40+. Но это — свой дед.
За время работы в компании у него складывается широчайшая сеть нетворкинга: он всех знает и его все знают.
Он прекрасно разбирается в бизнес-процессах и в куче смежных областей.
Он лично учил многих ключевых IT-менеджеров или работал в совместных с проектах со многими руководителями, и по отношению к нему есть определенная лояльность
В конце концов, коллектив ему многое прощает, потому что он во многом и является фундаментом этого коллектива.
Это вполне жизнеспособная модель работы такого разработчика. Даже если в силу возраста и скорости развития он не успевает за современными технологиями, можно скомпенсировать это отставание за счет опыта и широкого кругозора.
С годами люди прикипают к окружающей обстановке, людям, компании. Чем больше сотрудник проработал в одной организации, тем сложнее ему уйти из нее. Проработав 10-15 лет в одной лавке, можно быть уверенным, что по своей инициативе сотрудник вряд ли уйдет из компании. Однако если по каким-то причинам компания расстается с таким сотрудником (могут наступить сложные времена), то он автоматически переходит в разряд «пришлого сукина сына».
Иногда удается найти специфическую «нишу» для таких разработчиков. Посадить их на какой-нибудь крупный долгий проект, или на развитие специфического сервиса, который не требует частых изменений и где можно закопаться в стеке, совершенствуя каждую строчку кода. Но риск стать «пришлым сукиным сыном» всё равно есть.
Пример из жизни
Аркадий (имена, естественно, изменены) пришел к нам в 2016 году. Сразу попал в сильную и дружную команду, которая делала внутренний продукт. Через год команду распустили — продукт не выстрелил и оказался ненужным. Аркадию повезло: его перевели в другую команду, которая также занималась другим, более сложным внутренним продуктом.
Приняли его хорошо, он смог выучить новый стек и за счет своего опыта, системности и способности доводить сложные задачи до конца быстро завоевал себе авторитет. Люди в команде менялись, но Аркадий был столпом стабильности. Постепенно он стал самым «знающим» и старым членом в команде. Через некоторое время руководство предложило ему позицию технического лидера, и Аркадий возглавил команду, продолжая развивать сложный внутренний продукт.
Кейс «Пришлый сукин сын»
В компанию изначально приходит разработчик 40+. Допустим, страшнейший кадровый голод, коммиты и дефицит ресурсов заставили брать с рынка вообще всех подряд, и в числе нанятых оказался наш разработчик из кейса «свой сукин сын», с которым старая компания рассталась и он устроился работать в новую.
В этом случае возникает масса проблем, которые делают и новую компанию, и самого разработчика несчастным:
Разработчик привык в старой компании к определенному статусу и уважению. А здесь этого нет: в новой компании авторитет надо зарабатывать по-новой, никакие прошлые заслуги не играют роли.
Совместные мероприятия — тим-билдинги — нашему герою не интересны. Он не так быстро сходится с новыми людьми, да и окружающие его коллеги обычно сильно моложе и у них другие интересы. К тому же дома ждет семья и дети.
Процесс разработки, постановки задач и вывода функциональности в прод, скорее всего, несколько иной, и это требует перестройки от разработчика, вызывая внутренний дискомфорт
Поскольку человек новый и заработанного авторитета еще нет, ему не прощают какие-то особенности поведения, которые в прошлой компании принимались.
Вероятно, в новой компании приняты другие подходы к шаблонам разработки, другие линтеры, да и стек немного другой. Наш дед-разработчик не очень хорошо с ними знаком, а выучить быстро их не получается. Всё это выливается в скрытые или явные конфликты с другими разработчиками или техлидом, в которых наш герой выглядит как «Фома, пришедший со своим уставом в чужой монастырь». Такие острые дискуссии зачастую резонируют с вопросами авторитета, что еще сильнее давит на разработчика.
Всё вышеперечисленное потихоньку приводит к тому, что совместно работать с нашим дедом-разработчиком уже никто не хочет — ни бизнес-заказчик (делает долго, всё переспрашивает), ни разработчики (у нас приняты такие вот правила, а он ходит и брюзжит, что всё плохо и в прошлой компании было лучше).
Итогом может быть очередное расставание, после которого наш герой снова выходит на рынок, подпортив себе репутацию и сильно упав в морали.
Пример из жизни
Калистрат (имена, естественно, изменены) попал к нам в компанию два года назад, и уже на тот момент перешагнул проклятую планку в 40 лет. Скорее всего, обычным способом и не попал бы, но в ходе серии слияний и организационных реструктуризаций старое подразделение, в котором работал Калистрат, было расформировано, а его функции и сервисы перешли в одну из команд нового подразделения.
Судьба у Калистрата не задалась. Сначала он еще приносил пользу, поддерживая legacy-сервисы, при этом с фатализмом наблюдая, как остальная команда трудится над их переписыванием на другом стеке.
В какой то момент, когда legacy-система была выведена из эксплуатации, встал вопрос: а чем заниматься Калистрату? Он честно пытался изучить новый технический стек, и многое даже получалось, но очевидно было, что звездой ему не стать. Более того, в новой системе были свои «хранители знаний» — люди, которые досконально понимали все особенности работы новых систем и процессов; Калистрату среди них места не нашлось.
В какой-то момент Калистрат пришел к руководителю и выступил с инициативой возглавить какую-либо команду, приводя в качестве аргументов свой длительный опыт разработки. Но руководитель не согласился, поскольку опыт был нерелевантен, в новом техническом стеке Калистрат ориентировался на уровне мидла, а управленческого опыта у него не было. Да и с авторитетом среди других разработчиков дела были не особо хорошими.
Калистрат нас покинул полгода назад, через несколько дней после отказа. Его резюме я недавно нашел в HeadHunter. После нас он успел поработать еще в одной организации, но покинул ее после испытательного срока...
Синекура для престарелых джедаев
Пока проблема не стоит так остро, поскольку на рынке просто нет большого количества разработчиков 40+. Но сколько-то таких ребят есть, и куда им деваться? Понятное дело, что кто-то кочует по компаниям, кто-то ушел на пенсию и растит внуков, кто-то нашел себя в специфической нише, кто-то вырос в IT-менеджера или архитектора. Но куда девается основная масса?
Я побеседовал с рядом своих коллег – владельцев IT-лавок, руководителей крупных IT-компаний, и получил ответ на этот вопрос:
Обучение стажеров или преподавание курсов программирования. Знаний и умений разработчиков-олдов хватает для наставления молодого поколения. Тут же присутствует уважение и авторитет со стороны студентов (учителя знают и умеют больше, чем ученики). К тому же у «старичков» удовлетворяется потребность в наставничестве.
Вторая-третья линия поддержки. Достаточно четко определен алгоритм действий, но в то же время какая-то свобода для творчества и исследования багов остается (а баги бывают заковыристые). Обычно — нормированный график, понятное расписание и минимум переработок. В компаниях с налаженными ITSM-процессами это, по-сути, островок стабильности с прозрачными KPI и способами их достижения.
Разработка и поддержка legacy-сервисов в крупных банках. На этих позициях основными привлекающими факторами также являются стабильность и прозрачность. Нормированный график работы, неплохой доход, отсутствие (или оплачиваемые) переработки, знакомый (хотя и устаревший) стек технологий.
Отдельно можно выделить институт «советников» крупных менеджеров. Обычно на такие позиции определяют сотрудников, которых нельзя уволить, но которые уже в силу определенных обстоятельств не могут выполнять обязанности разработчика (или IT-руководителя определенного уровня). Иногда разработчики 40+ попадают на такие позиции в небольшие организации, где вполне находят себя в качестве консультантов генеральных менеджеров и директоров по IT-вопросам.
Я заранее прошу прощения, если мои размышления кого-то обидели и не соответствуют действительности. Я понимаю и согласен с тем, что всегда бывают исключения и есть достаточно много примеров успешного развития разработчика и после 40.
Своей статьей я хочу поднять дискуссию о вашем, читатель, понимании судьбы и перспектив разработчиков после 40 лет. Спасибо за конструктивную обратную связь.