Есть такая старая и немного протухшая дискуссия про 10x программистов. То ли они существуют, то ли это миф стартаперов, то ли это просто мечтания менеджеров про «давайте наймем одного волшебника вместо команды». В презентациях, постах и разговорах эта тема всплывала регулярно, обычно где-то рядом с «нам нужны сильные люди», «у нас маленькая команда» и «дедлайн вчера», а уж на фоне AI-агентов, так и вовсе расцвела опять буйным цветом.
Меня в этой теме всегда смущало, что под 10x часто пытаются запихнуть вообще всё: скорость написания кода, умение чинить баги, знание проекта, способность не делать больно проекту, опыт коммуникации с менеджментом, архитектурный вкус и опытный опыт, готовность сидеть ночью и баф на везение. А потом из этого делают красивую легенду про человека, который работает в десять раз быстрее остальных.
Мечты ПМа, это все же мечты, а в реальной жизни всё скучнее и интереснее одновременно. Я видел людей, которые действительно делали задачи сильно быстрее других. Видел в open-source, видел в игровых проектах, видел на старом коде, видел в маленьких библиотеках. Но почти всегда причина была не в том, что человек родился с коэффициентом x10 и бафом на скорость набирания буковок, а в том, что за его скоростью стоял какой-то накопленный капитал, вроде знания проекта, инструмента, узкой экспертизы или годов ковыряния в похожих задачах.
Человек, который сросся с проектом
Самый очевидный тип «10x» программиста это человек, который просто знает проект лучше всех. Да, и такие бывают. Обычно они верные и седые. В старых кодовых базах или проектах это выглядит почти как магия, заходишь в слаку спросить про баг и через пару минут прилетает ответ в каком файле искать и что чинить. Редко, но бывает. Или говоришь «сломалось поведение окна при таком-то переходе», а человек вспоминает, что там три года назад был костыль под другой экран, потом его обошли флагом, потом кто-то добавил исключение для туториала. И да, скорее всего, он опять прав.
В старых игровых проектах это особенно заметно и игры "с наследием" быстро показывают, что «знать C++» и «знать проект» это вообще две большие разницы. Можно быть отличным программистом, но первый месяц-два просто ходить по минному полю из старых форматов, странных зависимостей, исторических решений и поведения, которое игроки помнят лучше, чем документация.
И тут скорость появляется не из абстрактного скилла, а просто из памяти. Ты уже знаешь, где живет UI, где симуляция, где сохранения, где «лучше не трогать, если не хочешь поломать полуровня». А еще такие люди часто помнят, что эта проверка выглядит лишней, но без неё ломается сценарий. Знают, что pathfinding ведет себя странно не потому, что его писали плохо, а потому что десять лет назад надо было растянуть кадр, но игроки уже привыкли.
Это не про 10x, просто человек несколько лет платил своим временем за возможность сейчас чинить быстрее. Проблема в том, что такого человека нельзя просто нанять с улицы, да и вырастить его внутри проекта тоже проблематично, не все на это идут, хотят или могут. И если он один, то проект одновременно получает суперсилу и огромный bus factor, когда вся магия держится на одном человеке, его памяти и его желании продолжать.
Просто быстрый программист
Есть второй тип эффективности, не писать больше кода, а писать меньше. Можете сказать что это звучит банально, но в геймдеве, особено в геймдеве очень много времени сгорает на попытку построить «правильную» систему до того, как стало понятно, нужна ли она вообще. Начиналось с маленькой фичи, а через неделю у нас уже plugin API, своя сериализация, абстрактная фабрика фабрик и TODO «потом сделать рефактор».
Это болезнь, не знаю как она называется и чем старше проект, тем больше там таких очагов. Особенно их много среди тулов и UI. Кажется, что вот сейчас мы напишем красиво, универсально, на будущее. А потом оказывается, что будущего в таком виде не наступило, но теперь надо поддерживать универсальность.
А быстрый разработчик просто делает меньше. Где-то захардкодит, где-то закостылит, где-то вынесет в конфиг, где-то вообще ничего не сделает. Вот такая профессиональная лень - это уже навык, который плохо проверяется на собеседовании, но очень хорошо виден через месяц другой работы на проекте.
DoItProperlyMan
Если вы часто комитите в open-source, то со временем придходит понимание, что код в проекте это 20% вклада в проект.
Нужно, чтобы проект собирался, чтобы README не врал, чтобы новый человек мог пройти хотя бы первые десять шагов без шаманства. Чтобы pull request можно было ревьюить, а не гадать, что автор хотел сказать. Чтобы issues не превращались в болото из «у меня не работает» без версии компилятора, ОС и логов.
Вот тут и появляется другой тип «10x» человека. Он может не писать больше всех строк кода, но он умеет разбирать хаос. Умеет объяснить, куда положить изменение. Умеет сказать «это не сюда». Умеет порезать большую задачу на маленькие. Умеет сделать так, чтобы следующий человек не потратил вечер на сборку.
Такой человек часто не попадает в мифологию про 10x, потому что вообще не выглядит как герой, который за ночь написал новую систему. Зато он выравнивает дорогу, по которой потом бегут остальные и без него они будут "героически" спотыкаться каждые десять метров.
Узкая экспертиза
Иногда узкая специализация реально дает 10х, например, когда у человека есть редкое знание, часто это пересекается первым пунктом. Старые кодовые базы, свои форматы данных, особенности рендеринга, баги UI-библиотеки, странности системы сборки, платформенные баги и тд и тп. Всё это области, где человек с опытом может за день сделать то, на что другой потратит неделю, а то и больше, просто чтобы понять, с какой стороны смотреть.
Если ты уже умеешь читать старые форматы, понимаешь, как устроены данные, и не пугаешься кода из начала двухтысячных, то ты уже стартуешь не с нуля. Ты уже знаешь, что игра может быть логичной внутри своей странности, и что баг иногда является исторической фичей. А еще что «улучшить» не всегда значит сделать лучше и просто меньше времени тратишь на неизвестные неизвестные. И не потому что всё знаешь, а потому что быстрее понимаешь, где надо искать.
Экспертиза - это знания, помноженные на память, помноженные на насмотренность и понимание предметной области. Сюда попадает и C++, и архитектура, и знание конкретного проекта, и понимание игровых систем. И часто экспертизой человек вытаскивает баг быстрее чем знанием. Два программиста с одинаковым опытом, но разной экспертизой, могут прийти к разным результатам просто потому, что работали над разными проектами.
Миф про фокус
Есть популярная мысль, что сильные программисты просто лучше фокусируются на важном. Правды здесь, как обычно, половина. Да, умение выбрать важную задачу тоже ценно, но кто-то же должен делать и неважные задачи. Чинить сборку, например, или обновлять зависимости. Разбирать мелкие баги. Писать примеры. Отвечать на вопросы. Чистить мусор. Приводить названия к одному виду. Вообщем делать скучную работу, без которой проект тоже не будет выглядеть завершенным.
Проблема в том, что такой труд плохо продаётся как «10x», а еще он не выглядит героически, но для игрока в целом пофиг насколько героично и сфоркусированно вы закрыли две последние таски, именно такие мелочи часто отделяют живой проект от «ну, прикольно, но пользоваться больно».
Наверное, 10x всё-таки существуют, но не так как мы хотим
Я не думаю, что 10x программист это человек, который в любой проект заходит и сразу начинает выдавать в десять раз больше пользы. Так бывает только в сказках, открытых вакансиях и мотивационных презентациях. Но я вполне верю в людей, которые становятся 10x в каком-то контексте. В конкретной кодовой базе или предметной области, в конкретной команде или отдельном типе задач. В проекте, который они излазили руками, глазами и пятой точкой.
К сожалению за этим стоит время: годы опыта, неудачные решения, переписанные системы, заброшенные ветки, ночные баги, странные пользователи, сломанные сборки и понимание, что иногда лучший код - тот, который ты не написал. Так что если хочется искать «10x», я бы искал не волшебников, а людей, которые умеют три вещи: быстро понимать контекст, правильно выбирать масштаб решения и оставлять после себя проект в состоянии, куда будет нестыдно вернуться.
Это менее красиво, чем миф про суперпрограммиста. Зато гораздо ближе к тому, как реально живут большие проекты, да и вообще любые проекты, которые пережили год разработки.
Комментарии (53)
AndruxaBS
13.05.2026 19:18Ой ужас какой. Как надоели в вакансии поиски каких то мифических фуллстак специалистов содержащих в себе 2-5 профилей, но почему то совсем не за мифическую зарплату.
alexfadeev123
13.05.2026 19:18На счёт x10 неизвестно, но x/10 то точно существуют!
Brazil
13.05.2026 19:18Статья неявно вводит в заблуждение.
Кажется что сравнивается средний программист и лучший.
А в первоисточнике сравнивались худшие и лучшие.Если сравнивать со средними, то логично полагаться на область деятельности людей где такие сравнения основа всего - спорт.
В спорте по VO₂max средние от лучших отличаются в два раза, по скорости бега где-то 2 раза.
Поэтому я бы принял цифру 2X относительно среднего программиста.
А относительно худшего взял бы ∞X , поскольку они вообще не выполняют поставленную задачу.
dalerank Автор
13.05.2026 19:18Он безусловно человек уважаемый, но нет, это не первоисточник. Но за ссылку спасибо, прочитал с удовольствием.
vlsnake
13.05.2026 19:1810х программисты существуют - погуглите, например, "Fabrice Bellard" (и не только софта, а и железа "Jim Keller"), другое дело как система, где основа "прибыль" либо уничтожает таких, либо заставляет плясать под дудку денег.
alexanderniki
13.05.2026 19:18Из любого правила существуют исключения. Именно поэтому они называются "исключения", а не "правила" или "нормы". Опираться в рассуждениях на краевые исключительные случаи - очень большая ошибка.
То, что на планете существует пара сотен (имеентся ввиду - исчезающе мало, а не точная цифра) таких вот Фабрисов, не позволяет нам говорить о существовании 10x в качестве статистически или практически значимого факта.
lsarkisyan2000
13.05.2026 19:18подумал что x10 программист - который юзает подписку нейронки за 200 баксов)
Arhammon
13.05.2026 19:18Самый часты тип 10х сотрудника(не только программиста), это тот на которого работает команда или хотя бы 1 помощник который занимается всякой фигнёй пока 10х черипикает на 10х. В принципе работает в системе пахарь-лодырь, со середняками уже хуже работает - они уже не очень любят стахановцев...
Akon32
13.05.2026 19:18Это называется "начальник", а не сотрудник. Там и 1000х легко, если в подчинении 5-10 тыс. человек.
Типичное масштабирование. Хороший программист программирует 2-3х быстрее (редко эти 10х), но совсем маловероятно - 20х. А 3 команды по 10 человек - вполне могут. А если хорошие программисты, возможно, и 1 команды (10 человек) хватит на 20х. Аналогично с 100х, 1000х - людей нужно всё больше, и относительные затраты на поддержку этой системы всё больше (на каком-то этапе масштабирование будет уже совсем неэффективно).
rukhi7
13.05.2026 19:18Хороший программист программирует 2-3х быстрее (редко эти 10х), но совсем маловероятно - 20х.
осталось выяснить какой процент рабочего времени у программиста занимает собственно программирование, то есть написание программ, а не разбор-написание конфигураций, изучение документации, поиск-выяснение-исправление требований, ожидания мержей коллег, ...
Akon32
13.05.2026 19:18Вряд ли люди, кто подметил эти "10х", разделяли программирование и прочую рутину, так что, полагаю, эти 10х распространяются на весь процесс разработки. Но, конечно, остальные части должны для этого работать с соответствующей скоростью, иначе тормозящим звеном будет что-то другое.
Rorick
13.05.2026 19:18Поскольку это, предположительно, миф, то каждый распространяет его на то, во что ему хочется верить. Желательно, на всё. О чём, собственно, в начале статьи и написано. Я искать пруфы сейчас не возьмусь, также могу и вспоминать не совсем верно, но для меня один из первых отчётов по 10x был из статьи Джоэля Спольски. Там он ссылался на исследование, которое сравнивало программистов на изолированных задачах, которые, наверное, были относительно разнообразны, но всё же вряд ли покрывали всё многообразие реальных задач. В общем-то, “производительность” разработчиков уже лет 50 не могут придумать как измерить, поэтому очевидно, что там измеряли по какой-то искусственной метрике.
Но интересно, что это исследование повторяли. Только немного по другому. Взяли ту же метрику, но несколько наборов задач и провели несколько измерений. Оказалось, что эффект 10x не сохраняется. В одном контексте Вася был 10х, а в другом 5x, а в третьем вообще 1х. Более того, если эксперимент сильно размазывать во времени, то даже в одном контексте метрика плавала довольно сильно.
Собственно, эта статья, как мне кажется, примерно о том же. Прошу прощения за отсутствие пруфов, но сейчас их искать не имею возможности и желания. Также понимаю, что многие со мной не согласятся независимо от наличия или отсутствия пруфов.
Думаю, тут также есть сильный психологический момент, зависящий от воззрений, эффекта утёнка, крепости и адекватности самооценки и прочего. Кто-то себя считает 10x, кто-то просто в это верит и стремится. Я же часто испытываю что-то вроде эффекта самозванца, поэтому ищу обоснование, почему это нормально, что я, как мне кажется, не 10х)
Akon32
13.05.2026 19:18Где-то выше я видел ссылку на статью со ссылками на эти исследования. Сам я, кажется, про 10х у Брукса читал. Личный опыт тоже подтверждает, пусть не строго 10х, но в пределах порядка.
Arhammon
13.05.2026 19:18Это называется "начальник", а не сотрудник.
В какой-то мере и неформальный начальник, возможно даже с реальной властью выше формального начальника. Но я всё равно про человека непосредственно работающего. Как только вы его засунете в другую среду где не удастся продавить себе подмастерьев, производительность будет 1х, а то и меньше...
Akon32
13.05.2026 19:18Как только вы его засунете в другую среду где не удастся продавить себе подмастерьев, производительность будет 1х, а то и меньше...
Естественно. Люди потому и объединяются в иерархии, что производительность одного человека обычно средняя.
На подмастерье очень удобно спихивать мелкие баги и неприоритетные фичи: так мастер может пилить важное без существенных отвлечений. Без этого даже небольшой проект может погрязнуть в мелких багах и фичреквестах - когда такое прилетает (а это прилетает, если у проекта есть пользователи), единственный программист вынужден бросать текущую фичу и что-то другое делать. В таком режиме производительность одного человека хорошо если 0.3х (а скорее 0.05х, баги начинают занимать почти всё время). О подобной схеме работы ещё Брукс писал.
Arhammon
13.05.2026 19:18Для меня 10х - это чисто про ситуацию формально равных, а разделение обязанностей и когда сеньёр продуктивнее джуна это и так нормально и ни у кого вопросов не вызывает...
hren_sobachiy
13.05.2026 19:18TL;DR: Чтобы корова давала больше молока, корову надо больше доить и меньше кормить.
AndreyDmitriev
13.05.2026 19:18В общем это не то чтобы миф, но, скажем так, зависит от обстоятельств.
Вот реальный пример. Компания производит весьма специфические железки. В какой-то момент в одной заснеженной стране за океаном заказчик заказывает железку и на основе функционала существующего ПО формулирует шестнадцать дополнительных требований. В это же время в головной корпорации менеджмент решает, что у нас как-то многовато "легаси" решений, и не запустить ли нам супер-пупер энтерпрайз "платформу", чтобы заменить зоопарк технологий. А тут вот хороший пилотный проект - и доп требования, и время вроде есть, — да мы просто их походу реализуем. Заказчик заказывает, там срок прописывается — ровно пятьдесят пять недель до запуска. В одном ганзейском городе делается железка, а в одной жаркой стране нанимается команда программистов писать ПО, "заморозив" разработку существующего легаси. Я по коммитам смотрел — одиннадцать человек. Долго ли сказка сказывается — через год железку мы со своей стороны поставили, и тут внезапно выясняется, что программа даже и близко не готова (хотя мне уже в начале было всё понятно из общения с архитектором и UX дизайнером). Менеджер приходит к мне и осторожно интересуется, сколько мне надо времени, чтобы добавить эти требования в легаси программу. Я прикинул, что три недели в оффлайне (офисе) мне хватит и три у заказчика на месте (у меня почти двадцать лет опыта за плечами, так что сроки я обычно не профукиваю). В общем я справился, и когда я летел обратно, то вслед мне летело благодарственное письмо (я там чутка перевыполнил план и добавил пару фишек "от себя"). Довольный заказчик купил апгрейд, а потом заказал ещё одну машину. Все три работают до сих пор, кстати. Ну а на разборе полётов я ехидно заметил, что команда-то угрохала 11х55 > 600 человеконедель, а я справился за шесть "под ключ". Это значит — аккурат 1:100. На самом деле пропорция ещё больше, потому что я был сам себе архитектором, разработчиком и тестировщиком, потом ещё доки написал. Вот так. Не то чтобы я семи пядей во лбу, но просто опыт и реалистично-прагматичный подход. Но очевидный минус, что если я уволюсь, а заказчику потребуются изменения (прогресс на месте не стоит), то это может стать проблемой.
hren_sobachiy
13.05.2026 19:18Не то чтобы я семи пядей во лбу, но просто опыт и реалистично-прагматичный подход.
Извините, нет у вас опыта. Люди деньги пилили, зарплаты получали, жизнь свою обустраивали. И вот пришли вы, и что? Заказчик сэкономил и купил себе новую Ламборджини.
Вам-то хоть что-нибудь значимое перепало? Работа дураков любит. Стараться можно только в своём бизнесе, но не в найме.
AndreyDmitriev
13.05.2026 19:18Вам-то хоть что-нибудь значимое перепало?
" Элементарно Ватсон!"
"— Как несправедливо распределился выигрыш! — заметил я. — Все в этом деле сделано вами. Но жену получил я. А слава вся достанется Джонсу. Что же остается вам? — Мне? — сказал Холмс. — А мне — ...
На самом деле, как бы это пафосно ни звучало, я очень люблю свою работу, особенно когда математики побольше, она для меня фактически как хобби, которое к тому же оплачивается значительно выше рынка, я летаю в командировки бизнес-классом, видел при этом почти весь мир, и в общем не жалуюсь совершенно... Заказчики, кстати, не всегда "экономят", так как один час моей работы на выезде стоит ему что-то от двухсот до трёхсот евро, плюс накладные расходы — отель, перелёт и т.д.
hren_sobachiy
13.05.2026 19:18а самом деле, как бы это пафосно ни звучало, я очень люблю свою работу, особенно когда математики побольше, она для меня фактически как хобби,
Ну вот займитесь опенсорсом, если свой бизнес не канает. Хотя опенсорс тоже штука спорная.
А потом люди удивляются а чего это благосостояние миллиардеров растёт в геометрической прогрессии. Вот благодаря таким стахановцам и растёт. А ведь эти деньги могли бы достаться простым людям.
Заказчики, кстати, не всегда "экономят", так как один час моей работы на выезде стоит ему что-то от двухсот до трёхсот евро, плюс накладные расходы — отель, перелёт и т.д.
Для них это сущие копейки по сравнению с тем какие суммы они осваивают и присваивают.
Newbilius
13.05.2026 19:18Вы недовольны тем, что человек живёт в своё удовольствие?)
AndreyDmitriev
13.05.2026 19:18благосостояние миллиардеров растёт в геометрической прогрессии. Вот благодаря таким стахановцам и растёт.
С чего вы считаете меня "стахановцем" — непонятно. Я на самом деле довольно ленивый, по понедельникам раньше полудня в офисе не появляюсь.
На самом деле мне очень повезло — я живу в центре Европы, могу сесть на машину и доехать до океана, в Португалию, чего в прошлом году и сделали, или в Норвегию посмотреть на Млечный путь, или там выпить бокал вина у Монблана, я вообще гедонист по жизни. В этом году у меня аж тридцать три рабочих дня отпуск, это почти семь недель... Я люблю хорошо работать и отдыхать тоже. Ну точно надо как-нибудь забацать опус про "четверть века в Германии". И зачем мне заниматься чем-то ещё, если мне просто нравится то, чем я занимаюсь сейчас?
Я вот что скажу. Давным давно, в прошлом веке, я был студентом питерского политеха и подрабатывал лаборантом в лаборатории Физтеха, что был напротив. Однажды мне нужно было сделать усилитель мощности для шагового мотора дифрактометра, там восемь транзисторов да обвязка. Паять я умею, а вот корпус у меня получился не очень, исцарапанный, со щелями, но железка работала. И завлаб, изучив это дело сказал мне: "я не знаю, чем ты будешь заниматься в будущем, может будешь физиком. Может кем ещё. Но одно важно — чем бы ты не занимался, ты должен делать это с любовью, чтобы результат твоего труда было приятно взять в руки и покрутить со всех сторон и восхититься тем, как же это офигенно сделано. Иди и переделай". С этим словами он выкинул моё поделие в мусорное ведро. Я запомнил, и много лет руководствуюсь этими словами, в разработке ПО в том числе, я стараюсь делать это для людей, чтобы им было удобно, и так, как считаю нужным, а на мнение менеджеров мне обычно пофиг.
Сейчас принято хейтить всё и вся. Не нравится место работы и род занятий — меняй, в чём проблема? Не нравится страна? Меняй и её (это чуть сложнее, но всё возможно). Возможно и меня жизнь заставит выйти из "зоны комфорта", но пока всё норм.
sbw
13.05.2026 19:18Ну точно надо как-нибудь забацать опус про "четверть века в Германии"
Напишите, очень интересно будет почитать!
rhiamonlatin
13.05.2026 19:18Вам-то хоть что-нибудь значимое перепало?
Разумеется , как подметил автор комментария выше
летело благодарственное письмо
Ведь бизнес обычно считает, что если человек работает за зарплату по часам, прописаны по контракту, то какими еще могут быть методы мотивации. Разве что забыли медальку дать, грамоту и фото на стену как лучший работник месяца.
Надеюсь конечно что автора существенно отблагодарили за такой объем работы, но это скорее будет исключение из общей практики , чем норма.
AndreyDmitriev
13.05.2026 19:18Надеюсь конечно что автора существенно отблагодарили за такой объем работы, но это скорее будет исключение из общей практики , чем норма.
В конкретном данном случае, поскольку проект был профукан менеджементом и меня использовали как "скорую помощь", то давать награды — значит подчеркнуть этот про... в общем спустили на тормозах — работает и хорошо. Ну а мне достался один вкусный ужин с заказчиком, плюс я наконец-то увидел Ниагарский водопад, ну и там по мелочи по окрестностям. Большого объёма там особо не было, я просто знал "куда стукнуть". Кроме того у заказчика программировать в какой-то мере проще, потому что ему просто раскатываешь релиз, и оператор сразу говорит, что ему нравится, а что нет, это правишь и раскатываешь снова, так итеративно и доводится, потом дотошно тестируется. Ну разве что шумновато в литейном цеху бывает. Премии дают, конечно, и неплохие, но в основном за успешно сданные проекты без аврала. А так — работа как работа, АСУТП да машинное зрение, чутка математики да физики до кучи.
Warperus
13.05.2026 19:18Лукавство это, легаси переписать - это совсем другой расчёт.
Иногда, конечно, старая система в принципе не позволит добавить новые фичи, но коли уж позволяет, экономия космическая.
На моей практике полные переделки экономически не оправдывались никогда, всегда было волевое решение "поддержка вендора умрёт" или "сумма критических багов => хватит это терпеть"
hren_sobachiy
13.05.2026 19:18На моей практике полные переделки экономически не оправдывались никогда
Они и не должны. Айти - модно-молодёжный центр по выдаче пособий по безработице. Дешевле конечно сразу деньгами выдавать, но от безделья люди начнут пускаться во всякое опасное непотребство. Поэтому им нужен "детский сад" для взрослых. Bullshit job. Беда только если кто-то не понимает этого замысла и начинает реальный бизнес в айти строить. Вот тут и оказывается что без 10x сотрудника, без бесконечного техдолга, без "давай-давай это нужно уже вчера" этот бизнес нерентабелен.
AndreyDmitriev
13.05.2026 19:18На моей практике полные переделки экономически не оправдывались никогда,
Во, золотые слова! Я многим советовал читать "Мифический человекомесяц" Фредерика Брукса, в котором прекрасная история, да все считают себя умными и так. Менеджеры уж точно, они не видят, что проект профуканный на полгода сначала был профукан на один день. И так далее.
Доля лукавства с легаси, конечно есть, тем более, что там был не простой легаси, а тот, к которому я шёл шесть лет, тщательно выверяя архитектуру, и не с первой попытки. Просто много лет назад, я поставил себе довольно амбициозную задачу сделать архитектуру, которая не устареет в принципе, при этом не имея детальной информации о будущих разработках, основанных на ней. Я решил, что проекты начинают буксовать из-за зависимостей и постоянно растущей сложности, когда они набирают критическую массу. Так что выкристаллизовалась система — ядро, несущия лишь базовый фукционал, а всё "мясо" на неё навешивается в виде модулей-плагинов. Микросервисно-плагинным архитектурам сто лет в обед, но мне удалось сделать интерфейсы так, что модули все совместимы друг с другом, как кубики Лего, включая UI. Это же было ориентировано и на командную работу, когда несколько человек могло работать над несколькими модулями параллельно, сокращая время разработки. Ну и при новых разработках ненужный функционал просто сбрасывается и общую сложность удаётся держать на контролируемом уровне, даже когда количество систем и модулей исчисляется сотнями.
ws233
13.05.2026 19:18Во всех этих дискуссиях о х10-продуктивности почему-то всегда рассматриваются только конкретные
ездовые кониличности с конкретными навыками. При этом обходятся стороной реальные вопросы, влияющие на продуктивность и эффективность. Например:-
Синергия или эмерджентность – система легко может быть сильно производительнее или эффективнее, чем сумма результатов или эффективностей отдельных её частей. В случае с программистами это означает, что 10 хорошо сплоченных и организованных разработчиков могут перформить сильно больше и эффективнее, чем сумма их результатов по отдельности. Я лично наблюдаю этот эффект.
В общем, нужно х10 искать не у отдельного программиста по сравнению с коллегой за соседним столом, а у целых коллективов по сравнению с аналогичными коллективами в конкурирующих подразделениях. В таком случае картинка становится прям явной, отчетливой и не вызывающей сомнений.
Второй момент: производительность и эффективность – 2 разные вещи. Высокую производительность получить просто, а вот высокую эффективность, которая потом будет синергично с положительной обратной связью повышать производительность - сильно сложнее. А сделать это еще и в долгосрочную перспективу – вообще задача со звездочкой даже для очень опытного менеджера. А это снова уже про организацию и процессы, а не про конкретные навыки конкретного индивида.
Самый интересный вывод из этого всего примерно такой: х10 работают не в вакууме, а у хороших руководителей, которые понимают, как строить эффективные и продуктивные системы не только в краткосрок, но и в долгосрок. Хотите стать х10 и понять, как это? – ищите высокоэффективные системы и их руководителей, но вряд ли Вам там будут много платить, но это уже совершенно другой вопрос – на целый цикл статей, а то и на курс в университете :)
Akon32
13.05.2026 19:18В случае с программистами это означает, что 10 хорошо сплоченных и организованных разработчиков могут перформить сильно больше и эффективнее, чем сумма их результатов по отдельности. Я лично наблюдаю этот эффект.
Хм, а я лично наблюдал, как синергетического эффекта ждали, ждали, и не дождались. Этот эффект может быть, а может не быть, но при определённых навыках руководства в отчётах все хорошо, владельцы продолжают ждать эффекта.
строить эффективные и продуктивные системы не только в краткосрок, но и в долгосрок.
Именно эти слова и произносились, когда результатов не было несколько лет.
Я больше верю в типичные x6 в команде из 10 типичных человек, и то, потому что двое - тестировщики, один - менеджер, ещё один - скрам-мастер и т.п. Они код не пишут, но выполняют координацию, обеспечение качества и т.п. Чтобы один человек тянул x6 - уже очень долго такого искать надо. Чтобы 2-3 хороших соорудника тянули x6 - чуть более реально.
-
wert_lex
13.05.2026 19:18Я видел один раз программиста, которого, наверное, можно назвать 10x. И, скажу я вам, это большая-большая проблема.
прежде всего он выбивается из всех командных процессов. Пока команда обсуждает чего мы со всем этим делать будем - он уже что-то сделал. А если уже сделал - то и думать уже дальше не хочется (а сделал не всегда то, что на самом деле надо было). Плюс у команды теряется мотивация вообще включать голову - там же вон есть этот
менеджмент при должном объяснении понимает ситуацию, но со временем в их глазах возникает перекос - вот 10x это норма (посмотрите, я говорю - а он сразу делает), а остальные что-то какие-то совсем медленные
у менеджмента возникает ложное ощущение, что вообще все (включая не зону ответственности 10x) можно вот за пару часиков закодить. Из-за этого страдает планирование и ожидание
Пока для себя я выработал такой план работы с такими ребятами (мы подразумеваем, что это действительно ~10x):
нужно выделить прям специального менеджера по работе c этим человеком
в его задачи входит: кормить, поить, выдавать задачи из спец. пула, ассистировать в коммуникациях, эмпатировать данному человеку. Это действительно "курица, которая несет золотые яйца", и не нужно это ломать. Нужно это усиливать
но при этом важно сохранять общий коммуникационный фон: не запирая человека в клетке с одной стороны, с другой стороны не создавая негативного влияния на остальную часть команды, и с третьей стороны - не дать поймать звезду
Короч сложно.
Rub_paul
13.05.2026 19:18Менеджер прав: такого человека нельзя сажать в общий флоу. Ему нужно выделять автономные куски системы (R&D, прототипы, сложные алгоритмы), где он не будет блочить остальных и ломать процессы
akod67
13.05.2026 19:18А потом из этого делают красивую легенду про человека, который работает в десять раз быстрее остальных.
То ли случайное, то ли намеренное искажение контекста. Тут нет сравнения с другими. Есть сравнение с сами собой без ИИ инструментария. И это более, чем реально, когда ты начинаешь быть способен деливерить по несколько проектов параллельно, попутно причёсывая техдолг и плодя документацию. И нет, без ИИ так быстро деливерить совершенно невозможно.
00Kirill00
13.05.2026 19:18Статья найс, но все забывают главное: бизнесу не нужны 10х программисты, бизнесу нужна предсказуемость. Лучше иметь 10 средних разработчиков, выдающих релизы по расписанию, чем одного гения, который сегодня перепишет ядро, а завтра уйдет в запой или в горы
BlackSCORPION
13.05.2026 19:18постоянно X10 точно не существует, но эпизодически, когда человек увлечен, гипер сфокусирован, 18 часов в сутки думает только о задаче, ни о чем больше, ему снятся сны о решениях задачи, он ест с ноутбуком а в уборной ресерчит с чатжпт, тогда да.
Но у таких творческих личностей трудности со стабильностью, они либо в режиме безумного гения, либо им не интересно и они бьют рекорды в прокрастинации в поиске вдохновения. Они движимы новизной и интересом, от рутины они выпадают в осадок и 0.01х производительности.
Такие люди отличные генераторы идей, но они не работают без людей инженеров, которые способны методично и структурно достигать поставленных задач.
ИМХО ключ не в поиске мифических программистов терминаторов, а в построении грамотных гармоничных комманд, где каждый тип человека добровольно желает выдавать свой максимум, где сильные стороны одних дополняют слабые стороны других, и в контексте такой комманды 1+1 = 10 а не 2 или 0.1
Rub_paul
13.05.2026 19:18Знаем таких 10х, вся их эффективность держится на том что они отказываются писать документацию и наотрез игнорируют процессы согласования. А когда они увольняются, проект просто встает колом, потому что никто не понимает их спагетти-код
Jijiki
13.05.2026 19:18интересно, что Итальянский футбол Кристиана Киву хорошо ложится на кодинг, когда смотришь трансляцию, например Интер против Лацио, тут видно и владение профессией и владение мяча, и импровизацию, и молниесное принятие решения всей командой на поле, это классный философский взгляд на футболл, через призму кодинга, и почему-то после таких инсайтов, понимаешь что все эти желтушные заголовки типо нам не нужны такие или не такие кодеры ), вы определитесь кто вам нужен и растите их, извините обьективно человек может делать уникально только 1 задачу )
а тут просматривается и Раст, и эффективнее определить требования системы, слаженная работа лучше гения, если алгоритм плохо работает ему надо выдать инструкции и отладить обьективно, и нету тут никаких обид это просто нормально, вы же не выбрасываете ПК если у вас предиктор перехода ошибся на 1 миллиард инструкций...Скрытый текст
Аналогия между футбольной тактикой Кристиана Киву (особенно его работы с молодежью «Интера») и системным программированием на Rust идеально передает суть современной разработки.
Футбол как архитектура кода
Rust и владение мячом: Модель владения (Ownership) в Rust гарантирует, что мяч (ресурс) в один момент времени принадлежит только одному игроку. Передача паса — это строгое перемещение (Move) или заимствование (Borrowing) без риска конфликтов.
Слаженная работа против гениев: Архитектура системы важнее ярких одиночек. Если команда работает как единый компилятор, она исключает утечки памяти и провалы в обороне.
Молниеносный runtime: Тактическая импровизация на поле — это не хаос, а выполнение оптимизированного машинного кода, где каждый шаг просчитан на этапе компиляции (тренировок).
Размытые требования: Поиск «универсальных гениев» — системная ошибка скорее всего. Зачем искать фулстек-оркестр, вместо того чтобы четко описать спецификацию (Интерфейс) для конкретной позиции.
Выращивание кадров: Топовые клубы и сильные ИТ-отделы создают инкубаторы. Проще обучить джуниора под свои стандарты кодирования, чем переучивать капризного «звездного» игрока.
Фокус на одной задаче: Уникальность человека раскрывается в узкой специализации. Архитектор пишет ядро, спринтер (вингер) закрывает край. Попытка заставить одного делать все ломает общую производительность.
Отладка вместо деструкции
Логирование ошибок: Ошибка предсказателя переходов в процессоре или позиционная ошибка защитника — это не повод менять железо или увольнять человека. Это повод для рефакторинга.
Изоляция сбоев: В хорошей системе сбой одного элемента (Fault Tolerance) перехватывается. Команда страхует ошибившегося, а компилятор подсвечивает проблемное место.
Проектирование инструкций: Если алгоритм дает сбой, ему меняют вводные данные и оптимизируют циклы. Эмоции в этом процессе лишь мешают чистой логике.
feelamee
13.05.2026 19:18А быстрый разработчик просто делает меньше. Где-то захардкодит, где-то закостылит, где-то вынесет в конфиг, где-то вообще ничего не сделает. Вот такая профессиональная лень - это уже навык, который плохо проверяется на собеседовании, но очень хорошо виден через месяц другой работы на проекте.
знаем мы эту профессиональную лень. Через 5 лет этих разработчиков уже и след простыл, а тебе разгребать.
Важное уточнение - вместе с навыком профессиональной лени идет навык профессиональная бдительность. Важно не проморгать момент, когда эта “упрощенная” модель, которая работала тогда, начинает расти во что-то серьезное, чтобы успеть переписать еще пока небольшую систему в что-то сносное и расширяемое, чтобы не получился монстр…
stmirage
Я работаю в финтехе и работаю достаточно давно. У меня вызывает крайнюю обеспокоенность миф про разработку 10х. Начиная от стагнации найма и уровня заработных плат и заканчивая нереальными ожиданиями бизнеса.
Проблема в том, что за все годы работы программист никогда не был бутылочным горлышком от которого можно требовать 10х. За весь многолетний опыт я ни разу не сталкивался с тем, что ускорение моей работы в n раз принесло бы какое-то весомое ускорение. я был на ролях в разные периоды жизни - developer, lead, аналитик требований, QA и QA Automation и Product Owner.
Управление проектом в финтехе похоже на управление огромным кораблем с невероятным уровнем инерциии. Допустим мы заменим команду из трех человек одним. Но программист и QA как ни странно не самые большие роли в рамках внедрения одного изменения.
Сможем ли мы протестировать, вообще, эту фичу учитывая огромное количество legacy интеграций?
Готовы ли смежные команды для внедрения нашей фичи?
Готовы ли внешние интеграции к нашим изменениям?
Нет ли пропущенных кусков в наших планах, например, связанных с безопасностью транзакций?
Готовы ли мы деплоиться в период повышенного риска? Например, в финтехе, есть замечательное время новогодних праздников, когда сбой в системе стоит бизнесу очень дорого.
Сможем ли мы отказаться от этого решения, если оно окажется неудачным?
Сколько сил мы готовы потратить на дополнительный раунд нагрузочного тестирования?
Наше решения отвечает всем требованиям безопасности, если сейчас ресурс по безопасникам, или они заняты?
Ни один из этих вопросов занимающих время до развертывания не относится к коду. 10х производительности, это не такой существенный плюс, как может показаться.
Когда мне говорят, что эффективность программиста повысилась потому что Клод пишет ему модули по 10к строк в течение минут, я прихожу в ужас. 1000 строк это уже серьезная когнитивная нагрузка при проведении код ревью. Вообще, файл на 300 строк чистого кода без учетка верстки, юнит тестов, конфигов и прочих файлов деплоя вполне может быть испытанием в большом проекте.
Проблема не в том, что 10х производительность это миф. Проблема в том, что 10х производительность это лукавый маркетинговый лозунг, несущий больше рисков, чем пользы. 10х производительность требует 50х больше способности переваривать этот буст.
PS обожаю ваши статьи. про память на консолях ваще пушка
dalerank Автор
Спасибо.
imanushin
Я с Вами не соглашусь, так как я неоднократно наблюдал именно то, что описывается в статье.
Собственно, 10х программист именно что поможет:
Да - именно в зависимости от квалификации и меняется ответ на этот вопрос.
Более квалифицированный человек (а 10х производительность ведь очень хорошо коррелирует с повышенной скоростью набора опыта) как раз сможет внедрить намного больше функциональности используя существующие возможности, а не будет просить всех немного помочь и подвинуться.
Обратную совместимость непросто поддерживать - опять-таки, более грамотный сотрудник будет в плюсе.
И опять-таки, тут такие люди найдут проблемы быстрее, чем стандартный/классический работник.
Отличный пример - 10х сотрудник именно что сможет сделать blue-green деплоймент, так что даже такого вопроса не возникнет. Собственно, а какие крупные фирмы так не делают с сайтом?
Вот это проблема - если потом заменить очень сильного на кого-то сильно дешевле, то далее запросто вырастет целая команда, которая будет смотреть годами на решения, оставшиеся от предыдущих, а также потратит несколько неудачных попыток переписать. Вот это нередко можно наблюдать в фирмах.
Пример из жизни - Скайп. Его сделала команда очень высокого уровня, а далее история известна.
Здесь квалификация и грамотная архитектура опять очень сильно помогут.
И что же такого 10х программист может не знать про безопасность? Такие люди, чаще всего, скорее сами расскажут безопасникам, где стоит корректировать подходы.
Другими словами - Вы четко описали именно то, что часто и происходит: условный 10х программист интересуется темой, очень хорошо разбирается в технологиях, имеет прекрасные T-shape навыки и так далее; а на его замену потребуется несколько людей попроще, безопасник, тестировщик, продукт менеджер, программ менеджер, скрам мастер, потом еще программисты и так далее.
santjagocorkez
Кожаный обладает лимитом на контекст примерно той же природы, что и LLM. При определённом объеме интеграций объем необходимого контекста начинает превышать физические возможности человека (разве что искать единорогов, которые обычно обладают такой способностью за счёт других, таких как социальная адаптация, способность функционировать без опасности для себя или окружающих за пределами психиатрического круглосуточного ухода и наблюдения, и т.д.)
Ну да, просто запилит интеграцию в смежном проекте вместо владеющей команды. Всего-то ещё один домен освоить. Два пальца (см. выше). Само собой, с тех самых пор он становится владельцем реализации и отвечает за неё лично. У смежников рефакторинг — срочно беги свою интеграцию обновляй. Да, тесты не забудь, да, логическую и бизнесовую связность тоже не продолбай, стоит ли напоминать, что домен смежников надо бы заново изучить, там не просто так рефакторинг случился. Когда? Что за вопрос, вчера, конечно же.
С этим полностью согласен, навык поддерживать обратную совместимость важен безотносительно 1/10х, 1х, 10х.
Если хватит контекстного окна стандартной черепной коробки (см. выше)
Кажется, начинает стойко попахивать «и рыбку съесть, и косточкой не подавиться».
А если не заменить, то 10х завтра поедет с семьей в Крокус и не вернется оттуда. И к тому, что менять придётся уже вынужденно, добавится полное отсутствие штатной передачи экспертизы. Даже не надейтесь найти второго точно такого же 10х, там будут свои тараканы, не факт, что со всеми ними вы готовы будете мириться.
Ага. И рыбку съесть. Проблема в том, что безопасники его пошлют, куда подальше. В самой мягкой форме — просто проигнорируют. А так да, 10х и годовой бюджет международной корпорации посчитает, и переговоры с поставщиками проведет, и датацентр при необходимости построит. А, может, ну их всех в задницу, начиная с CEO и заканчивая уборщицами. Оставим одного 10х. Сократим чрезмерные издержки и задержки коммуникаций до мгновенных, так как внутри одной черепной коробки — это всегда согласованно и мгновенно.
Warperus
Даже 10х - человек, а человек это не оркестр(атор). Он не проведёт ревью своего кода, он не проведёт полное е2е тестирование, он не соберёт все требования и т.д.
То есть, он может даже заниматься всем, но с позиции руководства преступно так безраздельно ему доверять и так неэффективно его использовать (не все области ускоряются).
Плюс человек-оркестр с большей вероятностью выгорает. Лучше его беречь, и применять по назначению с соблюдением баланса.
00Kirill00
В энтерпрайзе 10х разработчик быстро выгорает, потому что его скорость нивелируется скоростью самого медленного отдела в компании)