Современный IT-рынок штормит, а ожидания разработчиков часто разбиваются о суровую реальность. Пока одни пытаются сбежать от кризиса в собственные стартапы, вооружившись искусственным интеллектом, другие совмещают несколько full-time работ, сжигая остатки здоровья.
Глава Foxminded Software Сергей Немчинский разбирает главные мифы индустрии, объясняет разницу между кодингом и реальной инженерией, а также честно говорит о том, почему «простые решения» больше не работают.
Миф 1: «Если не найду работу, возьму Claude и запилю свой стартап»
В условиях кризиса аутсорсинга (особенно в регионах с высокими геополитическими рисками) многие компании начинают переквалифицироваться в стартап-инкубаторы. Для них это понятный бизнес-модель: вложить деньги в 100 проектов в надежде, что выстрелит один и окупит оставшиеся 99.
Однако для разработчика уход в стартап «от безысходности» — это ловушка.
- Код — это лишь 10% продукта. Инструменты вроде Claude или ChatGPT действительно могут помочь быстро написать код, но работающий код не равен успешному бизнесу.
- Параллельная вселенная предпринимательства. Профессия бизнесмена принципиально отличается от инженерной. Самая сложная часть маркетинга — это не покупка рекламы (продвижение), а продуктовая упаковка: создание уникального торгового предложения (УТП) и четкое донесение ценности до рынка.
- Статистика неумолима. Успешные стартапы чаще всего создают люди с огромным бэкграундом в бизнесе. Новички почти всегда прогорают.
Совет: Если вас не берут на работу, глупо открывать компанию. Лучше прокачивайте софт-скиллы (в первую очередь английский язык) и архитектурное мышление. Требования к разработчикам выросли, и чаще всего отказы приходят именно из-за слабых навыков коммуникации.
Миф 2: «На собеседованиях гоняют по паттернам, а в реальных проектах их нет»
Это классическая боль разработчиков: на интервью требуют безупречного знания теории, а после оформления в штат специалист видит хаотичный legacy-код без намека на архитектуру. Но у паттернов проектирования есть две неочевидные функции:
- Единый словарь. Паттерны нужны, чтобы команда говорила на одном языке. Когда коллега предлагает: «Давай использовать Стратегию», вы не должны округлять глаза. Вы мгновенно понимаете суть и можете аргументированно возразить: «Здесь всего два варианта развития событий, паттерн избыточен».
- Расширение кругозора. Изучение чужих архитектурных решений делает разработчика умнее, даже если конкретный шаблон не применяется здесь и сейчас.
Чистый код без паттернов оправдан только в двух случаях: на первых стадиях проекта (выход на рынок и MVP), либо если проект запущен и поддерживается неквалифицированными специалистами. Опытного Senior-разработчика часто нанимают именно для того, чтобы он пришел и навел порядок, внедрив те самые паттерны.
Миф 3: «Зачем нужны Архитекторы и Техлиды, если Middle/Senior делает всю работу?»
Мнение о том, что работа программиста ограничивается написанием кода, документацией и деплоем (DevOps) — это классический пик глупости на кривой Даннинга-Крюгера.
Написание кода — это самая простая и наименее объемная часть разработки. Сегодня с кодингом по техническому заданию прекрасно справляется ИИ. Настоящая работа инженеров высокого уровня лежит в другой плоскости:
- Refinement и извлечение требований. Вытащить из заказчика технические и нефункциональные требования — колоссальный труд. Бизнес-аналитик фиксирует лишь бизнес-логику, но переложить её на архитектуру кода — задача техлида.
- Работа с предметной областью. Ошибка на этапе проектирования сущностей может стоить месяцев переделок.
Пример из практики Foxminded: В первом проекте для сервисного центра команда спроектировала жесткую связь «один клиент (юрлицо) — его оборудование». На этапе бета-теста выяснилось, что некоторые клиенты сами являются сервисными центрами, они передают заказы друг другу, а оборудование нужно мигрировать между филиалами. На переделку архитектуры ушло два месяца. Предусмотреть такие сценарии на старте — задача архитектора.
Техлиды и архитекторы работают с компромиссами, предлагают бизнесу альтернативные, более надежные и дешевые пути решения проблем. Код, который не решает проблему клиента, никому не нужен.
Миф 4: «Double Employment — легкий способ получать X2 к зарплате»
Совмещение двух или более full-time позиций одновременно (работа на нескольких работодателей) стало популярным трендом, но за него приходится платить слишком высокую цену.
Почему работодатели против?
Такие сотрудники быстро вычисляются. Даже если разработчик силен технически, на двух работах он начинает underperform (выдавать результаты ниже своего потенциала): пропускает митинги, выключает камеру, демонстрирует нулевую проактивность. Для руководителя такой специалист — «ни рыба ни мясо» и первый кандидат на увольнение при любом сокращении штата.
Ловушки для самого разработчика:
- Остановка в развитии. Чтобы вывозить две работы, нужно делать то, что вы умеете делать закрытыми глазами. У вас не остается ни времени, ни ментального ресурса на изучение нового.
- Постоянный стресс. Пересекающиеся созвоны, страх случайно выдать контекст другого проекта на общем митинге держат нервную систему в постоянном напряжении.
- Крах личной жизни и выгорание. Мозг программиста эффективно работает не более 4 часов в день. Растягивая этот процесс на две фултайм-ставки, человек опустошает себя эмоционально. Разрушаются семьи, страдает здоровье. Заработанные «сверхдоходы» в итоге тратятся на полугодовой саббатикал и психотерапевтов.
Исключение из правил
Исключением являются, например, Go-разработчики в стартап-индустрии. Из-за специфики стартапов (хаос в менеджменте, нестабильность финансирования) специалисты часто ведут 3–4 проекта параллельно за небольшие фиксы, чтобы диверсифицировать риски на случай закрытия одного из них.
Также это может работать, если вам 20 лет и запас энергии позволяет совмещать работу, ночные клубы и личную жизнь. Для зрелого специалиста полноценный Double Employment — это прямой путь к выгоранию.
Главный вывод
IT-рынок повзрослел. Написание кода окончательно превратилось в рутину, которую можно делегировать нейросетям. Сегодня ценятся специалисты, умеющие решать проблемы бизнеса, выстраивать гибкую архитектуру и эффективно общаться. Попытки обмануть систему через создание стартапов без бизнес-плана или работу на три фронта одновременно чаще всего приводят к потере времени и жесткому выгоранию.