Бывает так: код хороший, задачи закрыты, к технической части претензий нет. Но и повышения тоже нет. Или идею не взяли. А на интервью — отказ без внятной причины.
Каждый раз я понимал, что дело не в инженерных скиллах. Только понимал медленно — на каждый такой инсайт уходили месяцы и годы. И стоило разобраться с одной ситуацией, как наваливалась следующая, где работал совсем другой механизм.
Стаж рос, и понимание вместе с ним. Но всегда с опозданием, потому что впереди стояла новая стена, и пробить её сразу я не мог.
Сейчас я Staff Engineer. Мне нравится то, чем я занимаюсь, я влияю на решения, которые считаю важными, и в стену больше не упираюсь. Помогло не то, что я стал сильнее как инженер — сильным инженером я был и тогда, когда упирался. Помогло другое: я разложил эти ситуации по полочкам, расстался с иллюзией собственного инженерного величия и начал комбинировать техническую экспертизу с семью вещами, которых поначалу не замечал.
Это семь языков. И ни один из них — не язык программирования.
Ниже расскажу семь историй. В первых я выгляжу неважно, но это и к лучшему: победные кейсы никого ничему не учат.
1. Технический CTO, или как я отбрил вопрос и через год пришёл каяться
Времена были десктопные. Первым продуктом, который я делал с нуля с маленькой командой, было Windows-приложение с серверной частью.
Всё шло хорошо: появились первые клиенты, они были довольны.
В какой-то момент ко мне приходит CTO и спрашивает: сколько будет стоить портировать бэкенд на Linux.
Я насчитал два года и сказал, что оно того не стоит.
Цифра была честной ровно настолько, насколько мне было нужно. Реальная причина — я не хотел лезть в незнакомую технологию. Мне было комфортно в том, что я уже знал, и я нашёл красивое инженерное обоснование, чтобы туда не идти. CTO пришёл с вопросом, а не с требованием, аргументов давить у него не было, и тема закрылась.
Через год я сам пришёл к нему просить ресурсы на этот самый порт.
Выяснилось следующее: пилотные клиенты действительно сидели на Windows, но это была случайная выборка. Основная часть рынка держала серверы на Linux, причём на бесплатных дистрибутивах. А в нашем ценнике половину суммы составляли не мы, а закупочные лицензии Microsoft. Мы одновременно были неконкурентоспособны по цене и отрезаны от большей части рынка.
Порт занял восемь месяцев — это вместе с переучиванием команды. Не два года.
Я честно сказал CTO, что ошибся. Он дал ресурсы и не стал напоминать, кто был прав.
Урок, который я вынес: когда технический руководитель приходит с вопросом «сколько будет стоить», он редко спрашивает про смету. Он проверяет, видишь ли ты то же, что видит он. Я услышал вопрос про ресурсы и ответил про ресурсы. А вопрос был про рынок.
И вторая часть урока, менее приятная: я тогда защищал не архитектуру и не сроки команды. Я защищал собственную зону комфорта и упаковал это в техническую аргументацию так убедительно, что сам поверил.
Поэтому первый язык — это язык стратегии. На нём говорят про то, где компания окажется через год, а не про то, что удобно делать сегодня. Трансформация, которая мне потребовалась, состояла в том, чтобы научиться слышать за вопросом о ресурсах вопрос о том, куда мы вообще идём, и проверять, не защищаю ли я в этот момент себя.
2. Нетехнический CEO. «Где деньги, Зин?»
Это была поворотная точка, хотя тогда я так не думал.
У меня были амбиции: взять направление под полный контроль, вести его с технической и не только стороны и сделать это рывком в карьере — первым по-настоящему своим решением, а не исполнением чужого.
Я пришёл к CEO продавать идеальное техническое решение. Объяснял, как красиво оно устроено, как надёжно будет работать, какое счастье получат клиенты.
Он не понял ни слова и задал один вопрос: где деньги?
Я ответил, что деньги придут, потому что продукт очень крутой.
На этом разговор закончился. Он развернул и моё решение, и мои амбиции.
У меня был подробный ответ на вопрос, как это будет работать. И не было никакого ответа на вопрос, откуда возьмутся клиенты. Я даже не заметил, что второго ответа у меня нет: мне казалось, он следует из первого.
Тогда я решил, что меня не оценили. Это был не единственный повод, но именно тот разговор стал финальным гвоздём — вскоре я закончил долгое сотрудничество и с компанией, и с этим человеком.
Прошло много лет, и я могу сказать прямо: он задавал правильный вопрос, а я на него не ответил.
Сегодня это очевидно даже сильнее, чем тогда, ведь реализация продукта — это самая понятная и дешёвая часть цикла, а ответ на вопрос «кому мы это продадим» — самая дорогая и самая важная. Начинать надо было с неё, а не с того, чтобы построить рабочий, красивый и никому не нужный продукт.
Это был самый простой, зато самый важный урок в моей инженерной карьере: CEO без технического бэкграунда не притворяется, что не понимает твою архитектуру. Он правда её не понимает — и не должен. Он оценивает не решение, а то, снимаешь ли ты с него неопределённость или добавляешь новую. Я тогда добавил неопределённость: пришёл с большим планом и без единой цифры под ним.
Язык второй, возможно, самый важный — язык инвестиций. Каждое решение здесь звучит как «мы вкладываем столько и рассчитываем получить вот это». Нужно перестать продавать качество решения и начать отвечать на вопрос, как это окупится. На это мне понадобилось несколько лет и одна потерянная работа.
3. Команда. Вчера равный — сегодня даёшь указания
Первые два языка я учил, стоя перед людьми, которые принимали решения обо мне. Дальше начинается другая часть карьеры — та, где решения начал принимать я.
Техлидом я стал не по желанию. Если бы не стал, продукт закрыли бы, команду разогнали, а я оказался бы на улице. С семейными обязательствами за спиной это был не тот сценарий, который я мог себе позволить.
Это и подтолкнуло к решению: выйти из роли обычного разработчика и на ощупь искать себя в роли человека, который должен ещё и управлять командой. Теми самыми людьми, с которыми буквально вчера я сидел в одной роли и ждал указаний откуда-то сверху. А теперь этим «сверху» стал я сам.
Самым сложным оказалось несогласие. Раньше с этими же людьми я спокойно находил компромисс — мы были в равных позициях, и спор был просто спором. Теперь при каждом расхождении внутри поднималось желание ударить кулаком по столу: ребята, мнение у вас есть, но главный тут теперь я, и сейчас я вам всё объясню.
Пару раз я ловил себя ровно в этой точке. Не позволил ни разу — какое-то шестое чувство подсказывало, что так делать не надо и что искать компромисс придётся всё равно, просто позже и дороже. Поэтому приходилось учиться принимать решения на фактах, а не на раздражении.
Это был перелом. Я буквально шёл вразрез с тем, как обо мне думали вчерашние сокомандники, а теперь подчинённые.
Но у роли обнаружилась вторая сторона, о которой я до этого не думал. У меня появился инструмент, чтобы команду защищать. Выбивать условия — и технические, и финансовые. Договариваться с руководством за конкретного человека, менять формат взаимодействия, искать новых людей. Вся организационно-административная работа, которую до этого не делал никто. Я, разумеется, тоже — учился на лету.
И вот когда я начал давать ребятам уверенность, что на меня можно положиться в сложных ситуациях, всё начало вставать на места.
Авторитет сложился не из того, что я требовал и настаивал. Он сложился из двух вещей. Первое — я научился аргументировать свои решения. Второе — команда увидела, что положиться на меня можно и в вопросах, к разработке отношения не имеющих. Ровно так же, как я полагался на них в технических решениях.
Это и был мой первый настоящий урок в роли лида. Получая в руки инструменты (назовём их управлением, слово «власть» тут неточное), применять их надо в обе стороны сразу. И чтобы стоять на своём, и чтобы защищать людей. Односторонний вариант не пройдёт: команда очень быстро считывает, на кого ты работаешь.
Так что третий язык — это язык доверия. Он всегда взаимный. Односторонней версии не существует: если ты не доверяешь команде, она не будет доверять тебе, сколько бы полномочий у тебя ни было. Моя трансформация в лида — это перестать видеть в новой роли право распоряжаться и увидеть в ней обязанность быть надёжным.
4. Продакт: а если «нет» прилетит тебе?
На одном проекте я вёл команду и одновременно закрывал продуктовую функцию — по тайтлу это называлось CTPO (CTO плюс CPO), а по факту я был тимлидом и продактом в одном лице. За архитектуру при этом отвечал отдельный техлид.
Пришёл я в середине жизни проекта: продуктовые ожидания уже сформировались, и одной из задач было — найти новые точки роста.
Первой из моих идей была рекомендательная система контента с несколькими нестандартными атрибутами. Логика была такая: рекомендации увеличивают время работы с продуктом, время означает внимание пользователя, а внимание мы умели перепродавать тем, кому оно интересно.
Питчу идею команде. Всем нравится. А техлид начинает сопротивляться — и, надо сказать, вполне резонно: он показывает конкретные ограничения текущей архитектуры. И встаёт в позицию: это нереализуемо.
Вот здесь развилка, ради которой я эту историю и рассказываю.
Будь я классическим продактом без инженерного бэкграунда, я бы опустил руки. Услышав «нереализуемо» от человека, который знает систему изнутри, пошёл бы искать другую идею. Ровно так это и работает в большинстве команд: техлид говорит «нет», продакт не может проверить аргумент и отступает.
Но я эти ограничения видел сам, когда проводил технический аудит. Поэтому предложил посмотреть на ситуацию иначе — не спорить с его «нет», а изменить постановку задачи.
Мы договорились сделать быстрый прототип. Тяп-ляп и в прод — но изолированный так, чтобы качество кода в нём не могло повлиять на ключевые узлы системы. Задача прототипа была не в том, чтобы работать долго, а в том, чтобы проверить гипотезу: нужна ли пользователям эта функция вообще. Считать мы это умели.
Дальше логика простая. Если интерес подтверждается — вкладываемся в полноценную реализацию по тем самым правильным рельсам, о которых техлид и говорил. Ему нужно было дополнительное время, и после подтверждённой гипотезы это время у него появлялось. Если не подтверждается — мы не тратим месяцы на архитектурно безупречную функцию, которая никому не нужна.
Что я отсюда вынес.
Техлид не ошибался. Его «нет» было технически обоснованным, и в собственной системе координат он был прав целиком. Проблема в том, что «нереализуемо» — это ответ на вопрос «можем ли мы построить это правильно». А я как продакт задавал другой вопрос: «можем ли мы узнать, стоит ли это вообще строить».
Разговор разблокировался в тот момент, когда мы перестали обсуждать решение и начали обсуждать, что именно мы пытаемся выяснить.
И честное замечание напоследок. Я смог развернуть этот разговор только потому, что мог говорить с техлидом на его языке. У большинства продактов такого рычага нет, и когда они слышат «нереализуемо», у них не остаётся никаких инструментов, кроме как поверить или продавить силой. Оба варианта плохие.
Четвёртый необходимый язык — язык гипотез. На нём не спрашивают «как правильно», на нём спрашивают «как быстро мы это узнаем». Для техлида это значит перестать отвечать «нет» и начать отвечать «вот три варианта и вот что каждый стоит». Техническая позиция при этом остаётся той же — меняется только то, открывает она разговор или закрывает.
5. Боль рекрутера: почему подавляющее большинство кандидатов не могут рассказать, что они сделали
Здесь я целиком с другой стороны стола, и это, возможно, самая полезная часть статьи, так как изнутри этот процесс не виден почти никому.
В моей компании нерядовая практика: рекрутер не ведёт кандидата напрямую на техническое интервью — сначала его пропускают через скрининг инженеры, и я один из них.
И вот моё наблюдение: на 120 скринингах, которые я провёл за последние месяцы, примерно 90% кандидатов не смогли внятно рассказать, кто они и что они сделали. Не потому что слабые — многие сильные. Просто рассказ о себе как о профессионале — это отдельный навык, которым почти никто не занимается.
Провалы делятся на два типа.
Первый — рассказ про свёрнутые горы. Верхнеуровнево, красиво, с энтузиазмом. Какие именно горы, к чему это привело и какова была личная роль рассказчика — понять невозможно. Для слушателя такие кандидаты сливаются в серую массу: выделиться этим способом не получается ни у кого, потому что так говорят все.
Второй — опыт, который никуда не привязан. Человек добросовестно описывает, чем занимался, но я не могу вытащить оттуда ни одного факта, который связал бы этот опыт с вакансией, о которой мы разговариваем. Опыт может быть отличным, но если я не вижу пересечения, у меня нет причины двигать человека дальше.
Что происходит у меня в голове в эти пятнадцать минут. Я накладываю рассказ на то, что вижу каждый день в работе, и на те требования, которые мы с коллегами предъявляем сами себе. Картинка получается бинарная: человек хотя бы краем пересекается с этим множеством — или лежит полностью в стороне. Если полностью в стороне, мы даже не идём проверять конкретные навыки. Незачем.
Вывод, который я бы отсюда вынес на месте кандидата: скрининг — не проверка квалификации. Это проверка того, можешь ли ты сделать чужую работу за собеседника. Тот, кто тебя слушает, должен потом кому-то тебя пересказать, иначе дальше твой рассказ не пройдёт, каким бы сильным ты ни был.
Пятый язык назвал бы языком пересказа. Всё, что нельзя воспроизвести чужими словами через час после разговора, не существует. Если ты идёшь в найм, перестань описывать себя качествами и начни описывать ситуациями с измеримым результатом. Опыт при этом не меняется ни на грамм. Меняется только то, можно ли его передать дальше.
6. Бизнес, или как мы считали себестоимость кода в строчках
В какой-то момент мы решили оформить один из наших продуктов как полноценную интеллектуальную собственность — по-настоящему, в легальном поле. Пошли с этим к бизнесу и бухгалтерии.
Выяснилось, что по применимому праву у продукта должна быть номинальная стоимость: она нужна как доказательство общей стоимости работ, которые компания выполняет. А считается эта стоимость в человеко-часах, потраченных на изготовление.
Дальше бухгалтерия задала вопрос, к которому я оказался не готов: хорошо, а себестоимость какая? То есть нужно было соотнести зарплаты команды разработки с конкретным результатом на выходе.
Вы будете смеяться, но мы это сделали. Ввели три метрики: количество написанных строк кода, количество влитых пул-реквестов и количество багов, привязанных к конкретному разработчику. Первые две — метрики ценности, третья — понижающая. Финансовый аналитик, сидевший с бухгалтерией, аккуратно приземлил всё это на зарплаты.
Я всё время находился в ощущении абсурда. Потому что регулярно случалось так, что одно и то же функциональное требование мы переписывали несколько раз — просто потому, что этого требовал процесс разработки. И стоимость засчитывалась трижды, как будто мы трижды создали новую ценность.
Честно, я до сих пор не знаю, как корректно свести язык финансов и то, как мы производим продукты. Это два разных языка — они нам про яблоки, а мы им про апельсины.
Забавно, что с тех пор ничего принципиально не изменилось, поменялись только единицы. Сегодня в эпоху AI считают уже не строки кода, а потраченные токены. Метрика новее, выглядит технологичнее, а понимания в ней ровно столько же: она измеряет объём производства и затрат, а не созданную ценность — тот же счёт яблок в апельсинах.
Зато я усвоил другое: момент, когда бизнес не может посчитать твою работу, — это не их проблема, которую можно проигнорировать. Это твоя проблема. Потому что считать они всё равно будут — просто теми метриками, которые придумают без тебя. И тогда разработка окончательно превращается в статью расходов: то, что нельзя связать с результатом, остаётся в отчёте просто затратами.
Практический вывод из всей этой истории оказался неожиданно простым: с бухгалтерией и финансами надо дружить. Не терпеть, не отбиваться от их запросов, а идти к ним самому и разбираться, как они считают. Люди, которые сводят сметы, обычно рады объяснить свою логику, ведь их редко кто спрашивает. А ты получаешь доступ к тому, как твоя работа выглядит на верхнем уровне, и возможность повлиять на метрику до того, как её придумают без тебя.
Язык шестой, иностранный, — язык учёта. На нём любая работа должна превратиться в строку, которую можно занести в отчёт. Тут только принять, что перевод в эти единицы — твоя задача, а не бухгалтерии. Признаюсь честно, стадию принятия я до конца так и не прошёл — но хотя бы перестал считать её необязательной.
7. Инвестор и борд: Тот-Кого-Нельзя-Называть
Эту историю я наблюдал со стороны.
Был разработчик-суперзвезда. Создал действительно уникальное решение, компания заработала на нём приличные деньги. А потом от этой славы, скажем прямо, сошёл с ума.
Настолько, что люди, управлявшие огромным бизнесом, боялись прийти к нему с просьбой, если она хоть немного расходилась с его взглядами на жизнь. Тянулось это три или четыре года.
Технологически он защитил себя идеально. Решение было закрытым, детали работы и все её нюансы жили у него в голове и больше нигде. Отказаться от этой головы никто не решался.
Страдали при этом сотни людей: те, кто пользовался инструментом и годами не мог добиться расширения функционала, и те, кто пытался что-то доработать сбоку и упирался в стену.
А кончилось всё предсказуемо: он ушёл. Просто взял и ушёл, не передав никому ничего.
Дальше случились две вещи. Развитие продукта, которое тормозилось все эти годы, теперь встало окончательно. И поддержка остановилась полностью — инструменты в какой-то момент перестали справляться со своей функцией, а починить их было некому. Убытки от этого простоя считались миллионами.
Люди, которые пришли после, оказались ровно там же, где были все до них: перед чужим чёрным ящиком, в котором надо разбираться с нуля.
Что здесь важно понять. Незаменимость выглядит изнутри как безопасность — тебя нельзя уволить, тебя нельзя обойти, твоё слово весит больше всех. Именно так этот человек и прожил несколько лет.
Но на уровне борда это описывается одним термином: key person risk. И считается не в уважении, а в деньгах: в оценке компании, которая снижается, потому что критичная часть бизнеса держится на одном сотруднике.
Он думал, что построил себе крепость, а на деле это было то самое бутылочное горлышко для всего бизнеса.
Язык седьмой — это язык риска. На нём любая зависимость от одного человека становится не достижением, а угрозой, которая снижает стоимость компании. Зрелость разработчика измеряется тем, насколько уверенно всё работает без него, а не насколько он незаменим.
Что общего у этих семи историй
Когда я собрал их вместе, обнаружилась неприятная закономерность.
Ни в одной из них не решалось, хороший ли я инженер. Вопрос всегда стоял иначе: снимаю ли я неопределённость с человека напротив или создаю ему новую. Просто у каждого эта неопределённость своя, и говорит он о ней на своём языке.
Семь языков, и ни один не выучивается по книге. Каждый требует трансформации — перестройки в голове, а перестройка вещь неприятная: приходится признать, что ответ, которым ты гордился, был ответом не на тот вопрос.
Я на все семь долго отвечал одинаково, рассказывая, насколько хорошо разбираюсь в системах. Иногда срабатывало. Чаще нет, и я списывал это на то, что меня не оценили.
Не скажу, что прошёл все семь трансформаций до конца. Но разница между сегодняшним состоянием и теми стенами, о которых я писал в начале, сложилась именно из этих переходов — а не из того, что я стал сильнее как инженер.
Мне повезло столкнуться с этим в начале карьеры — и всё равно я потратил время в поисках причины. А многие сидят в этом годами и объясняют застой чем угодно: рынком, руководством, невезением. Настоящую причину при этом не проверяют, потому что она неприятная.
А проверить её просто: вспомни последний разговор, после которого ничего не сдвинулось, и спроси себя — о чём тебя тогда спрашивали на самом деле.
Комментарии (26)
Amabi
26.08.2026 09:26Понравился заход! Класс!
Переформулирую со своей колокольни в виде критериев оценки:
технический - надежность решения
экономический - прибыльность
рыночный - востребованность
административный - минимизация рисков
социальный - когда хорошо относятся
оставлю на втором плане: творчество, инновации, экологичность
и наверняка еще много чего забыл :)
nickmanecannotbeempty
26.08.2026 09:26Нахера тогда на собеседованиях спрашивают языки, уровни изоляции транзакций, сетевые протоколы, SOLID (куда ж без него) итд? Они там все дураки, да?
rktkvv Автор
26.08.2026 09:26В части проверки технических компетенции ничего не изменилось - их все еще надо оценивать. Но начиная с некоторого уровня карьеры нетехнические знания начинают играть все более важную роль.
nickmanecannotbeempty
26.08.2026 09:26Как человек как раз на некотором уровне карьеры, я абсолютно согласен с этой мыслью. Но как человек участвовавший в найме по обе стороны стола для допросов с пристрастием, я видел некоторое дерьмо. С возникновением нейромашинок для печатания кода, нанимающме компании будто бы поехали головушкой на кроссдисциплинарности, и их перекосило в сторону тотального непонимания роли инженера. Ну ладно, можно примириться с тем, что от фронтенд-джунов сейчас требуют опыта развертывания кластера кубернетиса на bare metal, тут я обеими руками за — парни и девчата должны расширять кругозор, иначе так лысыми дураками и помрут. Но зачем вы его, ребёнка болезного, мучаете бизнесовым мышлением? Ну на месте как-нибудь определится, ну джун он в конце концов. Если бы он всё это знал и умел, в гробу бы он видал подаваться на ваши нищенские 3 бакса.
Я конечно понимаю, что им надо отличить человека с опытом от самозванца с нейромашинкой, но блин... Ну не так это делается
omaxx
26.08.2026 09:26Есть технические собеседования, а есть т.н. "behavioral interview". Погуглите про процесс найма в крупные компании, там одним кодингом на собеседовании не отделаешься...
nickmanecannotbeempty
26.08.2026 09:26Так я в крупной работаю. В чудовищно, невообразимо крупной. Просто парень я не пафосный — могу и лопату в грязь, а могу и идею в жизнь. И дело-то нехитрое, когда домен знаешь. Коню понятно — думать надо головой.
Я почему спросил.
10 Дело в том, что чем мельче и глупее нанимающая сторона, тем больше у них нарциссизма и упора на эти ваши бехериовистические интервью — и тем больше статеек в линкедыне на тему "вчера я подскользнулся на куске собачьего говна, и вот чему меня научил этот случай в плане маркетинга и искусства продаж" — а дальше два экрана мотивационного нейрослопа от великого СЕО-фаундера конторы рога и копыта. Ни в одной крупной компании не позволят себе постить такое — да возьмите навскидку блог Майкрософта, Амазона или Нетфликса: найдёте — с меня пиво.
Я был поражён, насколько просто и приятно было пройти собеседование с инженерами моей компании: мы говорили о базах, нагрузках, очередях, ETL, IaC итд. Это был разговор инженера с инженером. Ну, пяток вопросов по софт-скиллам задали, но, скорее для оценки того, что я не наврал в резюме и действительно работал в указанных сферах.
И что же в итоге? И код пишем, и девопсим понемногу, и инфраструктуру тюним под хуйлоад, и с кастомерами на равных брейнштормим по методологии YAGNI. И матюгаемся на них в курилке от души. И всё это без скучных линкедыновских нейропроповедей, всё по-человечески.
А если компаха уровня скейлапа пытается разводить софтскилловый марафон, где девелоперу предлагается взвалить на себя роль СЕО, так может быть им стоит поменять СЕО, этот протух, раз на его место берут человека под другим тайтлом?
Я ещё раз говорю и неустанно повторяю: инженер должен быть инженером. А ещё— взрослым и простым человеком не без доли скепсиса и с фигой в кармане.
20 GOTO 10
rktkvv Автор
26.08.2026 09:26Быть инженером, необходимое и достаточное условие. И оно откроет большое количество дверей на пути. Но в какой-то момент игра на этом уровне будет пройдена, а чтобы попасть на следующий (по сложности, по интересу, по доступности другого класса вызовов и т.д.) понадобится дополнительный набор навыков.
PeeWeee
26.08.2026 09:26Есть только одна игра - игра престолов.
Хаос - это лестница.
Вот оно чего,
СеменычПетир. /s
nickmanecannotbeempty
26.08.2026 09:26Это как раз и есть необходимые, но недостаточные навыки
nickmanecannotbeempty
26.08.2026 09:26И не было бы проблемы, не будь людей, возлагающих эти все вещи на алтарь своего культа, как если бы им хотелось раздуться от гордости, струйно мироточить во все стороны Истиной Правдой итд. Очнитесь! 21 век уже на исходе, а вы всё надуваете свои лопнувшие пузыри корпоративного тщеславия. Это всё уже было. В каждой эпохе — да хоть бы в том же СССР. Помните?
vadimsolovev
26.08.2026 09:26Да уж, статья прям в точку. Когда в джунах сидишь, кажется, что достаточно просто фигачить код 24/7 и быть батей в синтаксисе. А потом сталкиваешься с реальностью и понимаешь, что умение донести мысль до бизнеса или тупо не поссориться с командой решает гораздо больше, чем изящный рефакторинг.
nickmanecannotbeempty
26.08.2026 09:26Хочешь выбраться из джунов? Не слушай торгашей, расти ввысь, вширь и вглубь, а дядьки с портфелями — они тоже люди, но пусть знают своё место, в то норовят
Devpiligrim
26.08.2026 09:26Хорошая статья. Почитал, прямо себя увидел. Люди разные, а пути схожие. Тоже влез в управление вначале с руками и ногами, что бы удержать проект и команду от развала. Тоже были случаи когда хотелось стукнуть по столу и заставить всех делать так, как я считаю нужным... И тоже сдерживался.
Единственное отличие. Вовремя понял, что это не моё, столько нервов тратить, держать себя в узде, подстраиваться по 10 раз на дню то под бизнес, то под топов, то под разработчиков... К концу дня чувствовал себя как выжатый лимон...
Вернулся уже как архитектор - и платят не хуже и нервов тратишь в разы меньше.
stxdtm
26.08.2026 09:26У меня была ситуация, вот прям подходящая под некоторые из этих пунктов… В компании появилась новая технология, а у меня появился проект, как эту технологию превратить в уникальный продукт. Он не давал огромной прибыли (какие-то сотни тысяч в месяц), но радикально изменил бы некоторые процедуры внутри компании, которые значительно повысили бы качество работы с клиентами и снизили нагрузку на сотрудников.
Я проявил инициативу, предложил уникальный продукт, который заодно выделил бы нас среди конкурентов, перед этим уже доказал свою компетентность (как мне казалось), показал выгоду (как мне казалось) - но все равно оказался не прав… А почему? Как раз потому, что не владел какими-то из этих важных языков.
Я тогда был наивным и слепо доверился человеку, который имел доступ к руководству и согласился стать моим ПМ (проект-менеджером). Мы обсудили возможные варианты и пришли к выводу, что можно реализовать проект в рамках договора ГПХ как самостоятельную единицу (не спрашивайте).
Я подготовил презентацию, он вывел меня на стейкхолдеров. Там я подробно расписал текущую ситуацию, плюсы, которые мы получим после релиза, озвучил, сколько бы это стоило, если бы мы наняли команду разработчиков со стороны и предложил сделать это дешевле (и это тоже казалось мне правильным - я не взял ценник из головы, а аргументировал свою позицию рыночными ценами, объемом работ, необходимыми для решения задачи компетенциями и предложил выгодный вариант).
Дополнительно мой ПМ подготовил модель, которая оценивает затраты, считает возможную прибыль, окупаемость и прочие интересные вещи, но… Как оказалось, сделал он это с помощью LLM и не вполне качественно…
Сейчас я понимаю, что мы упустили важный этап - перед разговором со стейкхолдерами нужно было найти кого-нибудь, кто мог бы провести техническую экспертизу со стороны (подтвердив или опровергнув мои тезисы), и перевести технические термины на язык тех, кто даёт деньги, потому что стейкхолдеры задали мне ровно четыре вопроса:
Почему так долго? Нужно максимум за полгода, а лучше - за квартал (что-то связанное с бюджетом, финансовыми отчётностями и т.п.), а проект был весьма сложным и включал более 10 микросервисов + старое легаси, которое надо было частично переписывать, и все это одним человеком, за год, без возможности кого-нибудь привлечь.
За что тут платить? (“если бы твой проект приносил миллионы - разговор был бы другим, а так…”).
Почему так дорого? (в пересчёте на месячную оплату мне были готовы заплатить как джуну, и только после того как все будет реализовано, протестировано, запущено и покажет прибыль, хотя объем работ на тот момент подразумевал (на мой скромный взгляд) хотя бы команду из сеньора и одного-двух мидлов - нужно было с нуля разработать архитектуру (в том числе и для сетевых сервисов с высокой нагрузкой), выбрать подходящие решения, реализовать, протестировать, написать документацию и научить пользоваться. Понятно, что есть какие-то стандарты и распространенные паттерны и технологии, но вряд ли эти знания стоят 50к в месяц).
Что будет, если ты уйдешь? (проект должен был быть написан на go, а людей с таким навыком в округе не наблюдалось. Мой ответ в духе “не обязательно искать разработчика под боком в эпоху удаленки” не был принят).
А спустя время я случайно узнал, что мне отказали не потому, что проект плохой, а потому, что я осмелился шантажировать руководство зарплатой. Что нужно было сделать его бесплатно, показать свой скилл, и тогда - может быть - мне подняли бы зарплату, процентов на пять, а если получится очень хорошо - даже на десять…
С моей точки зрения, парадокс просьбы “сначала сделай - а потом проси” заключается в том, что буквально за пару месяцев до этого разговора мы с моим начальником реализовали уникальный проект, который сэкономил компании несколько миллионов рублей, и этот момент был публично озвучен на очередном корпоративном собрании в присутствии тех же стейкхолдеров, и это никак не сказалось на моей зарплате, видимо, не считается…
Да, мы разговаривали на разных языках, да, мой ПМ оказался так себе ПМ, а я ему слишком доверился, да, я не понимал, чем руководствуются люди, которые принимают решения, куда потратить деньги, но… Плохой опыт - тоже опыт…
Devpiligrim
26.08.2026 09:26Типичная ошибка - предлагать руководству компании в которой работаешь проект за отдельную плату. Прикинь, к тебе подходит жена и говорит, дорогой, я научусь готовить блюда мексиканской кухни, но они будут за отдельную плату. Как отреагируешь?
Да, семья и работа разные вещи, но с точки зрения психологии - ты и так уже принадлежишь компании, зачем тебе доплачивать, тем более за идею, которая не реализована даже?stxdtm
26.08.2026 09:26Точно так же могу сказать - типичная ошибка руководства - думать, что сотрудник принадлежит компании, поэтому ему можно не платить за дополнительную работу. На мой взгляд, это всегда договорные отношения. В Вашей аналогии - это как если бы жена подошла и сказала - “дорогой, наша машина не едет, я слышала, ты ищешь хороший сервис, а они все дорогие, так вот знай - я могу и движок перебрать. Помнишь Вовку? Я ему тачку делала. Давай сэкономим семейные средства, но ты мне купишь что-нибудь вкусненькое.”
Я наверное упустил важный нюанс - на тот момент разработка не входила в мои служебные обязанности, а компания, не имея своих разработчиков, периодически прибегала к услугам сторонних команд.
Собственно, поэтому я и предложил свои услуги, но не в рамках своих прямых обязанностей. И то, что постоянно происходит с другими сотстороны, закончилось, даже не начавшись, наверняка именно потому, что руководство думало так же - мы уже платим, пусть и за другое, так зачем мы будем платить ещё?
Devpiligrim
26.08.2026 09:26Важное уточнение, которое меняет картинку, но не сильно и не в вашу сторону.
С точки зрения руководства, человек который даже не кодер в компании, просто с презентацией - чуть больше чем пустое место. Скажите спасибо что хотя-бы выслушали.
Ну реально, как можно доверить серьёзный бюджет человеку, который вряд-ли что-то может? Красивая презентация - пшик. Ваши выкладки - пшик, если приложение не дойдёт до прода.
И вопросы вам правильные задали, но вы даже не увидели в них подвоха. Даже сейчас на опыте не видите.
Почему так долго? - у вас нет стратегии поэтапного развития продукта. Если бы, вы дали первый результат через месяц, следующие доработки готовы били бы выкатить через 3, мы бы подумали что можно и рискнуть.
За что тут платить? - мы не готовы платить в долгую без видимых результатов.
Почему так дорого? - почему мы должны рисковать деньгами, если совершенно не уверены, что получим хоть копейку прибыли.
Последний вопрос даже переводить не нужно...
Всё на поверхности.stxdtm
26.08.2026 09:26Я понимаю, что Вы пытаетесь мне сказать, но довольно много нюансов осталось за рамками, которые позволяют комментарии.
Скажу лишь, что это был не первый проект, который я писал для нужд компании (просто они были не такими крупными и я делал их на голом энтузиазме, потому что было интересно, и в том проекте, который я упоминал ранее, я тоже участвовал как разработчик), что была подробная дорожная карта и поэтапное внедрение, благо микросервисная архитектура позволяла использовать сервисы по мере готовности, и много чего еще - я реально готовился несколько месяцев, тестировал решения, которые планировал использовать, собирал материалы, анализировал проблемы и так далее.
Просто в этот раз получалось слишком масштабно и дорого. Как мне сказали на одной из встреч: “Да у нас коммерческий директор столько не получает!” (с)
Пожалуй, безоговорочно Вы правы только в одном - итоговая встреча действительно состоялась только из вежливости - все решения были приняты заранее.
Devpiligrim
26.08.2026 09:26Нюансы - они такие... Но реально, текущему работодателю продать идею за нормальные деньги - очень сложно.
Пример: мой прошлый работодатель, за идею автоматизации на производстве, которая сэкономила предприятию миллионы в год, заплатил что-то около 200 т.р.
ИМХО: Это всё что нужно знать о продаже идей по текущему месту работы :)
lastpx
Пункт про язык гипотез оказался у меня дороже остальных шести, причём узнал я его цену наоборот — когда безупречно решил не ту задачу.
В августе на мой проект зашла ферма ботов: двенадцать тысяч регистраций за двое суток, капча Cloudflare не остановила ни одной. Две недели я занимался тем, что умею: разбирал распределение регистраций по рефереру, искал аномалии, в итоге нашёл приём, который выбил всех до одного и не задел живых людей. Технически это была чистая победа, и я ей до сих пор доволен.
А потом ботов не стало — и стало видно, что живых-то и не было. Настоящий вопрос всё это время стоял другой: не «как отбиться», а «зачем сюда вообще приходить». И я его не трогал ровно потому, что он не решается кодом, а значит не выглядит как работа. Две недели отладки ощущаются продуктивнее, чем один честный вечер с вопросом, на который у тебя нет метода.
Так что я бы добавил восьмой язык: язык неудобного вопроса — того, который не решается тем, что ты умеешь лучше всего.
rktkvv Автор
Именно! Существует много вопросов, которым не уделяется внимание, потому что задача рассматривается с точки зрения инженера. Чем раньше получиться принять, что это только одна из возможных, необходимых, но не достаточных точек зрения, тем быстрее возрастет ценность такого опыта.
PeeWeee
Немного критики.
Прежде всего - мне понравилась статья. Да, очередной успешный успех, “семь правил которые сделают вас…”, и т.п, из-за чего, видимо, у нее (пока?) не так много плюсов. Но написано довольно живо, примеры яркие, лаконичные, правдоподобные. Прошу не обижайтесь на последнее определение, я циник и инженер - то что не могу верифицировать, а тем более может иметь внятное альтернативное объяснение, мне кажется правильнее назвать так.
Так вот, что собственно не понравилось.
Кликбейт, причем неудачный. Сама его стилистика желтушная оттолкнет больше чем привлечет. Ну и несоответствие содержанию.
“Для успешной карьеры разработчику нужно знать семь языков…” Что-нибудь в таком духе и формально точнее отражает суть статьи, и менее раздражает в итоге.
Но это как-бы полбеды, даже скорее малый инициирующий заряд небольшого внутреннего взрыва возмущения :) Собственно даже не самой статьей, а некой комбинацией современный тенденций и личных представлений о желаемом идеальном мироустройстве.
Вы раскрыли какие-то полезные, в определенном карьерном и личностном срезе, наверно более важные моменты. Но по заголовку и вступлению следует, что Вы это адресуете не (потенциальному) будущему staff engineer или абстрактному амбициозному юноше “хочу быть успешным и богатым, желательно быстро и не сильно парясь”, а некоему усредненному разработчику (инженеру). При этом вся техническая база мгновенно выносится за скобки и обесценивается. Да, мне лично хочется верить, это лишь потому что Вы настолько круты как инженер и недостаточно опытны как писатель, и для Вас это как умение ходить или дышать - зачем об этом вспоминать, пока ты моложе 80 и не под колесами сбившего грузовика. А не потому, что Вы (уже) не инженер, но бизнесмен/руководитель/продаван, которому эти инженерские штучки не интересны, а важно лишь навесить на тащащего ослика помимо инженерных задач еще вот это все софтскилловое дерьмо - тащи еще за соседа Петю, начальника Васю и собственника Федю, а мы тебе за это морковку, когда-нибудь, может даже настоящую.
Да, наверно самый
крутойглавныйбогатый инженер - больше про вот это все из Вашей статьи. Да, нынешняя (хотя точнее вчерашняя) айтишечка это уже не (с)только разработчики, а и 100500 тел подтанцовки, и вообще успешный успех, а не интроверт-ботан, кайфующий от решения инженерных задач. НО Вы же формально адресуете это инженерам. А это все-таки зачастую определенный склад ума, и иногда жизненная позиция. Все-таки эталонно это люди которые умеют/хотят/эффективны в решении определенного круга задач - грубо говоря, превращать некий локальный технический хаос в красиво работающий механизм. И не всегда им нужны (профессионально, материально, эмоционально) все эти межличностные игры с нулевой суммой, “угадай что я хочу”, “кто девушку ужинает, тот ее и танцует”, и т.д, и т.п.В общем, пожелание. (глобально) Не надо очень уж откровенно лить воду на мельницу перемалывающую (экономически, методологически, морально) остатки такого архетипа людей. (локально) Быть точнее с заголовком, позиционированием, формулировками. Я все сказал :)
rktkvv Автор
Спасибо за обратную связь по форме.
Я понимаю вашу эмоцию, и по размеру комментария, смею предположить, что она достаточно сильная. Откровенно говоря, я благодарен вам вдвойне, потому что видеть такой отклик на свои мысли воодушевляет продолжать ими делиться.
Мои рассуждения о нетехнических аспектах карьерного пути действительно направлены на тех, кто хочет попробовать пощупать другие архетипы - не только инженерный.
Попробую по-другому проиллюстрировать мысль/идею за статьей.
Представим на месте опытного инженера опытного кузнеца. Он мастер своего дела, его изделия знает и использует вся округа. Но в силу ограничения в пространстве (те места куда кузнец может добраться ) и времени (то количество работы, которые кузнец может сам сделать за 8/10/12/16 часов) объем ценности, созданный таким мастером, тоже ограничен. Физику пока никто не отменял. И вот если кузнец пожелает увеличить зону распространения своей пользы на окружающих, ему придется решать вопрос масштабирования себя. Например, чтобы построить металлургический завод. И вот на пути между одного молота и наковальни до доменных печей и десятков тонн обрабатываемого металла в день, мастеру кузнецу надо будет осваивать и другие направления или, как я назвал это в статье - другие языки.
PeeWeee
Я оценил и попытку причесать тезис под масс-аудиторию, и легкий подъ#б. Хотя и не берусь предсказать их пропорцию и преднамеренность.
Не знаю изучают ли в Германии русскую классическую литературу, но если те, ради кого Вы практикуете свой storytelling, и правда настолько серьезные господа, то могут не оценить Чичиков-стайл общение с отзеркаливанием собеседника :)
rktkvv Автор
Если обратиться к немецкой классике, то у Гёте развитие всегда строится на единстве противоположностей. Как в „Фаусте“, где созидание невозможно без силы, которая „вечно хочет зла и вечно совершает благо“. Внимание к другой точке зрения — это не подстройка, а попытка собрать объемное видение.
Привычный взгляд на вещи удобен и безопасен. А суть статьи как раз в том, чтобы показать иные ракурсы, не исключающие, а дополняющие привычный.