Я последнее время всё чаще думаю, что засиделся. Не в формате «всё плохо, спасите», а просто… долго в одном месте. Работаешь, делаешь задачи, код живёт, что-то двигается — но ощущение движения куда-то пропадает.

В какой-то момент в голове появляется мысль, которую очень не хочется думать: а может, пора снова выходить на рынок.

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

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

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

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

Собеседования при этом каждый раз разные. Где-то тебя гоняют по топ-100-вопросам-по-фронтенду. Где-то просто разговаривают, как будто вы уже работаете вместе. Где-то мешанина из задач, теории и «а как бы ты сделал». Угадать формат невозможно, и это всегда немного нервирует.

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

И в какой-то момент ловишь себя на том, что дело даже не в собеседованиях. А в том, что тебе просто неприятно снова находиться в позиции человека, которого оценивают.

Очень не хочется здесь сейчас быть, но надо.

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

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

Рано или поздно приходит реальность. Появляются срочные задачи. Потом ещё одни. Потом «давай пока так, потом переделаем». Меняются приоритеты, команда, требования, ограничения. Архитектура не ломается в один момент, но начинает деформироваться — медленно и почти незаметно.

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

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

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

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

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

// не идеально, зато читаемо и решает задачу
fetchUserProfile(userId).then(setUser)

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

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

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

Она почти никогда не выглядит так красиво, как на схемах в статьях. Зато она переживает сроки, изменения требований и реальных пользователей. А это, как показала практика, куда важнее аккуратных стрелочек на диаграмме.

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

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

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

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

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

Проверка результата всё ещё остаётся на человеке. Выбор инструментов и стека — тоже. Ответственность никуда не делась. ИИ не знает, что у вас легаси, где у вас деньги и где бизнесу будет больно. Он не знает, что этот код придётся поддерживать через год. ИИ полезен ровно до тех пор, пока ты способен проверить его работу.

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

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

Прогресс не спрашивает, комфортно тебе или нет. Он просто едет дальше. И выбор сейчас довольно простой: либо ты учишься работать с ИИ как с инструментом, либо со временем тебя заменят те, кто это сделал.

P.S. Буду время от времени писать в таком формате — без суеты, эмодзи-приколов и лишнего форматирования. Интересно, как вам заходит.

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

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

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

Самая подлая часть в том, что это бьёт по уверенности. Хочется линейного роста: вчера не умел, а сегодня умею. А здесь наоборот: чем дальше идёшь, тем больше вопросов, тем меньше ощущения контроля. И мозг делает самый простой вывод — «я, видимо, стал хуже». Это очень удобная, но абсолютно ложная интерпретация происходящего.

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

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