Как стать Senior-разработчиком: 4 шага на пути к успеху
Если вы следите за текущими тенденциями в мире найма/вакансий, то определенно заметили, что куда-то подевались вакансии Middle и Junior-разработчиков, и у этого есть несколько причин.
Первая: рынок просел, и общее количество вакансий в IT-индустрии сократилось. В результате Middle-позиции теперь можно закрывать Senior-разработчиками. Это уже случалось в нашей истории, но за любым спадом следует подъем.
Вторая — AI-агенты. Senior-разработчики получили «рычаг». Теперь задачи, которые ранее поручали Junior и Middle-разработчикам, можно поручить AI Agent. При этом для Senior мало что меняется, поскольку подробное review делать нужно в обоих случаях.
Можно сказать, рынок оказался в «клинче». Сейчас нет времени думать, что будет дальше, поскольку нужно решать текущие вопросы, а когда начнется подъем, нужного количества разработчиков может и не оказаться, поскольку они ушли в «плотники».
Однако сомневаюсь, что вас сильно волнуют проблемы рынка, разве что на кухне за чашкой кофе. А вот что делать конкретно сейчас и конкретно вам, чтобы стать Senior, разбираемся в статье…
Дисклеймер: «Разработчики больше не нужны»
Несмотря на то что главы Anthropic & OpenAI провозгласили закат эпохи программирования, сами эти компании на данный момент являются основными работодателями в Palo Alto aka Silicon Valley. Нанимают они, правда, в основном Senior Developers, поэтому читаем далее.
Туманный путь к senior
Переход от junior к middle для большинства разработчиков обычно не вызывает больших проблем. Когда вы junior, основная задача, которую вы перед собой ставите, — это заставить код просто работать. При этом зачастую любыми возможными усилиями.
Попутно вы узнаете, какие бывают окружения, как выглядит процесс разработки в целом и как в конечном счете код попадает на production.
Занимает это обычно 1–2 года (которых у нас, кажется, нет, но об этом чуть позже).
А вот что делать, если вы уже middle и хотите стать senior? Этот переход гораздо менее очевиден, и связано это с тем, что в каждой компании свое представление о том, кто такой senior. Однако не стоит отчаиваться.
Большинство разработчиков считают, что путь к senior выглядит как-то так:
-
вы с удвоенной силой углубляетесь в свой текущий язык программирования, чтобы стать «экспертом»
-
вы добавляете новые инструменты в свой арсенал — новый язык программирования или фреймворк (Rust?)
-
вы зацикливаетесь на качестве кода, его корректной работе
-
вы недоумеваете, почему вас до сих пор не повысили
Возможно, вы, как и я, думали так же, прошли этот путь, поняли, что этого недостаточно, внесли коррективы и все же стали senior.
У тех, кто сейчас является junior или middle, к сожалению, нет столько времени «на раскачку», сколько было у нас. Поэтому приступим.
Шаг 0: Быть хорошим в кодинге
Давайте разберёмся с этим, прежде чем погружаться в менее очевидные вещи.
Нельзя просто быть приятным в общении, но ужасным кодером и при этом рассчитывать на повышение (хотя я видел, как такое случалось).
К сожалению, как бы мы того ни хотели, иметь навык написания кода по-прежнему необходимо. Тому есть несколько причин.
Первая: AI может, но не все. По-прежнему мы сталкиваемся с задачами, не всегда сложными для человека, в которых AI буквально начинает спотыкаться на ровном месте, не может найти очевидное решение. Если вы не сможете подсказать Agent-у в этот момент, то это сильно скажется на вашей продуктивности в целом.
Вторая: код нужно читать, ревьюить, анализировать, а этот навык сложно развить, не умея его писать. Раньше говорили: «он все понимает, но ничего не говорит», так вот, на практике это кажется недостижимым.
А читать код все равно придется: чтобы гарантировать, что Agent не порождает технического долга, а он по-прежнему актуален; чтобы гарантировать корректную работу алгоритмов, убедиться в поведении которых можно только анализом кода.
Лучший способ научиться лучше писать код, как и раньше:
-
написать много плохого кода
-
читать хороший код и красть то, что имеет смысл (нет, не копипастом, а «воруя» паттерны и стиль более опытных разработчиков)
-
читать книги о распространённых паттернах проектирования и применять их в работе
-
изучать паттерны для фреймворка, который вы используете. Например, если вы используете Spring (а вы, конечно же, используете), то изучите популярные подходы к композиции компонентов, получению данных и построению крупных приложений
Однако это по-прежнему долго, поэтому:
-
попросите AI Agent сделать review вашего кода
-
попросите AI Agent решить задачу и сделайте сами review кода, заставив AI Agent обсудить с вами ваши же комментарии
-
подключите к вашему Agent-у Skills от экспертов в индустрии (Spring Agent Toolkit для Spring/Spring Boot, ActionBook Rust Skills для Rust)
-
посмотрите, как написаны Skills от экспертов в индустрии, и напишите свои, перенимая подходы и методы
Помните: как только вы покинули позицию junior, хорошее (не идеальное) качество кода от вас будут ждать по умолчанию, и совершенно неважно, как вы этот код получили: писали сами или за вас код писал Agent.
Поэтому умение развивать своего Agent — это такой же необходимый навык, как умение развивать себя как профессионала.
Шаг 1: Перестаньте думать только о себе
От разработчиков достаточно часто можно слышать: «Мне правда нравится работать в одиночку. Я хочу писать код, работать из дома и не иметь дела с людьми». Увы, но…
Создание ПО — это командный спорт, и управление изменениями от множества разработчиков — задача непростая.
Один из явных признаков здоровой кодовой базы — целостность:
-
множество авторов пишут код в похожем стиле
-
код в продукте следует некоторой архитектурной концепции
-
общий код выносится в компоненты и переиспользуется
-
доменная модель распределена по компонентам, пакетам, сервисам
И наоборот, кодовая база без паттернов — огромная проблема. Да, она работает, но что произойдёт, когда разработчик захочет разработать новую фичу? Какой подход/паттерн использовать и почему? Представьте работу в кодовой базе, где нет принятого подхода к организации компонентов и распределению ответственности, нет доменного фреймворка. По сути, каждый разработчик заново изобретает велосипед.
Будучи junior-разработчиком, вы отвечаете за небольшую часть кодовой базы. Вы просто хотите, чтобы ваш код работал. Вы, конечно, уже слышали о разных принципах и подходах в разработке, возможных архитектурах, но большинство из этого — исключительно теоретические знания, и непонятно, как их точно применять на практике.
На уровне middle ваш кругозор расширяется, и вы, возможно, даже помогаете junior’ам с их задачами. Ваш код не только работает — вы ещё и думаете, как он вписывается в общую картину.
Senior’ы создают паттерны, которые остальные используют, чтобы нарастить темпы разработки и при этом сохранить структуру приложения в поддерживаемом состоянии. Они смотрят за «горизонт»; иногда, правда, проблемы, которые они видят, являются миражами, но если не смотреть, то можно пропустить смерч.
Кажется, чтобы приобрести такой навык, нужно написать огромное количество кода и еще больше отревьюить. И раньше это был практически единственный способ. Однако сейчас у нас есть AI Agent — рычаг, который самое время использовать.
Попросите Agent показать вам ваши доменные модели в терминах DDD (есть в наборе Skill), далее сделайте review и убедитесь, что нет связей между aggregate root -> aggregate member. Если обнаружите такое, то либо сразу исправьте, либо заведите задачу в техдолг.
Попросите Agent проанализировать паттерны использования JPA и подходы (используйте JPA Skill), зафиксируйте возможные проблемы, заведите задачи или сразу же их исправьте.
Попросите Agent создать правила ArchUnit или просто проанализировать проект на предмет расхождения с целевой архитектурой.
Помните: senior — это человек, отвечающий за проект в целом, улучшающий опыт разработки всей команды. Ему не все равно, он понимает, что такие улучшения могут принести большие дивиденды.
Если бы ваша кодовая база была книгой, ощущалась бы она так, будто написана одним из классиков? Стремитесь приблизиться к этому идеалу.
Шаг 2: Бегите навстречу пожарам
Есть универсальное ожидание от senior-разработчиков: они готовы взять на себя ответственность за решение проблемы, в том числе, в критический момент на продакшене.
Когда в вашей команде случается критический инцидент — например, простой системы или критический баг, который всплыл во время демонстрации системы заказчику или будущему инвестору, а может, случилось каскадное падение в «черную пятницу», — я хочу, чтобы вы подняли руку и взялись это расследовать.
Не говорите «Я это починю». Говорите «Я это расследую».
Информируйте команду о своём прогрессе каждый час простым языком и будьте честны.
Если вы действительно всё почините — вы герой. Если вам придётся обратиться за помощью, вы всё равно получите «эффект ореола» от участия в исправлении. Помните: это командный спорт.
Что бы вы ни делали, инциденты будут случаться. Участвуя в расследовании раз за разом и каждый раз рефлексируя над тем, как не допустить такой ситуации вновь, не забывайте задавать себе вопрос: а что можно сделать для ускорения обнаружения проблемы и ее решения?
Возможно, что-то нужно изменить в метриках. Удалось ли быстро получить доступ к log-сообщениям с production? Использовали ли вы Agent для их анализа? Имел ли сам Agent доступ к информации с production-серверов? Помог бы вам тулинг, дающий доступ к информации о Spring-приложении изнутри (посмотрите axelix).
Если вы уже использовали AI Agent, посмотрите историю чата: пришлось ли что-то объяснять особенно подробно или что-то, что для вас являлось очевидным? Если да, есть ли способ дать Agent доступ к этой информации, напишите Skill, поделитесь им с командой.
Шаг 3: Пишите меньше кода и пишите больше
Помните: если вы senior, ваша задача не только писать код, ваша задача — писать:
-
документацию
-
сообщения аналитику, проджект-менеджеру, владельцу продукта о том, почему та или иная фича займет больше времени, чем планировалось (он будет в ярости)
-
тексты для тикетов с новыми фичами/багами, включая требования
-
комментарии в коде, объясняющие бизнес-контекст какого-то фрагмента (например, вы конвертируете даты в странный формат для пользователей определённой страны)
-
описания pull request’ов, чтобы коллеги знали, как протестировать сложный сценарий
Как senior-разработчик, вы хотите масштабировать свои знания. Единственный лучший способ сделать это — записывать то, что вы знаете, и делиться этим с другими.
Если вы создаёте фичу на основе какой-то новой технологии — задокументируйте её, чтобы остальные знали, как с ней работать.
Пишите статьи, чтобы упорядочить мысли и навести ясность в той каше, что творится у вас в голове. Умение писать ясно и доносить технические концепции доступным языком сотворит чудеса для вашей карьеры.
Ваша организация больше, чем ваша команда ботаников. Большинство разработчиков попросту не умеют раскладывать технические вещи на термины, понятные обычным людям. Поверьте, это суперспособность, и она непростая.
Единственный способ стать лучше в написании статей — начать писать. Напишите ключевые мысли будущего текста — это скелет, добавьте немного «мяса» (не перестарайтесь), попросите вашего AI Agent проверить орфографию, пунктуацию, добавить ссылки. Если вам не нравится некоторая формулировка или стиль изложения, попросите несколько вариантов у AI Agent, но не увлекайтесь: не получилось после 3 попыток — выберите приемлемый вариант и продолжайте. Если что, сообщество вам подскажет, где вы оступились.
Прочитайте книгу вроде «Пиши, сокращай 2025: Как создавать сильный текст» Максима Ильяхова и Людмилы Сарычевой, чтобы узнать, как профессиональные писатели пишут хорошо.
Возможно, мне и самому стоит её перечитать.
И последнее, что вам не понравится
Вы можете делать всё это — и всё равно не получить повышение.
Если в бюджете нет денег на повышение зарплаты, то вы можете исправить сложнейшие баги, потушить самые яркие пожары, сделать фичу досрочно и наставлять junior’ов в вашей команде — и всё равно не получить блестящий титул senior.
Делайте всё это всё равно. Успех будет неизбежен.
И помните: в эпоху AI Agent при правильном использовании это мощнейший рычаг для вас и для вашей карьеры. Применяйте его правильно, и «да пребудет с вами сила».
А теперь идите и получите этот титул.
Пробовать Spring Agent Toolkit можно, установив его по ссылке. Присылайте обратную связь и рассказывайте о своём опыте использования в социальных сетях. А больше про разработку на Java с AI-агентами читайте в нашем ТГК-канале.

Источник: habr.com

Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.