Громкое имя ещё не означает рост

Многие разработчики мечтают попасть в крупную IT-компанию. Яндекс, Сбер, Google — звучит как следующий очевидный шаг в карьере. Большие проекты, известное имя в резюме, сильные команды. Кажется, что там ты уж точно вырастешь как специалист.

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

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

Когда тебе остаётся один процент

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

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

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

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

Чему меня научил первый год работы

У меня начало карьеры было устроено почти противоположным образом. Меня без опыта бросили в проект, который нужно было писать с нуля. Приходилось общаться с заказчиками, оценивать сроки, разбираться с требованиями, продумывать архитектуру, писать код и доводить всё до рабочего состояния. По сути, сразу проходить полный цикл разработки.

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

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

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

Что я видел на собеседованиях

Это заметно и при найме. Я собеседовал разработчиков из Сбера и других крупных компаний. Когда разговор касался программирования и той работы, которую они непосредственно выполняли, вопросов у меня часто не возникало. Люди знали свой участок.

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

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

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

Большая компания двигается медленно

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

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

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

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

Кому вообще нужен разработчик, который умеет всё это

Здесь есть ещё один вопрос: нужен ли каждой компании специалист, который умеет самостоятельно пройти весь цикл? Скорее всего, нет. Я не говорю, что разработчик обязан быть fullstack, чинить отображение сайта, настраивать деплой и проводить полную аналитику любого нового сервиса. Такие задачи могут вообще не входить в его работу. Речь о самостоятельности в основной разработке: разобраться в задаче, принять технические решения, договориться с людьми и довести результат до конца.

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

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

На что смотреть вместо вывески

Если цель — вырасти как разработчик, я бы смотрел прежде всего на то, что тебе реально дадут делать. Будешь ли ты участвовать в обсуждении требований? Сможешь ли предлагать архитектурные решения? Увидишь ли, что происходит с твоим кодом после ревью? Придётся ли самому разбираться с задачами, у которых ещё нет готового решения?

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

Если для тебя сейчас главное — расти как разработчик, я бы предостерёг от похода в крупную компанию ради её имени. Не стоит считать Яндекс, Сбер или Google автоматическим билетом в прекрасную карьеру. Размер и известность работодателя ничего не говорят о ширине твоей будущей работы. В компании поменьше ты можешь получить гораздо больше самостоятельности, полезного опыта и причин развиваться.

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