Супергерой или миф: как возникло понятие 10х-программист и что за ним стоит
Все, кто так или иначе связан с IT-сферой, знакомы с понятием 10х-программист. Так называют самых крутых и эффективных разработчиков. Термин встречается буквально везде: от кликбейтных статей “Как стать программистом за месяц” до книг уважаемых экспертов вроде Стива Макконнелла или Мартина Фаулера. Даже в сериале "Кремниевая долина" в первых же сериях упоминается, что главный герой – как раз один из тех самых 10х-программистов.
Все статьи по теме ссылаются на некие исследования ученых. Я разобрался, как появились 10х-программисты и что на самом деле стоит за этим термином.
Очередной заказ военных
В 1966 году научная группа из двух сотрудников System Development Corporation Евгения Гранта и Гарольда Сэкмана по заказу армии США сравнивала эффективность работы опытных программистов (тогда еще не придумали Сеньоров) при прямом доступе к компьютеру и работе через оператора.
В те времена для того, чтобы запустить программу, надо было принести ее в вычислительный центр. Помещение, размером с современный дата центр, мог занимать всего один компьютер с единой точкой ввода/вывода. Программисты отдавали свой код в распечатанном виде или на перфокартах оператору и вставали в очередь на его исполнение. Ждать результата иногда приходилось до двух дней.
Альтернативой была новая на тот момент концепция разделения времени вычислительных ресурсов компьютера между несколькими рабочими местами. С помощью телетайпа программист самостоятельно вводил свою программу в компьютер и почти тут же получал результат. Но на все это уходило много накладных расходов: было необходимо более дорогое и сложное оборудование, а на переключение контекста между пользователями требовалось дополнительное машинное время. Критики этой концепции опасались, что программисты будут лениться самостоятельно проверять свой код, часто запускать нерабочие и неэффективные программы и впустую тратить машинное время.
Чтобы узнать, как каждый из этих двух подходов влияет на производительность, ученым поручили провести эксперимент. Для него отобрали 12 человек, которых произвольно разделили на две группы. У каждой было по две задачи.
Лабиринт – надо было написать программу для выхода из представленного в виде таблицы 20х20 лабиринта.
Алгебра – надо было написать программу, которая сможет интерпретировать введенное через телетайп алгебраическое выражение и решить его. Также требовалось обработать ошибки ввода, если они есть.
Прямой доступ к компьютеру |
Непрямой доступ к компьютеру |
|
Группа 1 |
Алгебра (6 человек) |
Лабиринт (6 человек) |
Группа 2 |
Лабиринт (6 человек) |
Алгебра (6 человек) |
Обе задачи группы должны были решить с прямым и непрямым доступом к компьютеру. Чтобы сэмулировать работу через оператора, организаторы эксперимента наняли двух студентов и задали ряд правил. По ним участникам эксперимента можно было:
отдавать код только с 8:00 до 17:00
проинструктировать оператора, что и как вводить
попросить распечатать отладочную информацию
одновременно отдавать в работу не больше 2 программ в час
получить результат через 2 часа, при условии его передачи до 15:00, в ином случае он мог быть готов лишь на следующий день
Для написания кода в эксперименте использовался 60-ти тонный транзисторный компьютер IBM AN/FSQ-32, который изначально создавался для ядерных бункеров. Он поддерживал концепцию разделения времени между пользователями и имел несколько телетайпов для работы. В качестве языка программирования подопытные могли выбрать между JTS (процедурно-ориентированный язык "JOVIAL Time-Sharing") и SCAMP.
На чем держится миф
В ходе эксперимента ученые замерили время, потраченное участниками на написание рабочей программы, и машинное время, потребовавшееся на тестовые запуски. Также они сопоставили размер получившихся программ и скорость их исполнения.
В результате ученые сделали несколько выводов:
При прямом доступе к набору и исполнению кода результат можно получить гораздо быстрее. В основном, из-за отсутствия задержки между вводом кода и получением результатов.
Если позволить программистам самостоятельно запускать программы, то они начинают расходовать в среднем на 30% больше машинного времени.
Ученые также заметили значительный разрыв в производительности программистов. Несмотря высокую квалификацию всех участников эксперимента, разница между лучшими и худшими результатами была очень велика: от 5-тикратной до 28-кратной. При этом, ученые не обнаружили прямой корреляции ни с опытом работы, ни с оценками в стандартных тестах для программистов.
Оценка производительности |
Худший результат |
Лучший результат |
Коэффициент |
Время отладки Алгебры |
170 |
6 |
28 : 1 |
Время отладки Лабиринта |
26 |
1 |
26 : 1 |
Затраченное время CPU Алгебры |
3075 |
370 |
8 : 1 |
Затраченное время CPU Лабиринта |
541 |
50 |
11 : 1 |
Время разработки Лабиринта |
111 |
7 |
16 : 1 |
Время разработки Алгебры |
50 |
2 |
25 : 1 |
Размер программы Алгебра |
6137 |
1050 |
6 : 1 |
Размер программы Лабиринт |
3287 |
651 |
5 : 1 |
Время работы Алгебра |
7,9 |
1,6 |
5 : 1 |
Время работы Лабиринт |
8 |
0,6 |
13 : 1 |
Полученные результаты передали военным, а также опубликовали в журнале IEEE Transactions on human factors in electronics с пометкой, что это первое известное исследование продуктивности программистов. Интересно, что в том же номере вышла статья, критикующая выводы ученых. Ее авторы указывали на ограниченность исследования, а также критиковали его параметры и методы.
Тем не менее, в семидесятых на сделанные в ходе упомянутого эксперимента выводы в книге «Мифический человеко-месяц или Как создаются программные системы» сослался Фредерик Брукс. Он обобщил их:
Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой‑либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)
После выхода книги о существовании 10x-программистов начали говорить как о факте. С тех пор некоторые компании ищут именно таких специалистов, ведь считается, что каждый из них способен один работать за целую команду. Начинающие программисты ищут способы стать “десятикратными” и часто выгорают по пути.
Хотя, если разобраться, за самим понятием не стоит ничего фундаментального.
Комментарии (33)
dkuzminov
17.04.2023 15:06+74Сейчас принято видеть в программистах этаких суперменов, джеймсбондов, которые умеют стрелять из любого вида оружия, управлять любым видом транспорта, успешны в любом виде спорта и т.д. По представлению публики (и многих менеджеров) они должны эффективно разбираться в любом говнокоде, иметь шестое чувство и уметь угадывать мысли коллег. Короче, очень удобная концепция, но супермены бывают только в кино.
С моей точки зрения настоящий опытный 10x-программист должен быть похож не на киношного Джеймса Бонда, а на несколько иной тип супермена. Помните Мистера Вульфа из "Криминального чтива"? Человека, который решает проблемы? Когда два долболома бандюка с признаками нарциссизма повыделывались перед своими жертвами, что закончилось серьезными практическими проблемами, требующими быстрого решения, к ним был послан... Профессионал. Без паники, но при этом ценя дорогое время, он заставил всех сделать элементарные вещи (типа смыть следы крови), не давая ситуации усугубиться. При этом по большей части попивая кофеек и добродушно беседуя с хозяином дома.
10x-программисты не должны уметь делать супервещи в сверхтяжелых условиях. Они просто должны не запускать ситуацию до того, чтобы потом не нужно было искать существующего только в кино Крепкого Орешка.
uvelichitel
17.04.2023 15:06+1просто должны не запускать ситуацию
не поспоришь)
10x-программисты не должны уметь делать супервещи в сверхтяжелых условиях.
и уж, по крайней мере, не должны за такое браться)
Но, ведь программирование не только ремесло и профессия, но и творчество. Так, сегодня, принято считать) А значит, можно говорить о талантливых программистах. Способных решить задачу, как ещё не делали, а завтра будут все.
dkuzminov
17.04.2023 15:06и уж, по крайней мере, не должны за такое браться)
Это типа инженерного айкидо: вместо того, чтобы геройски проворачивать тонны говнокода, уметь избегать наобходимости марать руки, своевременно ликвидируя технический долг.
Но, ведь программирование не только ремесло и профессия, но и творчество.
Программирование -- это подраздел инженерии, а инженерия -- управление сложностью. То есть умение сделать простыми сложные вещи, а также наоборот: найти непроторенную дорогу там, где все изведано. Одно НО: надо четко разделять, когда мы создаем, а когда исследуем. И, если вдруг приспичило позаниматься творчеством, ни одну его строчку кода не отдавать в продакшн, а либо в корзину, либо оставить для референса. В продакшн ТОЛЬКО с нуля и без излишнего неуемного творчества.
Wesha
17.04.2023 15:06+4Это типа инженерного айкидо: вместо того, чтобы геройски проворачивать тонны говнокода, уметь избегать наобходимости марать руки, своевременно ликвидируя технический долг.
Инженерное дзюдо: не следует бороться с говнокодом, нужно направить его в нужное русло, чтобы он сам рухнул :)
SanyaZ7
17.04.2023 15:06Статья всё-таки не про покрытие кода тестами, а про неприменимость компенсаторного мышления.
MetaMurza
17.04.2023 15:06+6Есть просто такой тип менеджмента, когда из поиска кандидата устраивают олимпиаду (используется "модель приза"), чтобы выявить так называемых Nх программистов. По-сути людей, которые загоняют себя в крысиные бега. Далее, чтобы мотивировать человека, необходимо подать напряжение на рабочее место, как на процессор, в виде дедлайнов и премиальной части зп
maslakak
17.04.2023 15:06-3Понятие "10х-программист" возникло в IT-сфере и означает разработчика, который в 10 раз более продуктивен, эффективен и квалифицирован, чем средний программист. Такой специалист обладает высоким уровнем знаний и навыков, быстро решает сложные задачи, умеет работать с большим объемом кода и применять передовые технологии. Он также способен быстро обучаться и адаптироваться к новым условиям и требованиям проектов. 10х-программисты являются ценными кадрами для компаний, которые стремятся к развитию и инновациям в IT-сфере.
Throwable
17.04.2023 15:06+1В те времена для того, чтобы запустить программу, надо было принести ее в вычислительный центр. Помещение, размером с современный дата центр
Создаётся впечатление, что с тех пор концепт не особо изменился. Сегодня чтобы протестить код, нужно залить его в репозиторий, скомпилировать, запаковать в контейнер, развернуть в облаке, сделать необходимые тесты, достать результаты, и по новой... Только вместо оператора там теперь сидит девопс инженер. Каждый раз на умные люди изобретают новые препятствия на пути между программистом и исполняемой средой...
Kanut
17.04.2023 15:06Сегодня чтобы протестить код, нужно залить его в репозиторий, скомпилировать, запаковать в контейнер, развернуть в облаке, сделать необходимые тесты, достать результаты, и по новой...
Я допускаю что такое встречается и наверняка достаточно часто. Но я бы сказал что обычно тестить код можно и без этого. Как минимум части кода точно.
Throwable
17.04.2023 15:06То, что тесты отдельных частей кода зеленые отнюдь не гарантирует, что весь бизнес кейс работает корректно. Кроме того, тестирование по частям накладывает дополнительные расходы на мокирование и фейкирование зависимостей, а это не тривиальная задача. Например, как тестировать по-частям монорепозиторный фронт с зависимостями от 100 микросервисов?
BlackSCORPION
17.04.2023 15:06Ну это уже чтобы совсем совсем потестить, а так можно на локальной машине докеры запускать, они же для этого и были придуманы, чтобы works on my machine, стало works in docker.
ggo
17.04.2023 15:06И тем не менее, в любой профессии есть люди, которые в 10 раз более эффективны, чем в среднем по отрасли. Да, таких мало. Да, эффективны в самом широком смысле этого слова.
un1t
17.04.2023 15:06+110х это же понятие относительное. Возможно вы не видели 10х программиста отнсительно вашего уровня, но как насчет 0.1x прораммиста? Такого который дневную задачу делает за неделю, приичем криво и косо, что потом приходиться еще 2 недели баги фиксить. Они точно существуют. Я таких видел и это не джуны.
Arhammon
17.04.2023 15:06+1А бывает еще 10х работник приходит в другую компанию и работает как 0.1х три года прежде чем выйти на 1х. В одной среде был звездой, а бюрократия процессы и задачи совсем чуть-чуть поменялись и все...
x2v0
17.04.2023 15:06+6Гуглит, когда в чём-то не уверен.
Тратит время на другие вещи помимо программирования, например хобби, друзей или семью.
Пишет код с — вздох — багами.
Пишет код, который могут прочесть другие.
Читает доки.
Обновляет доки.
Не обязательно помешан на коде, который пишет, или задаче, которую решает.
Не удивляется, когда кто-то чего-то не знает.
Хочет и может взаимодействовать с другими.
Умеет признать, что был неправ, и не боится сказать «Я не знаю».
Помогает другим прокачать свои навыки.
Копипастит код из StackOverflow.
Задаёт вопросы.
Может любить или не любить писать документацию, но всё равно делает это для будущих разработчиков.
Умеет быть благодарным за потраченные время, усилия и энергию других людей.
Ценит конструктивные и полезные код-ревью от коллег.
Предоставляет конструктивные, полезные, тактично поданные код-ревью, которые помогают коллегам расти как в личном, так и в профессиональном плане.
Просит помощи, когда нуждается в ней.
Может иметь красочный фон рабочего стола.
Поддерживает код на продакшне, даже если не он его написал.
Порой может чувствовать себя самозванцем.
Следит за тем, чтобы обсуждения всегда были продуктивными и у всех была возможность высказать своё мнение перед тем, как команда примет решение. Не считается с чужим мнением только при наличии аргументов.
Создаёт сообщество и делится знаниями.
Никогда не перестаёт учиться.
Желает выйти из зоны комфорта.
Вносит вклад в сообщество.
Может медленно писать код.
Не хейтит фреймворк Y, если работает с фреймворком X.
Иногда делает небольшие перерывы, чтобы проветрить голову.
Может работать как продуктивно, так и не очень.
Не воспринимает себя слишком серьёзно.
Косячит время от времени.
Говорит: «Я никогда не слышал об этом», — вместо того, чтобы кивать и притворяться, что это не так.
Заслуживает доверия.
Работает, чтобы жить, а не наоборот.
Имеет любимый редактор, браузер и операционную систему, но понимает, что у других тоже есть свои любимчики.
event1
17.04.2023 15:06Гуглит, когда в чём-то не уверен.
Это как раз 10х программист. 1х спрашивает у соседа, когда в чём-то не уверен
Тратит время на другие вещи помимо программирования
это просто от возраста зависит
Не удивляется, когда кто-то чего-то не знает.
и это тоже
youzhick
17.04.2023 15:06>> "Все, кто так или иначе связан с IT-сферой, знакомы с понятием 10х-программист."
Больше четверти века в программировании, а термин такой впервые встречаю :)
x2v0
17.04.2023 15:06В Тему - https://bitfieldconsulting.com/golang/crisp-code
Don't write clean code, write CRISP code. Who wants to write dirty code, unless maybe it's for a porn site?
Good programs should be Correct, Readable, Idiomatic, Simple, and Performant
saipr
Так это же про меня, про то как я программировал в 70-е и 80-е годы аж прошлого столетия:
Но честно скажу, что до прочтения данной статьи о 10-х программистах не слышал (или не обращал внимание). А за статью спасибо.
Sergeygs
Я вот тоже с удивлением для себя открыл этот термин, хотя перфокарты в руках держал :)
saipr
И перфоленты тоже.
rombell
На перфолентах программировать не пришлось, только загружал с них "Посадку на Луну" и "Управление государством". А вот колоды перфокарт таскал девочкам. И самостоятельно изучали JCL, чтобы отжать побольше времени для своих вычислений на ВЦ.
Когда-то записал на перфоленте список одноклассников, чтобы позже можно было найти и списаться.
Плохой выбор оказался.
saipr
Про то и другое стоило бы написать, а заодно и про девочек:
А вот с этим соглашусь: