На Habr вышел материал с прямым и немного вызывающим заголовком: «В борьбе обретешь ты право свое: стать синьором». Для тех, кто пытается стать синьором, это важный сигнал: карьерный рост в разработке давно перестал быть историей только про «знаю больше фреймворков» и «закрываю больше задач».
Как пишет Habr / Карьера, вопрос поставлен предельно в лоб: что отличает синьора от не-синьора, если базовые ответы всем давно известны. Знания, опыт, хард-скилы, софт-скилы, умение думать о бизнесе и продукте, все это уже стало обязательной частью разговора. Но сам материал подталкивает к более неприятной, а потому полезной мысли: возможно, различие упирается не только в набор компетенций, а в то, как человек распоряжается ими в реальной работе.
Это важный разворот для русскоязычной IT-аудитории. В локальном рынке слово «синьор» по-прежнему часто используют как удобную наклейку: в вакансиях, на собеседованиях, в пересмотрах зарплат и в бесконечных спорах о грейдах. Проблема в том, что у такой наклейки нет одного общепринятого стандарта. Для одной компании синьор это человек, который без присмотра тащит сложные фичи. Для другой это инженер, способный разрулить архитектурный конфликт, договориться с продуктом и не сжечь команду в процессе. Для третьей это почти тимлид без формального титула. На этом фоне попытка снова разобрать, что значит стать синьором, выглядит не теоретическим упражнением, а разбором рабочего инструмента, который у индустрии давно тупится о реальность.
Самый полезный тезис здесь в том, что синьорность плохо измеряется объемом накопленных знаний в отрыве от контекста. Можно отлично знать стек, уверенно писать код, быстро чинить инциденты и все равно оставаться специалистом, который решает задачу в границах собственного редактора. Синьор, если убрать пафос, обычно отличается не магическим IQ и не особой породой инженерного благородства, а способностью видеть систему целиком. Он понимает, зачем делается функция, где у нее бизнес-ограничения, кто будет поддерживать решение через полгода и почему «идеально» иногда дороже, чем «достаточно хорошо к релизу». Это не отменяет глубокой технической базы. Это просто означает, что зрелость инженера проявляется не в знании всего на свете, а в качестве инженерных решений под давлением сроков, неопределенности и чужих интересов.
Отсюда вытекает еще одна неприятная мысль, которую многие в индустрии предпочитают откладывать до очередного performance review. Синьорность почти всегда связана с ответственностью, которую нельзя красиво перечислить в списке технологий. Речь про способность принимать неполную информацию, объяснять компромиссы, страховать слабые места в проекте и замечать риски до того, как они превратятся в аврал для всей команды. Разработчик уровня middle часто оценивается по тому, насколько качественно он выполняет поставленную задачу. Синьора обычно начинают оценивать по тому, какие проблемы он не дал случиться. Это менее зрелищно, хуже смотрится в демо и почти не помещается в строку резюме. Зато именно здесь проходит граница между «сильный исполнитель» и «человек, на которого реально опирается команда».
Для бизнеса и продуктовых команд такой разговор тоже важен, потому что он бьет по популярной иллюзии: будто синьор это просто дорогой разработчик с большим стажем. Если компания сама не понимает, за что именно платит на уровне senior, она начинает путать роли. В результате от инженера ждут одновременно архитектуру, менторство, delivery, переговоры с заказчиком, спокойствие в кризисе и еще чтобы он писал код быстрее всех. Потом удивляются, что рынок полон людей с громкими тайтлами и выгоревшими лицами. Материал Habr ценен хотя бы тем, что возвращает дискуссию из плоскости статусов в плоскость функций: что именно человек умеет делать такого, что меняет результат команды или продукта.
Для самих разработчиков вывод тоже довольно практичный. Если цель звучит как «хочу стать синьором», то маршрут вряд ли проходит только через очередной курс, новый язык или коллекцию решенных задач на алгоритмы. Это полезные вещи, но они не отвечают на главный вопрос: умеет ли специалист расширять рамку, в которой мыслит. Видит ли он стоимость решения. Понимает ли, где технический долг действительно опасен, а где вокруг него просто разыгрывают ритуальный танец. Может ли спорить по делу, а не по самооценке. Способен ли поднимать качество работы команды, а не только собственный KPI. Иными словами, путь к синьорству становится менее похожим на прокачку персонажа и больше на болезненный апгрейд способа принимать решения.
На этом месте спор о том, кто достоин титула senior, становится менее интересным, чем другой вопрос: сколько компаний вообще умеют распознавать и выращивать такую зрелость, а не просто покупать ее по рынку. Если ответ не слишком обнадеживает, то борьба за право стать синьором действительно продолжается, только идет она уже не за звание, а за способность влиять на продукт, команду и результат без лишнего шума вокруг таблички в профиле.