Насколько сложно найти нового Java-разработчика? Этот вопрос мне задал технический директор, раздосадованный тем, что я никак не могу найти нового разработчика ПО для проекта.
К тому времени я провел собеседование с несколькими кандидатами и пришел к выводу, что ни один из них не соответствует заявленным в вакансии требованиям.
Спустя пару недель наша команда нашла подходящего специалиста, что избавило меня от объяснения истинной причины, по которой я не рекомендовал предыдущих соискателей.
Дело было в нас, а не в них.
Мысль, которую я пытался донести до отвергнутых кандидатов, заключалась в следующем: хотя они могли удовлетворить ближайшие требования проекта — мы были бы счастливы заполнить открытую вакансию, — работа в нашем технологическом стеке не стала бы для них оптимальным выбором в долгосрочной перспективе.
Сейчас, когда прошло достаточно времени и проект завершен, могу продемонстрировать эту мысль с помощью структурной модели.
В этой статье я раскрою смысл этой модели и приведу пару случаев из личного опыта, подтверждающих ее значимость как для новичков в IT-сфере, так и для продвинутых специалистов.
Модель “Иерархия карьерных приоритетов”
Я адаптировал пирамиду Маслоу “Иерархия потребностей” к профессиональной сфере и назвал свою модель “Иерархия карьерных приоритетов”.
Согласно теории Маслоу, для достижения самоактуализации — вершины личностного роста — человек, движимый постоянным стремлением к самосовершенствованию, совершает подъем от низших уровней приоритетов к высшим. Аналогичным образом происходит и достижение профессионального успеха. Представим этот процесс в виде восхождения по карьерной лестнице со следующими ступенями.
- Трудоспособность (Employability). Стартовая, базовая, карьерная ступень соответствует первому уровню пирамиды Маслоу “Физиологические потребности”. Эта ступень означает соответствие человека основным требованиям трудоустройства, включая образование, профподготовку, ученую степень и навыки, востребованные на рынке труда.
- Вознаграждение и стабильность (Compensation and Stability). Вторая карьерная ступень (у Маслоу “Потребности в безопасности”) предполагает наличие постоянной работы и получаемого за нее вознаграждения, адекватного затраченному времени и квалификационному уровню, а также обеспечение благоприятной рабочей обстановки.
- Рост и развитие (Growth and Development). Третья карьерная ступень (у Маслоу “Социальные потребности”) предполагает непрерывное обучение, повышение квалификации и профессиональный рост. На этой ступени работа не только позволяет, но и требует от специалиста развивать профессиональные компетенции, чтобы соответствовать занимаемой должности и сохранить возможность трудоустройства в будущем. Кроме того, эта ступень означает способность обеспечить жизнеспособность и перспективный рост бизнес-проектов.
- Сбалансированность трудовой жизни и благополучие (Work-Life Balance and Well-Being). Четвертая ступень (у Маслоу “Самоуважение”) посвящена достижению баланса в трудовой жизни как психологической составляющей работы сотрудника на предприятии и поддержке его общего благополучия. Суть этой ступени заключается в поддержании оптимального соотношения между работой и отдыхом, управлении стрессом, а также в том, чтобы отдавать приоритет психическому и физическому здоровью.
- Цель и смысл (Purpose and Meaning). Это вершина “Иерархии карьерных приоритетов” (у Маслоу “Духовные потребности: самоактуализация”), где люди ищут цель и смысл выбранного ими карьерного пути. Высшая ступень включает приведение личных ценностей в соответствие с карьерными приоритетами, оказание положительного влияния на коллег и стремление к самореализации помимо материального вознаграждения и поощрения извне.
В идеале выбор места работы должен способствовать равноценности перечисленных приоритетов. В реальной жизни этого добиться практически невозможно, но понимание потенциальных дисбалансов позволяет исправить их скорее раньше, чем позже.
Вот несколько распространенных примеров дисбалансов в карьере.
- Щедрый пакет вознаграждений побуждает человека жертвовать благополучием: работать неделями без выходных в режиме изматывающих авиаперелетов.
- Человек мирится с пребыванием в должности без перспективы профессионального роста и развития.
- Достигнув предела мастерства в устаревающем технологическом стеке, специалист предпочитает карьерный рост на текущей работе более перспективным возможностям трудоустройства.
В следующих разделах я буду ссылаться на эту модель, перечисляя наиболее важные уроки, извлеченные мной из собственных карьерных успехов и неудач.
Урок 1-й. Технологический стек определяет возможность трудоустройства
Этот урок является “белым пятном” скорее для менеджеров проектов и руководителей кадровых служб, чем для разработчиков ПО.
Совет “Учись или зарабатывай” подходит для новичков в профессии, но по мере продвижения по карьерной лестнице он трансформируется в “Учись или не зарабатывай”.
За последние 40 лет индустрия программного обеспечения прошла путь от взаимозависимых отношений “работа на всю жизнь” (в нескольких локальных технологических стеках) до невероятно короткого срока пребывания в должности. Это побудило работодателей перестать рассматривать “готовность к смене работы” как к негативную черту соискателя.
В результате успешные сотрудники, привыкшие работать на одном месте в течение всей жизни, теперь сталкиваются с необходимостью принятия новых технологий (в противном случае их инструментарий неизбежно устареет).
Заметьте, я не высказываю личного суждения о какой-либо технологии. Просто размышляю о практике найма в целом, когда работодатели все чаще прибегают к автоматизации для выявления соответствия резюме кандидатов своим требованиям.
Специалисты по персоналу могут порекомендовать периодически проходить профобучение, чтобы быть в курсе новых тенденций при работе с устаревающими технологиями. Однако разработчики ПО и работодатели знают, что навыки, не используемые на рабочем месте, быстро утрачиваются.
Например, наниматель, ищущий специалиста с 5-летним опытом работы в React, скорее всего, отбросит резюме, демонстрирующее многолетний стаж в JavaServer Faces, даже при наличии в нем пункта о прохождении пару лет назад курса по React. И наоборот, любая компания, использующая JavaServer Faces в качестве основного UI-фреймворка, наверняка постарается привлечь в свою команду соответствующих специалистов.
По этим причинам следует признать (и это может оказаться трудным осознанием для работодателей): с точки зрения сохранения трудоспособности, технологический стек продукта является наиболее важным фактором для сотрудников.
Да, плохой начальник может заставить человека уволиться, но даже лучшему из начальников будет трудно нанять специалистов для работы с технологическим стеком, спрос на который падает на рынке труда.
Понятно, что менеджеры по продуктам и компании в целом не заинтересованы в полной или даже частичной реорганизации технологического стека по соображениям трудоустройства. И все же им следует периодически проводить совещания с руководителями кадровых служб, чтобы иметь представление о влиянии их проектов на трудоспособность сотрудников в будущем.
Урок 2-й. Три года как срок жизни технологии
Технологические стеки могут оставаться актуальными в течение длительного времени. Посмотрите, как долго сохраняют свою востребованность языки программирования, такие как COBOL, или аппаратные технологии, такие как мейнфреймы.
Однако не все технологические стеки обладают такой способностью.
Для тех из них, которые не является основой бизнеса в современном мире, три года — это “волшебный” период, когда новые технологии могут внезапно впасть в немилость IT-сообщества.
Собираясь сделать очередной шаге в карьере или освоить новую популярную технологию, не поддавайтесь соблазну гнаться за тем, что актуально сегодня, — обратите внимание на то, что станет востребованным в ближайшие три года.
Обратите внимание, что “три года” — результат эмпирического наблюдения.
Иллюстраций этого наблюдения может служить динамика распространения языков программирования за последнее десятилетие, выявляемая путем анализа активности пользователей GitHub:
Почему языки программирования используются в качестве показателей актуальности технологических стеков? Потому что распространение языков программирования коррелирует с изменениями в технологическом ландшафте. Например, судьба Ruby связана с популярным фреймворком Rails, распространение COBOL зависит исключительно от экосистемы мейнфреймов, а C# является языком программирования для платформы .Net.
За три года, с 2015 по 2018 год, Ruby резко упал в рейтинге, опустившись с 5-го места на 10-е и уступив растущей популярности TypeScript, расширенной версии чемпиона среди востребованных языков программирования — JavaScript.
Кстати, за 3 года, с 2017 по 2020, Typescript взлетел с 10-го места на 4-е.
А посмотрите, что произошло с PHP — надежным инструментом трудоустройства, который противостоял распространению фреймворков для веб-разработки вплоть до 2019 года, когда началось его стремительное падение с 4-го места до 7-го к 2022 году.
Если вы начинаете карьеру сегодня, то владение любым языком программирования, который не является мейнстримом в интересующей вас области, станет помехой для трудоустройства в будущем.
Под “мейнстримом” я подразумеваю такие варианты, как Javascript для фронтенд-разработки, Python для машинного обучения и Go для разработки систем. Можно не согласиться с этими конкретными примерами — например, вы можете предпочесть Rust языку Go, — но принцип остается незыблемым.
Если для вас приоритетом является перспектива трудоустройства, найдите движущийся центр мейнстрима и нацельтесь на него.
В следующем разделе рассмотрим риск чрезмерной ориентации на эту цели.
Урок 3-й. Осторожно относитесь к новоиспеченным технологиям
Каждый, кто регулярно ездит на автобусе, учится принимать критически важные решения.
Это происходит, когда вы опаздываете на остановку и видите издалека, что пассажиры уже заходят в автобус. В такие моменты приходится выбирать одно из двух: бежать к остановке или ждать следующего автобуса.
Вы также уясняете, что погоня за уже поехавшим автобусом редко того стоит.
Узнавая о зарождающихся трендах, не поддавайтесь ажиотажу, а думайте о возможности трудоустройства. Речь идет не об игнорировании новых тенденций — ознакомление с ними полезно в принципе. Но я бы не советовал полностью погружаться в эти тенденции, не подстраховавшись на случай, если, вместо профессионального роста и развития, ваши перспективы будут ограничены высокопоставленной или руководящей должностью.
Имейте в виду: управление новой технологией потребует многократных корректировок курса и усиленного контроля ущерба, чтобы пользователи почувствовали себя уверенно и стали вам доверять. Другими словами, баланс между работой и отдыхом наверняка будет нарушен.
Я лично испытал это между 2013 и 2015 годами (еще один 3-летний период), когда Cloud Foundry и Docker, изначально определившие сферу оркестровки контейнеров, доминировали в ней.
Мой работодатель объединился с создателем Cloud Foundry и в начале 2014 года запустил публичное предложение, известное как Bluemix. Оно быстро стало крупнейшим в мире развертыванием Cloud Foundry с более чем миллионом пользователей. По многим оценкам, это был несомненный успех.
Я присоединился к этому проекту с самого начала и возглавил отдел производственного проектирования. До этого я работал в качестве технического руководителя трех команд разработчиков программного обеспечения. Это был большой скачок, а значит, и большой риск.
Однако на моем карьерном пути возникло препятствие планетарного масштаба.
Позже в том же году наша компания инвестировала еще в одно новое предложение, основанное на проекте с открытым исходным кодом и имевшее забавное греческое название. Речь идет о выпущенном Google в начале 2014 года Kubernetes — оркестраторе облачных рабочих нагрузок. Это программное обеспечение стало известно как основа умопомрачительных по масштабу рабочих нагрузок Google.
Благодаря миллиардным инвестициям, звездному составу специалистов и многочисленным сторонникам среди разработчиков, стоящих за Kubernetes, конкуренция закончилась, не успев начаться.
За относительно короткий период — три года — Cloud Foundry и Docker Enterprise растеряли весь запал, необходимый для новых внедрений. Привлеченные к тому времени заказчики потратили годы на то, чтобы справиться с дорогостоящей перепланировкой рабочих нагрузок, переоснащением конвейеров CI/CD и переподготовкой сотрудников для работы с новыми кластерами Kubernetes.
Для меня это не было фатальной карьерной неудачей. Я познакомился с людьми из разных слоев общества, а изнурительный график компенсировался значительным увеличением зарплаты. И даже спустя столько лет я убежден в том, что каждый разработчик ПО должен несколько лет поработать в операционном отделе.
Тем не менее к концу этого перехода мои навыки работы с Cloud Foundry оказались бесполезными на рынке труда.
Урок 4-й. Остерегайтесь проектов в узкоспециализированных предметных областях
Этот урок связан с проектом, в который я пришел сразу после окончания работы в Cloud Foundry. Я упоминал о нем в самом начале статьи, рассказывая о том, с каким трудом нам удалось заполнить вакансию разработчика ПО.
Продукт представлял собой хостинговое предложение для поставщиков медицинских услуг в области онкологии. С точки зрения технологий, основной упор делался на биоинформатику и обработку естественного языка.
Больше всего меня привлекала возможность работать с учеными-лаборантами и врачами-онкологами. Применение НЛП в поиске альтернативных методов лечения, направленных на спасение жизней раковых больных, придавало смысл и цель моей карьере. Такой возможности у меня не было ни в одном другом проекте.
Однако наш технологический стек вступал в 3-летний период, в течение которого быстро терял актуальность, особенно для SaaS-предложений.
- Хостинг? Все работало на виртуальных машинах. Контейнеров не было и в помине.
- Язык программирования? Java.
- Персистентный слой? DB2.
- Пользовательский интерфейс? AngularJS.
- Управление задачами и исходным кодом? Jazz.
- CI? Ant и Jenkins.
- CD? В основном вручную, с многочасовыми окнами планового обслуживания.
За исключением непростительного использования устаревшего фреймворка Ant вместо Maven в слое CI, все остальное было бы правильным выбором еще за пару лет до начала проекта.
Короче говоря, наше решение было вполне разумным, полностью реализуемым и экономически эффективным. Выбор компонентов стека был оправданным с точки зрения бизнеса, но для опытного разработчика ПО этот стек был дорогой к устареванию навыков.
Небольшой, но показательный пример — использование системы управления исходным кодом Jazz. В тот год, когда я пришел в проект, наша компания заключила договор о стратегическом партнерстве с GitHub, что открыло путь к переходу с Jazz на репозитории GitHub для внутренних проектов. Наш проект так и не перешел с Jazz, потому что не было смысла переводить весь код и процессы сборки на новую систему управления исходным кодом, не говоря уже о том, чтобы переучивать всех разработчиков на использование Git.
Тем не менее, с точки зрения разработчиков ПО, ценность навыков Jazz для трудоустройства в последующие годы постоянно снижалась — почти обратно пропорционально повышению ценности навыков Git, GitHub и GitLab.
Обратимся к более актуальному примеру. Для запроса всех изменений в генетическом образце, хранящемся в базе данных, разработчику ПО не нужно было разбираться в онкобиологии. Требовалось наладить контакт с онкобиологами, работающими в команде, объяснить им структуру таблиц, представляющих данные, и выяснить, какие атрибуты в таблице представляют эти уникальные изменения.
В то же время на рынке труда наблюдался рост спроса на навыки работы с MongoDB — образцом NoSQL-систем — Cassandra, Neo4J, Apache Spark и Hadoop.
И хотя Java был и остается востребованным навыком на рынке труда, люди, работающие с бэкендом проектов, наблюдали, как Python постепенно становится основным языком программирования для всего, что связано с машинным обучением и обработкой естественного языка. Как будто этого было недостаточно, Facebook и Google быстро выпустили PyTorch и TensorFlow, увеличив темп устаревания навыков для тех, кто работал над проблемами машинного обучения на Java.
За пару лет наш технологический стек превратился из разумного выбора в то, что никто не стал бы рассматривать для разработки нового проекта.
В конечном итоге именно поэтому мы с трудом находили новых разработчиков ПО, в то время как научная команда набирала все более впечатляющие кадры.
Даже если бы в тот момент у меня в голове не было четкой модели карьерных приоритетов, я бы открыто говорил кандидатам о компромиссах между уникальными возможностями работы в специализированной области и негативным ее влиянием на их рост и развитие в долгосрочной перспективе.
Некоторые кандидаты проявляли повышенный интерес к компонентам проекта, связанным с биоинформатикой и НЛП. Поскольку мы не набирали сотрудников для работы в этих областях, я открыто говорил, что работа над этими компонентами будет зависеть от изменений в их должностных обязанностях и, следовательно, не гарантирована.
Я все еще дорожу этим опытом. Но при этом осознаю печальную участь разработчиков ПО, имеющих дело с недифференцированными технологиями в узкоспециализированной области: эксперты в таких областях необходимы, разработчики ПО — нет.
Я понял это через три года после начала проекта, когда стало ясно, что спрос не приведет к значимым финансовым результатам.
Команда была значительно сокращена, чтобы сэкономить бюджет, хотя оставалась надежда на перелом в ситуации. Всем, кто не работал непосредственно с биоинформатикой или машинным обучением, а это большинство кадровых разработчиков ПО, было предложено поискать другие возможности трудоустройства в компании, в том числе и мне.
Урок 5-й. Не теряйте времени, пока оно у вас есть
Обратимся снова к аналогии с автобусом. Есть кое-что похуже, чем опоздать на автобус — сесть не в тот автобус.
Печальный вывод из моей истории заключается в следующем: хотя я четко осознавал свое стремление перейти на облачную разработку ПО, период между неудачным стартом в Cloud Foundry и увлекательным “сайд-степом” в сторону биологии растянулся в шесть лет, которые сегодня могут показаться одним мигом.
Для человека, находящегося на середине карьерного пути, шесть лет — критически долгий путь.
Мне потребовалось найти новую работу, потратив еще три года, чтобы догнать свой автобус под названием “Kubernetes” и занять в нем место, приобретя навыки работы с платформой и репутацию человека, способного консультировать других разработчиков и системных администраторов.
В итоге прошло девять лет.
Для выпускника шесть лет, потраченные на движение в неправильном направлении, — время, определяющее всю карьеру.
Многие скажут, что “неправильное направление” — понятие относительное, а приобрести разнообразный опыт перед тем, как приступить к разработке ПО в более позднем возрасте, вполне возможно и даже желательно.
Я с этим не согласен. Один из уважаемых мной разработчиков ПО имеет ученую степень по литературе и более десяти лет посвятил концертной деятельности, играя на различных музыкальных инструментах, прежде чем начать успешную карьеру в области разработки ПО.
Однако чаще всего попытки уклониться от карьерного пути и пропуск значимых технологических сдвигов могут надолго затормозить прогресс человека, стремящегося достичь профессионального роста в сфере технологий.
Да, у нас всегда есть время, но карьерные шаги измеряются годами, и с каждым годом резервы наших возможностей становятся все меньше.
Заключение
Мой главный совет разработчикам ПО, да и вообще любым специалистам, — постоянно отслеживать свое продвижение по карьерной лестнице, пользуясь моделью “Иерархии карьерных приоритетов”.
Не бывает неправильных карьерных путей, но могут быть неосторожные шаги. Простое выставление стрелки “вверх” или “вниз” на каждом уровне карьерной пирамиды значительно облегчит принятие оптимального решения о том, оставаться ли в нынешней должности или переходить на новую.
Осознавая это, можно оптимизировать один или несколько уровней, например предпочесть более высокое вознаграждение более интересной работе или пожертвовать балансом между работой и отдыхом ради более быстрого продвижения к своим жизненным целям.
Можно и вовсе пропустить какие-то уровни, например решив выполнять любимую работу в некоммерческой организации практически без зарплаты или сделав ставку на стартап, не гарантирующий успеха и стабильного дохода.
Однако подобные дисбалансы имеют тенденцию к устранению и восстановлению естественного порядка приоритетов. Дисбаланс может проявляться по-разному: депрессией, вызванной отсутствием смысла в работе, эмоциональным выгоранием из-за изнурительных 80-часовых рабочих недель или сокращением возможностей трудоустройства из-за работы с устаревшими технологическими стеками.
А работа мечты может оказаться не такой уж и приятной, если обернется неожиданными вычетами или проблемами с личными финансами, возникающими из-за нерегулярной выплаты зарплаты.
Независимо от выбранного пути, система оценки своей карьеры — лучший инструмент для принятия решений, будь то ставка на рискованный стартап или отказ от работы, которая становится потенциальным препятствием для развития карьеры.
Модель иерархии карьерных приоритетов также полезна для компаний, оценивающих свою привлекательность в глазах потенциальных кандидатов, особенно когда технологии меняются быстрее, чем проекты успевают реагировать на эти изменения.
И последнее напутствие: не переставайте стремиться к цели и смыслу. Успехов!
Читайте также:
- Пора делать шаг по карьерной лестнице разработчика?
- Из финансов в разработку: как стать инженером-программистом
- 21 серьёзная ошибка за 21 год работы программистом
Читайте нас в Telegram, VK и Дзен
Перевод статьи Denilson Nastacio: The Ultimate Guide for Making the Best Career Choices in Tech
