Почему разработчики упираются в потолок и как из него выйти

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

Самое неприятное — плато не видно изнутри. Никто не шлёт уведомление «вы перестали расти». Просто проходят год за годом на одном и том же уровне, пока не встречаешь коллегу, который сознательно не останавливался. Разница может оказаться огромной.

Почему «пиши больше кода» — плохой совет

На старте карьеры рост принудительный. Каждый новый проект подкидывает незнакомые проблемы, и деваться некуда — приходится учиться. Но когда у тебя сложился удобный стек и набор паттернов, которые «просто работают», мышцы начинают привыкать. Продуктивность есть, прогресса нет.

Часто советуют «собирай больше проектов». Проблема в том, что объём без сопротивления почти ничему не учит. Если каждый новый проект делается на том же стеке, с теми же архитектурными решениями, ты просто закрепляешь уже известное. Как в зале: если жать один и тот же вес годами, станешь мастером по жиму этого конкретного веса — и не более.

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

Чтение чужого кода полезнее, чем ещё один свой проект

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

Туториалы заточены под объяснение одной идеи, поэтому из них выброшено почти всё, что делает софт сложным: обработка ошибок, обратная совместимость, проблемы производительности, странные сценарии реальных пользователей. Чтение зрелого опенсорсного проекта — даже просто просмотр issue-трекера и пулл-реквестов — показывает не только, как код выглядит, но и почему его сделали именно таким.

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

Объяснение — быстрый способ выявить дыры

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

В программировании много «карго-культа»: мы копируем паттерны, потому что так принято, не до конца разбираясь в причинах. Например, многие знают, что useCallback нужен, чтобы избежать лишних ререндеров. А сможешь объяснить, когда он реально помогает, когда вредит и почему? Если нет — это как раз та дыра, которую стоит закрыть.

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

Как сдвинуться с плато

Резкая смена карьеры не нужна. Достаточно перестать выбирать задачи по принципу «что я умею» и начать выбирать по принципу «что чуть-чуть выходит за мою текущую границу». Задай себе вопрос: какой самый маленький шаг из зоны комфорта я могу сделать сегодня?

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

Это разница между десятью годами опыта и одним годом, повторённым десять раз.