Есть такая старая и немного протухшая дискуссия про 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», я бы искал не волшебников, а людей, которые умеют три вещи: быстро понимать контекст, правильно выбирать масштаб решения и оставлять после себя проект в состоянии, куда будет нестыдно вернуться.

Это менее красиво, чем миф про суперпрограммиста. Зато гораздо ближе к тому, как реально живут большие проекты, да и вообще любые проекты, которые пережили год разработки.