Супергерой или миф: как возникло понятие 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-программистов начали говорить как о факте. С тех пор некоторые компании ищут именно таких специалистов, ведь считается, что каждый из них способен один работать за целую команду. Начинающие программисты ищут способы стать “десятикратными” и часто выгорают по пути.
Хотя, если разобраться, за самим понятием не стоит ничего фундаментального.
