На одном из этапов карьеры автор текста на Habr насчитал два года на перенос бэкенда с Windows на Linux, а потом выяснил, что реальная работа заняла восемь месяцев и открыла продукту большую часть рынка. В этом и суть материала про семь языков разработчика: карьеру инженера тормозит не только код, но и неспособность говорить с бизнесом, командой и наймом на понятном им языке.
26 августа на Habr вышел текст автора rktkvv, который сейчас работает Staff Engineer и, как пишет Habr / Карьера, собрал семь собственных профессиональных факапов в одну карьерную схему. Его тезис звучит неприятно, но знакомо многим: задачи закрыты, к технической части вопросов нет, а повышения нет тоже. Идеи не взлетают, интервью разваливаются, решения где-то по дороге теряют поддержку. Причина, по его версии, в том, что сильный инженерный бэкграунд сам по себе не помогает, если человек отвечает не на тот вопрос, который ему на самом деле задали.
Первый такой вопрос пришёл от CTO. Формально это был разговор о смете на портирование серверной части под Linux, но по факту речь шла о рынке. Автор отказался от идеи, потому что не хотел лезть в незнакомый стек, а потом обнаружил неприятную экономику: пилотные клиенты сидели на Windows случайно, основная аудитория использовала Linux, а почти половину цены решения составляли лицензии Microsoft. Продукт проигрывал и по стоимости, и по совместимости. Отсюда первый вывод: инженер, который слышит только техническую постановку, легко пропускает стратегию. Для российского IT-рынка мысль не новая, но сформулирована жёстко: иногда разработчик защищает не архитектуру, а собственную зону комфорта, просто прячет это под аккуратной аргументацией.
Вторая история ещё болезненнее, потому что упирается в деньги. Автор пришёл к нетехническому CEO продавать «идеальное решение», рассказывал про надёжность и красоту реализации, а в ответ получил один вопрос: где деньги. Внятного ответа не было. Этот эпизод он называет одним из главных уроков в карьере: руководителю не нужно понимать архитектуру, его интересует, снимает ли предложение неопределённость и можно ли связать вложения с результатом. Для разработчиков и техлидов здесь нет ничего романтичного: сколько бы ни стоила красота системы, без ответа на вопрос «кто это купит» она остаётся дорогим упражнением. На фоне рынка, где от инженеров всё чаще ждут продуктового мышления, семь языков разработчика выглядят уже не как мягкие навыки, а как базовый набор для роста выше senior-уровня.
Дальше материал переходит к управлению людьми и продуктом. Став техлидом, автор быстро понял, что формальные полномочия почти ничего не стоят без доверия команды. Вчера ты спорил на равных, сегодня принимаешь решение сам, и соблазн продавить его статусом возникает мгновенно. Его рабочая формула проста: авторитет строится не на праве командовать, а на умении аргументировать и защищать своих людей перед руководством. Похожая логика и в продуктовой части. Когда техлид сказал, что новая рекомендательная функция «нереализуема», спор разблокировали не победой одной стороны, а сменой вопроса: не «можно ли сделать идеально», а «можно ли быстро проверить гипотезу». Вышел типичный для зрелых команд компромисс: быстрый изолированный прототип вместо месяцев на безупречную реализацию функции, которая ещё не доказала свою нужность.
Самый приземлённый и потому самый полезный блок касается найма. Автор пишет, что провёл 120 инженерных скринингов за последние месяцы, и примерно 90% кандидатов не смогли понятно объяснить, что именно они сделали. Не потому, что они слабые, а потому, что пересказ собственного опыта почти никто не тренирует. Типовые провалы знакомы любому, кто хоть раз участвовал в собеседованиях: либо человек рассказывает про «свёрнутые горы» без роли, результата и контекста, либо добросовестно перечисляет задачи, но не связывает их с вакансией. Для рынка, где многие разработчики по-прежнему надеются, что хороший GitHub и громкие названия компаний скажут всё за них, наблюдение неприятное. Скрининг, по сути, оказывается не проверкой хард-скиллов, а проверкой способности сделать за интервьюера часть его работы: дать историю, которую можно быстро пересказать дальше нанимающей команде.
Есть в статье и менее очевидный кусок про финансы. Когда компания оформляла продукт как интеллектуальную собственность, бизнесу понадобилось перевести работу разработчиков в учётные единицы. В ход пошли строки кода, число влитых pull request и количество багов, привязанных к конкретному человеку. Автор описывает это почти как производственную сатиру: одно и то же требование можно было переписать несколько раз, а стоимость в отчёте росла так, будто команда каждый раз создавала новую ценность. Но вывод у него не в том, что бухгалтерия ничего не понимает. Наоборот: если разработка сама не научится объяснять свою ценность в понятных бизнесу метриках, это сделают за неё и, скорее всего, грубо. В эпоху AI, замечает он, вместо строк кода легко начать считать токены, но риск тот же самый: объём затрат будут принимать за результат.
Последняя история про «звёздного» разработчика, который превратил своё решение в чёрный ящик и стал незаменимым для компании. Некоторое время это работает как личная крепость: тебя боятся трогать, без тебя не двигают продукт, твой статус только растёт. Проблема в том, что на уровне совета директоров такая конструкция называется не талантом, а key person risk. Когда человек уходит, вместе с ним уходит критичное знание, развитие продукта останавливается, а убытки могут измеряться уже не амбициями, а реальными деньгами. Это сильная концовка для всей идеи про семь языков разработчика: зрелость инженера определяется не только тем, насколько он нужен системе, но и тем, насколько система продолжает работать без него.
Главный вопрос после этого текста довольно неприятный для любой сильной команды: сколько карьерных тупиков в IT по-прежнему объясняют «рынком» и «политикой», хотя на деле инженер просто не умеет перевести свою работу с языка реализации на язык стратегии, денег, доверия, гипотез, найма, учёта и риска. Похоже, что в 2026 году именно этот перевод и становится настоящим порогом между хорошим разработчиком и человеком, который реально влияет на продукт и бизнес.