Как стать ценным кадром: 6 советов для карьерного роста разработчика
2026-02-21 17:59 Diff
https://skillbox.ru/media/code/kak-stat-tsennym-kadrom-6-sovetov-dlya-karernogo-rosta-razrabotchika/

#статьи

  • 5 апр 2024
  • 0

Опытный техдир Глеб Михеев объясняет, почему совершенный код ещё не гарантия повышения по службе.

Кадр: фильм «Мстители» / Marvel Studios Inc. / Paramount Pictures

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

Есть много советов, как развиваться программисту: учить матчасть, набивать шишки на практике, становиться идеальным «таск-киллером». Но что делать, если привычные способы расти не работают, а любые попытки достичь прогресса упираются в невидимый барьер?

Меня зовут Глеб Михеев, я с 2003 года занимаюсь разработкой, а с 2018 года руковожу программным комитетом конференции FrontendConf. Девять лет я развивал свою компанию по заказной разработке — за это время я провёл десятки или даже сотни собеседований и вырастил (или участвовал в росте) многих классных специалистов.

Расскажу, как действовать, чтобы бизнес за вас держался: эти советы принесут вам больше ответственности, навыков и, конечно, денег.

Руководитель программного комитета FrontendConf, автор телеграм-канала «Уставший техдир», спикер отраслевых конференций.

Часто (особенно если читать дискуссии в интернете) цели разработчиков сводятся только к деньгам и комфорту. Люди пишут, что хотят получать 300 тысяч в секунду, работать удалённо и жить на сказочном Бали.

Увеличить доход — достойная цель, но её недостаточно: даже если вы начнёте зарабатывать больше, можно обнаружить себя в не близкой по духу компании, решающим скучные задачи и не получающим удовольствия от профессии. Это вызовет страдания и экзистенциальные вопросы, а там и до выгорания и бед с ментальным здоровьем недалеко.

Важно, чтобы цель несла в себе ценности и смыслы, значимые лично для вас. Например, её можно сформулировать так:

«Хочу быть сеньор-разработчиком в большой корпорации, создавать сложные технические решения, которые используют другие команды. Меня вдохновляют задачи на стыке фронтенда и DevOps, я хочу быть экспертом в производительности и безопасности веб-приложений».

Рассуждения в таком ключе помогут понять, кем вы хотите стать через несколько лет, что вас драйвит как инженера и какие навыки и компетенции следует для этого развить.

А ещё часто разум туманится хайпом вокруг определённой позиции — а потом оказывается, что эта роль вам совсем не подходит. Например, разработчик думает: «Быть тимлидом престижно, управлять командой — вершина мастерства». Вроде бы всё логично? На первый взгляд — да.

Однако на практике оказывается, что хороший руководитель занимается совсем не инженерными задачами: планирует работу, решает конфликты, становится психологом и коучем, налаживает отношения со стейкхолдерами. И получается, человек пошёл в профессию, чтобы писать код, а тут — бац! — психология, конфликты интересов и вот это всё.

Когда поймёте, куда хотите двигаться, настанет пора подумать, как достичь цели. Самое простое — наращивать знания: улучшать владение фреймворком, решать задачи с алгоритмами, осваивать архитектурные приёмы. Это базовый, но очень эффективный драйвер роста.

Знания и опыт решения задач помогают прокачивать продуктивность. Если вы быстрее других пишете код — чистый, тестируемый и расширяемый, — то будете развиваться, особенно в компаниях с классической проектной разработкой и каскадной моделью организации.

«Я работаю в аутсорсе. Мы внедрили процесс, в котором продакт-менеджеры сами выбирают себе исполнителей на проект. Если разработчик очень долго выполняет задачи, его перестают приглашать в команды — независимо от уровня подготовки. Скорость решения задач — одна из самых очевидных метрик эффективности работы специалиста».

Алексей Авдеев,
CTO в продуктовой лаборатории Mish

Высокая продуктивность и достойное качество кода помогают быстро расти, но только до определённого уровня. Что же делать дальше?

Решение — брать на себя сложные нетривиальные задачи, которые есть в любой компании. Например, создать дизайн-систему, оптимизировать сборку, проанализировать код проекта, выявить архитектурные недостатки и решать их. И тут возникают новые драйверы роста — инициатива и ответственность, которые идут рука об руку.

Когда бизнес растёт, процессы становятся сложнее, появляется больше вызовов как в менеджменте, так и в разработке. Чтобы со всем справляться, компании приходят к меритократии — власти достойных. На первые позиции выходят лидеры, которые умеют выявлять проблемы, предлагать решения и доводить их реализацию до конца.

Вот пример: продукт становится сложнее, и QA-инженеру требуется всё больше времени для ручного тестирования. Объём работы растёт на 20 часов с каждым спринтом — и это проблема. Задача — автоматизировать проверку критических для пользователей сценариев, чтобы снизить нагрузку на QA и сократить этап тестирования.

Разработчик приходит к руководителю и говорит: «Я прикинул, как автоматизировать тестирование: потребуется максимум 400 рабочих часов, зато можно будет сэкономить 80 часов за каждый релиз. Могу подхватить задачу — знаю, что ещё трое фронтендеров готовы помочь, закончим к концу квартала. Если ты согласен, сейчас подготовлю инфраструктуру и запуск тестов, а на следующей неделе девопсы добавят всё в настройки пайплайна сборки».

Как на такое отреагирует руководитель? Люди и ситуации бывают разные — но лично я бы держался за такого человека. Исходя из моей практики и опыта коллег, подобные кадры ценятся очень высоко, потому что двигают компанию вперёд.

Идеальный для работодателя вариант — если вы просто возьмёте и начнёте делать больше. Даже когда вас об этом не просит руководитель, даже если за это сначала не дают надбавок и премий. Со временем это обязательно принесёт результат — как в деньгах, так и в статусе, в знаниях.

В моей практике был случай, когда разработчик забрал на себя консультирование технического пиара как дополнительную нагрузку, когда его начальник не был уверен в таком решении. Но спустя некоторое время, увидев результат для всей компании, поменял своё мнение. Тексты стали качественнее, на них стали лучше реагировать потенциальные соискатели, а технические мероприятия начали привлекать сторонних инженеров, в которых была заинтересована непосредственно команда. Тогда тимлид стал оставлять отдельный слот в спринтах на коммуникационную работу. И организовал бонус за неё.

Зоя Австрийская,
руководитель технического пиара «ВКонтакте»

Чтобы добиться своего, нужно об этом рассказать. Кажется, это самый очевидный совет — что сложного в разговорах? Но всё не так просто.

Посмотрим на историю разработчика с другой стороны. Вот он осознал, что компании нужны автотесты, и героически взялся за дело: не спал ночами, оставил в стороне все другие задачи и придумал блестящее решение. После этого пошёл показывать свои наработки руководителю, и тут вдруг выяснилось, что проблемой уже занимаются ребята из другого отдела — а сейчас в команду планируют нанять побольше QA-инженеров.

В чём ошибка? Наш герой не обсудил потребность компании и решение проблемы, перед тем как приступить к её решению.

Это работает и с личным развитием. Не стоит терпеливо ждать, пока к вам придут и предложат повышение, задачи поинтереснее и зарплату побольше. Такое действительно может случиться, если коллектив маленький и ваши заслуги видны издалека — или, наоборот, вы работаете в большой корпорации, где настроена чёткая система грейдов и индивидуальных планов развития. Но между этими двумя полюсами находятся десятки тысяч компаний, где без разговоров совсем никуда.

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

Сергей Щербинин,
CEO консалтинговой компании

Разговаривать с руководством трудно, особенно о деньгах. Это неудобно, неловко, «стеснительно» и даже как будто неприлично. Но важно помнить: зарплатные переговоры — такая же часть рабочих коммуникаций, как беседы на дейли или брейнштормы. Главное — чтобы диалог был честным и конструктивным для обеих сторон.

Может быть, после беседы окажется, что ваши ожидания и возможности компании не совпадают. Такое случается — иногда легче просто разойтись и двигаться дальше. Но если вам не готовы больше платить прямо сейчас, это не значит, что пора хлопать дверью и бежать к конкурентам. Планирование зарплат, особенно в корпорациях, — процесс не быстрый.

«Если вы хотите вырасти в деньгах и навыках, заложите на это от полугода до года. У компании будет время для поиска ресурсов, а вы сможете составить план развития и подтянуть свои навыки, чтобы потом чувствовать себя комфортнее на желаемой позиции.

Подходить к беседе стоит с позиции взрослого человека. Если с ходу высказывать претензии или пытаться манипулировать работодателем, используя оффер в другой компании как козырь, то это, конечно, может сработать из-за страха вас потерять — но вряд ли сыграет на руку в долгосрочной перспективе».

Вера Маневич,
директор по персоналу «Одноклассников»

Вопросы для зарплатных переговоров:

  • Что я могу сделать, чтобы вырасти в деньгах? Какую пользу принести компании?
  • Какие у меня есть варианты для развития — в позиции, ответственности, задачах? Кем я могу стать через год? А через два?
  • Какие проблемы я могу помочь решить?
  • Какие сильные стороны у меня есть? А что мне стоит развить?

С продвижением по карьерной лестнице специалист начинает всё больше влиять на результаты компании. Ускорить процесс можно, если прокачивать бизнес-мышцу: разбираться, какие метрики зависят от кода, договариваться с коллегами из других команд, повышать культуру разработки. И даже думать, как снять часть ответственности с руководителя, если работы у него с избытком.

Отвечать за свой участок работы, безусловно, важно. Но разработка — лишь часть продукта. Поэтому подход «Опишите мне задачу, и я её сделаю, остальное неважно» не приведёт к успеху. Больше ценятся кадры, готовые работать с проблемами, а не сформулированными задачами.

Представьте картину: разработчики встречаются в баре и начинают обсуждать свои беды.

— Вот было бы здорово организовать A/B-тестирование, а не гадать на кофейной гуще.

— А у нас неправильно организован деплой.

— А у нас API падает на деве, невозможно терпеть!

Такие разговоры без действий непродуктивны: если вы знаете, как решить проблему, — решите её. Чем больше вы заинтересованы в бизнесе, тем больше бизнес заинтересован в вас.

«Взаимодействие с заказчиком на проектах часто происходит через менеджера. Если разработчик может сам включиться в диалог и помочь решить проблему заказчика, то мы экономим на менеджере и сокращаем коммуникацию. Такой специалист стоит дороже».

Алексей Авдеев,
CTO в продуктовой лаборатории Mish

В сообществе разработчиков есть немало неписаных правил, которые как будто разумеются сами собой. Конечно, надо писать архитектурно правильный код, покрывать всё автотестами, проводить рефакторинг, обновлять устаревшие интерфейсы — всё это действительно важно.

Но мало кто спрашивает, с какой целью это делается. Я часто вижу решения, пропитанные верой в их правильность. Но редко наблюдаю, чтобы кто-то критически подходил к эталонам.

Например, зачем вкладываться в архитектуру и автоматизацию тестов и деплоя на проекте, судьба которого — собрать заявки на митап? Компания проведёт мероприятие и забудет об этом сайте. Может, лучше возьмём jQuery, оживим на нём форму — и этого будет достаточно?

Важно понимать, когда нужно сделать достаточно хорошо, чтобы всё просто работало и бизнес достиг ожидаемых результатов. Это может на время ухудшить кодовую базу проекта. Зато не сдвинет сроки, пока вы закапываетесь в поисках идеала, который не даст ничего, кроме дополнительных расходов.

«Реальность такова, что иногда приходится срезать углы и искать не самые изящные, но рабочие решения. Это понимают не все: часто разработчики резко негативно относятся к „костылям“ и отсутствию времени на рефакторинг. Тем ценнее становятся специалисты, которые знают, как сократить время на разработку, а потом улучшить фичу после релиза. Им руководитель будет охотнее доверять самые важные и критичные проекты».

Григорий Богданов,
тимлид бэкенд-разработки Altenar

Конечно, это далеко не все составляющие, из которых складывается ценность разработчика. Самостоятельность, знание продукта, умение управлять рисками и быть командным игроком — всё это не менее важные качества, которые стоит прокачивать.

Но вернёмся к первому совету: всё же главное — понимать, чего вы сами хотите от работы. Может статься, что общепринятый карьерный трек — не для вас, и пока все стремятся стать тимлидами, вам комфортнее расти как специалисту. Чтобы в итоге стать экспертом, за которым выстраиваются очереди из рекрутеров.

Подумайте: устраивает ли вас позиция, на которой вы сейчас находитесь? Хотите ли вы расти дальше? Если да — есть ли для этого возможности в вашей компании?

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу