Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>5 апр 2024</li>

3 <li>0</li>

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

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

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

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

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

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

10 Руководитель программного комитета FrontendConf, автор телеграм-канала "<a>Уставший техдир</a>", спикер отраслевых конференций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43 <ul><li>Что я могу сделать, чтобы вырасти в деньгах? Какую пользу принести компании?</li>

44 <li>Какие у меня есть варианты для развития - в позиции, ответственности, задачах? Кем я могу стать через год? А через два?</li>

45 <li>Какие проблемы я могу помочь решить?</li>

46 <li>Какие сильные стороны у меня есть? А что мне стоит развить?</li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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