Задача, которая раньше занимала три дня, теперь закрывается за один — но это ещё не обязательно рост. В заметке на Habr / Карьера автор предлагает измерять развитие разработчика не количеством тикетов и скоростью их закрытия, а новыми зонами ответственности, пониманием системы и способностью проверять собственные решения.
Материал адресован прежде всего джунам и мидлам, хотя описанные привычки пригодятся и более опытным инженерам. Его отправная точка проста: в команде легко стать человеком, который делает прежнюю работу быстрее, получает больше однотипных задач и со временем упирается в потолок. Для роста полезнее регулярно сравнивать себя не с коллегами, а с собой несколько месяцев назад: какой участок проекта теперь понятен, какую проблему можно разобрать без подсказки, почему архитектурное решение устроено именно так и что сломается при его замене.
Автор не предлагает лечить карьерную тревогу героизмом по вечерам. Вместо огромной и рискованной задачи можно взять небольшой, но незнакомый кусок работы, заранее договорившись о помощи на случай тупика. Ключевое условие — время на разбор. Если новая задача просто добавлена поверх обычного потока, она быстро превращается в переработку, а не в обучение. Впрочем, универсального рецепта нет: кому-то комфортно годами заниматься рутиной, и это тоже нормальная профессиональная траектория, если она выбрана осознанно.
Отдельная часть заметки посвящена навыку, который редко попадает в карьерные планы, но ежедневно отличает самостоятельного инженера от исполнителя: чтению чужого кода и расследованию сбоев. Необязательно сразу изучать все репозитории компании. Достаточно проследить один пользовательский сценарий: от входящего запроса через сервисы и хранилища данных до потребителя результата. При разборе медленного запроса автор советует не гадать по исходникам, а идти к данным — времени выполнения, трассировкам, логам и метрикам. Задержка может оказаться не в очевидном месте: в запросе к базе, ожидании внешнего сервиса или повторах, о которых разработчик не знал.
Для российских команд это особенно прикладной совет. Во многих продуктах документация отстаёт от кода, а знания о том, где смотреть логи и как устроен конкретный бизнес-процесс, распределены между несколькими людьми. Поэтому полезно выяснить доступ к инструментам наблюдаемости до инцидента, а не в момент, когда сервис уже деградировал и в общий чат приходят сообщения от бизнеса. Соседние команды тоже могут быть источником практики: сравнение похожих проектов помогает увидеть не «правильный» шаблон, а цену разных решений — сложности поддержки, риски ошибок и накопленные исторические ограничения.
Ещё один акцент — качество вопросов. Если постановка состоит из фразы «сделать по аналогии», лучше сразу уточнить ожидаемый результат, пользователей и пограничные случаи. Когда инженер застрял, коллеге легче помочь, если он видит контекст: что уже проверено, какую гипотезу пытались подтвердить и в какой точке возникло непонимание. Тот же принцип работает на код-ревью. Молча исправить строку быстрее, но вопрос «почему так?» превращает замечание в часть опыта. Особенно важно отличать реальные технические причины от договорённостей команды и от объяснения «так исторически сложилось»: это три разных разговора и три разных способа улучшить процесс.
Заметка не обходит стороной ИИ-инструменты. Они способны быстро выдать рабочий фрагмент кода, но сами по себе не создают компетенцию. Если разработчик не может объяснить, что делает предложенное решение и при каких условиях оно даст сбой, следующая похожая задача останется такой же новой. Автор предлагает давать модели контекст: цель изменения, ограничения проекта, запрещённые действия и способ проверки. Полезно сначала попросить изучить нужный участок репозитория и предложить план, а затем проверить его документацией, тестами и граничными случаями. Сохранённые инструкции и повторяемые сценарии экономят время, однако сначала нужно понять процесс вручную — иначе команда лишь автоматизирует одну и ту же ошибку.
В результате развитие разработчика выглядит не как набор курсов между релизами, а как дисциплина внутри обычной работы: брать чуть более незнакомые задачи, видеть систему целиком, вовремя спрашивать и проверять автоматизацию. На рынке, где ИИ снижает стоимость шаблонного кода, ценность инженера всё сильнее будет определяться не скоростью генерации очередного решения, а способностью понять последствия этого решения для продукта, команды и бизнеса.
