Міф про 10x-інженера — одне з найбільш хибно зрозумілих уявлень у нашій індустрії. Усі малюють однакову картинку: розробник, який пише вдесятеро більше коду, працює вдесятеро більше годин і знає вдесятеро більше інструментів, ніж будь-хто навколо. Пару років я пропрацював пліч-о-пліч зі справжнім 10x-інженером — і майже нічого з цього не було правдою. Коду вона писала менше за всіх у команді. А правда виявилася куди цікавішою за легенду.

Міф, який усі повторюють

Запитайте будь-кого — і почуєте три однакові визначення, і всі три хибні:

  • Вона пише в 10 разів більше коду.
  • Вона працює в 10 разів більше годин.
  • Вона знає в 10 разів більше мов та інструментів.

Це погляд джуна. Він міряє рух, а не результат. У ньому закладена думка, що цінність інженера — це обсяг виробленого: рядки, години, визубрені фреймворки. На початку кар'єри я й сам вірив у версію цього міфу — і заплатив за це купою вихідних.

Що насправді означає 10x

Справжній 10x — тихий. Виглядає він так:

  • Запобігти проблемі, на полагодження якої пішло б удесятеро більше часу.
  • Спростити рішення, яке всі інші ось-ось перетворили б на over-engineering.
  • Розблокувати трьох колег, які інакше застрягли б на кілька днів.

Її головний внесок — не фічі, які вона побудувала. А фічі, від яких вона відмовила команду. Рішення, які вона спростила до того, як вони перетворилися на двотижневу кролячу нору. 10x був у тому, чому вона запобігла, а не в тому, що зробила — і саме цього в резюме не впишеш.

Двотижнева фіча і двогодинна бібліотека

Ось момент, коли до мене дійшло. Прилетів складний запит на фічу. Один інженер узяв його і зник на два тижні. Повернувся з кастомною реалізацією з нуля — справді вражаючий код, красива архітектура. Уся команда була в захваті. Оплески стоячи.

Вона взяла той самий запит і витратила дві години на research. Знайшла живу, добре підтримувану бібліотеку, яка вже розв'язувала 90% задачі. Тридцять хвилин на інтеграцію. Правка README і один конфіг. Готово.

Дивитися значно менш ефектно. Зате вдесятеро цінніше для продукту.

Бо кастомне рішення не закінчується на змердженому PR. Його треба підтримувати. Оновлювати. Хтось має володіти ним вічно й отримувати виклик о 3 ночі, коли воно зламається. Інтеграції бібліотеки нічого з цього не треба. Один шлях повернув команді час. Інший тихо взяв його в борг.

Цей патерн повторюється в кожній команді

Саме цю картину я спостерігав у кожній команді за десять років. Найгучніший інженер викочує найбільше коду і зриває оплески. Найтихіший запобігає найбільшій кількості інцидентів і отримує... пейджер, який мовчить о 3 ночі.

Перше легко помітити на sprint review. Друге видно лише як інцидент, якого не сталося; як ніч на on-call, якої ніхто не пам'ятає, бо нічого не впало. Вгадайте, кого з двох я хочу бачити у своїй команді.

  • Код, який ти не написав, не зламається.
  • Зустріч, якій ти запобіг одним зрозумілим документом, рятує всім пів дня.
  • Нудна архітектура — це коли про неї ніхто не думає о 3 ночі.

Три зрушення, які реально змінюють справу

Якщо хочете рости в цей бік — справа взагалі не у швидкості друку. Це три зміни в тому, як ви думаєте:

  • Розв'язуйте проблему, а не влаштовуйте виставу з коду. Мета — результат, а не вражаючий diff.
  • Знайте, коли НЕ будувати. Спершу запитайте «а чи треба?», потім «а як?». Найкращий код — той, який так і не був написаний.
  • Підтягуйте колег, а не змагайтеся з ними. Десять хвилин, щоб когось розблокувати, вартують більше за десять годин сольного героїзму — а герої, якщо чесно, стають single point of failure.

Як я тепер міряю цінність

Ось незручна частина. Якщо ви міряєте свою цінність у рядках коду чи відпрацьованих годинах — ви міряєте зовсім не те. І індустрія привчила майже всіх нас робити саме так.

Найкращий код — той, який ти не пишеш. Найкраща зустріч — та, якій запобігло одне зрозуміле повідомлення. Найкраща архітектура — та, про існування якої ти забув, бо вона жодного разу тебе не розбудила. Ось той 10x, про який ніхто не говорить, — він невидимий by design.

Дві години research. Тридцять хвилин на інтеграцію. Удесятеро цінніше за два тижні кастомного коду.

І зустрічне запитання, чесно: хто найвпливовіший інженер, з яким ви працювали, — і що насправді його вирізняло? Б'юся об заклад, справа була не в обсязі коду.