Міф про 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. Тридцять хвилин на інтеграцію. Удесятеро цінніше за два тижні кастомного коду.
І зустрічне запитання, чесно: хто найвпливовіший інженер, з яким ви працювали, — і що насправді його вирізняло? Б'юся об заклад, справа була не в обсязі коду.