Стоит ли переходить в АйТи и чего опасаться?

Здравствуйте! Хотелось бы поинтересоваться, насколько реально, а главное — насколько правильно в 34 года начинать изучать программирование с целью дальнейшей смены профессии?

Честный ответ: шансы низкие, но они есть. Дело не в возрасте, а в том, что на рынке куча проблем (сокращения, кризис доверия, кризис компетенции и т.д.), сейчас даже с опытом сложно. Попытайтесь трезво оценить свою ситуацию, нужно быть готовым, что вложенные усилия и время не окупятся, если готовы рискнуть, то учитывайте следующее:

• Вся информация есть в публичном доступе бесплатно
Сегодня информация ничего не стоит. Всё, что требуется на старте, можно найти абсолютно бесплатно в открытом доступе. Никаких тайн и секретных секретов нет. Лучшее, что можно взять за деньги, — это структурированная информация (бывает проще, когда кто-то за вас составил план и ведёт по нему). Альтернатива — использовать ИИ для изучения теории.

• Практика важнее теории
Сегодня в LLM можно найти любую информацию: она поможет составить план, проверит, насколько правильно вы всё усвоили, даже поможет сделать свой проект. Но проблема в том, что это не означает, что вы получите опыт, сравнимый с коммерческим. Опыт — это объединение практики и знаний. Его на старте можно получить, общаясь с сильными спецами, или найдя первую работу.

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

• Нетворкинг + рефералки + рассылка резюме
Чтобы повысить шансы на успех, нужно смотреть все возможные варианты. Откликов для новичков очень мало, поэтому тут надо трезво смотреть на вещи и пытаться работать не только на рассылку резюме, а в процессе обучения смотреть по сторонам.

• Менторская помощь
Многие надеются, что с помощью менторов будет намного проще. Тут надо помнить о том, что я писал в самом начале. Главное правило — оплата по итогу трудоустройства и прохождения испыталки. Если ментор действительно имеет опыт и выход на компании, то ему нет смысла брать с вас никаких «базовых» тарифов. Только после прохождения испыталки. Иначе я бы не рисковал.

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

Подксажите, а насколько вообще стоит углубляться в изучение TPL и прочего (мне на C#) в текущих реалиях, если я это знаю в целом на среднем уровне (без супер глубины). Я вот просто думал - подтянуть ли мне там знания или сейчас LLM всё порешает и лучше углубиться в архитектуру (монолиты, сервисная, DDD и прочее)? Что практичней?

Всё больше вопросов о том, стоит ли изучать ЯП и низкоуровневые вещи.

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

К сожалению, из-за действий наших оппонентов многие люди по-прежнему тратят кучу времени и сил, изучая материалы, которые были актуальны 2-3 года назад, зубрят вопросы, которые не имеют смысла в новых условиях. Людей пытаются убедить, что рынок не меняется, что на самом деле он сломан и скоро починится.

С моей позиции рынок структурно изменился, чтобы оставаться востребованным, нужно так же меняться и идти по тем векторам развития, которые диктует новая реальность:

- использование ИИ для написания кода;
- использование оркестрируемых агентных систем;
- документирование архитектуры проекта (для генерации с помощью ИИ);
- учиться делать грамотную грануляцию и проводить границы;
- знать архитектурные фреймворки.

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

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

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

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

- Не нужно учить новое
- Не нужно признавать, что старые навыки обесценились
- Виноватые всегда внешние

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

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

У себя в сообществе мы нашли вектор развития, который помогает решать текущие проблемы - создали сильную команду специалистов, регулярно встречаемся и обмениваемся опытом, рассматриваем вопросы из практики (то, с чем сталкиваемся каждый день), анализируем чужие достижения. На мой взгляд, это конструктивно и полезно.

Буквально вчера была встреча, где обсуждали проблему запуска е2е автотестов с помощью ИИ, в частности почему нельзя просто скопировать тест и попросить LLM делать то же самое.

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

Какую книгу почитать чтобы научиться проводить границы и разделять ответственность?

Одна из причин почему я сделал курсы по архитектуре - разрозненность информации. Назвать одну книгу сложно, мне кажется проще этот материал взять из курса "Практическая монолитная архитектура".

- Лекция. Проведение границы и разделение обязанностей

Дополнительно в курсе есть материалы по сбору требований, документированию, которые желательно рассмотреть вместе с темой границ.

Отмечу, что если интересует только теория, то можно взять Подписку №1 за 1200 рублей. Вам будут доступны записи всех лекций, их можно слушать как аудиокнигу в метро или автомобиле.

Upd. Чтобы избежать лишних списаний подписку легко отключить сразу после оплаты. Заходите в раздел Платежи удаляете подписку. После истечения текущего периода никаких списаний не будет.

Еще раз убедился, что без практики не будет понимания. Наши оппоненты пытаются выступать не на своем поле, на этот раз пытаясь убедить, что понимают в архитектуре:

сделай лучше пост про халявные апи нейронок), в архитектуре только 1 тезис - нафигачить доп абстракций

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

Случай 1. Бывают ситуации, когда "целое" обладает большим количеством свойств, чем каждая из частей (это называется эмерджентность), в таких ситуациях удобно представить "целое" как абстракцию и использовать свойства вне контекста реализации.

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

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

Таким образом, идет "выделение обязанностей" -> "выделение границ", а далее решается вопрос, каким образом реализовать границы: либо закрытый контур (без абстракций), либо выделение интерфейсов (это и есть абстракция), либо использование механизмов унификации (это когда ранее использованные интерфейсы используются повторно, т.е. без создания доп. абстракций), либо прямая реализация (если нет сложности, которую нужно инкапсулировать), и т.д.

Ни о каком "фигачить доп. абстракции" речи не идет. Существует куча механик, которые нужно понимать и использовать грамотно.

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

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

Отсюда я сделал два вывода:

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

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

Кажется оппоненты обвинили меня в генерации слопа.

Курс по микросервисам стартует 20.04.2026.

Продолжаю создание курсов по теме архитектуры. Ранее в сообществе были созданы коллекции материалов по сервисам и монолитам, и вот настала очередь микросервисов.

О курсе:
❗️ приоритет на проектирование, документирование и анализ (будем разбираться, как проводить границы, формировать требования, распределять обязанности и т.д.)

❗️ изучать можно индивидуально или общаясь в группе

❗️ еженедельные семинары с разбором проблем и консультациями (только для Подписки №3)

❗️ часть созвонов предполагает интерактивный формат круглого стола (например, общая Event Storming сессия)

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

Можно просто смотреть лекции (для этого нужна Подписка №1), можно дополнительно смотреть мастер-классы (подписка №2), а для обратной связи приходить на семинары (подписка №3).

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

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

Количество участников на семинарах ограничено, сейчас есть 4 места, которые доступны, если вы приобрели подписку №3.

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

Мы реализуем идею поэтапного развития (движения к цели короткими шагами), постоянно шлифуем свои навыки, собираем актуальную информацию, которую можно применять на практике, обмениваемся опытом и т.д., а подписка определяет уровень доступа.

Например, после курса по микросервисам планирую курс по архитектуре агентных систем, дополнительные созвоны, публикацию материалов в ИИ-лаборатории и т.д.

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

Ну что, господа соеры, посрамили нас! У Антона Назарова вышли видео по технической тематике (это, кстати, вторая его попытка делать технический контент).

Благодаря роликам Антона, мы теперь знаем, что нагрузка считается городами (один город - монолит, 10 городов - микросервисы), а реалтайм секундами (5 секунд - реалтайм, а 30 секунд уже нет).

Теперь осталось вспомнить нестареющую классику "UDP - это легаси х***" и уйти плакать в подушку осознавая, что твой мир никогда не будет прежним.

И только одна мысль не дает покоя, а вот если у нас 5 секунд - это реалтайм, то получается, если у меня сетевая игра обновляет сцену раз в 5 секунд, то это не баг, а фича?

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

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

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

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

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

Что остается в таком случае? ВУЗы с хорошей репутацией? Таких учебных заведений всегда было единицы, но сегодня их становится все меньше.

Периодически слышу о новых образовательных реформах (например: отказ от Болонской системы, только вроде все отладили и нате, новый курс) и задаюсь вопросом: "А где сегодня качественное образование, которому можно доверять?"

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

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

Что думаете? Как сегодня фильтровать и находить полезную информацию?

Сегодня впервые за многие годы стоял в утренней пробке (нужно было по делам мотануться) и понял, что за 12 лет удаленки совершенно забыл, как раньше каждый день ездил на работу. Хочу поделиться некоторыми своими мыслями о том, как я трансформировался от офисного сотрудника до соера.

Какие результаты получены за 12 лет в хронологическом порядке:

- ушел на удаленку;
- начал продавать свою экспертизу, а не часы;
- создал личный бренд;
- занялся консультированием;
- завел YouTube-канал;
- развил публичный бренд;
- создал свое сообщество;
- разработал свой продукт (курсы, платформа, встречи, обмен опытом).

Как пришел к таким результатам

Я стараюсь добиваться целей через выстраивание стратегии. Невозможно построить детальный план на 12 лет, но можно наметить вектор развития. Для меня основными являются всего два принципа, которым легко следовать:

❗️ развитие технических навыков для решения практических задач;

❗️ развитие нетворкинга для получения предложений о работе или сотрудничестве.

Я никогда не думал: "Сейчас познакомлюсь с Иваном Иванычем, и он предложит мне заняться консультированием" - это какой-то тупиковый путь.

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

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

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

Коррекция на время.

Трудно не заметить, что рынок сегодня сильно поменялся. Знания устаревают быстрее (в нулевые нужно было корректировать стек в течение 4–5 лет, сегодня нужно успевать изучать новое в течение 2 лет), компетенции смещаются в область ИИ, архитектура ПО становится такой же важной частью, как и качественный код, и т.д.

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

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

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

А что делать конкретно?

После такого длинного поста о том, что важно не ограничивать себя стенами офиса и искать новые возможности для обмена опытом, вполне логично сказать "не, ну все это понятно, а что делать конкретно".

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

У нас стартует курс "Микросервисная архитектура", мы будем несколько недель встречаться на семинарах (в рамках "Подписки №3"), обсуждать не только курс, но реальные ситуации из рабочих будней наших участников и обмениваться опытом.

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

Знаю, "это платно, а есть что-то бесплатно?". Есть! Данная группа совершенно бесплатная, просто начни общаться в комментариях, задавай вопросы, делись мнением. Я всем отвечаю и стараюсь помочь.

Начал рассматривать в лекциях по микросервисам конкретные изменения, которые возникли в связи с развитием ИИ. Разобрал популярный тезис про "30% контекстного окна LLM" и декомпозицию по модулям, немного каснулся документации и того как она должна формироваться. Самое важное, что нужно учитывать при проектировании:

- Контракты проектируются для LLM - говорящие имена, примеры, типизированные ошибки

- Идиоматичные сервисы - никакой магии, никакого GraphQL. LLM генерирует клиента, сервис должен быть предсказуемым

- Минималистичный интерфейс без условной маршрутизации (один эндпоинт - одна операция)

- Метрики, трейсы и логи - требуют более тщятельной проработки. Observability должна работать с LLM: correlation ID на каждый вызов, структурированные логи, автоматическая трассировка

- LLM тестирование - не должна идти от fuzzing и спек, а отдельный подход, который должен отталкиваться от семантики (например, проверка соответствия текста ошибки её коду)

- Валидация контрактов - часть обязанностей LLM при CI/CD

- Schema registry становится источником знаний для LLM (все версии схем, deprecated поля, правила миграции)

Важно - пляски вокруг контекстного окна уже не так сильно влияют на результат.

Честно говоря тема ИИ меня утомила, прогресс есть, но почему тогда стоит пустить агента в самостоятельное плавание и он начинает делать всякую дичь, может выкинуть в паблик приватные ключи, или доверять JWT токену без проверки цифровой подписи. И много других "почему?".

Не вижу пока, чтобы "human in the loop" куда-то делся. Работать по-другому - это да. Вот только это не значит "работать меньше". Просто теперь проще заставить человека работать больше или ИИ тебя сдаст, ибо "а чем ты занимался, покажи логи контекста?".

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

Вышел видос Антона Назарова с Лесей Набокой, где наконец-то противоположная сторона не оспаривает, что найм через рефералки/нетворкинг стремительно набирает обороты, вытесняя рынок резюме, уже как минимум находится в паритете (50 / 50), но тренд не планирует останавливаться на этом.

Было бы интересно услышать от Антона, что делать простым людям, которые до сих пор пытаются вкатиться через резюме?

И опять начинается "А почему ты нас не предупредил, почему не настоял, если знал, что рынок менятся?".

Ну во-первых, предупредил, просто уметь слушать - это не моя зона ответственности.

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

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

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

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

Как проходит встреча? Мы используем общий white board куда подключаются все участники и где обсуждаем текущие вопросы, делаем диаграммы и схемы, фиксируем ожидания от будущей системы и затем переходим к Event Storming, с целью выделить границы сервисов и сделать примерную декомпозицию будущей системы.

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

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

Спасибо всем кто пришел, надеюсь увидеться через неделю.