Супергерой или миф: как возникло понятие 10х-программист и что за ним стоит

Супергерой или миф: как возникло понятие 10х-программист и что за ним стоит

Все, кто так или иначе связан с IT-сферой, знакомы с понятием 10х-программист. Так называют самых крутых и эффективных разработчиков. Термин встречается буквально везде: от кликбейтных статей “Как стать программистом за месяц” до книг уважаемых экспертов вроде Стива Макконнелла или Мартина Фаулера. Даже в сериале «Кремниевая долина» в первых же сериях упоминается, что главный герой – как раз один из тех самых 10х-программистов.

Все статьи по теме ссылаются на некие исследования ученых. Я разобрался, как появились 10х-программисты и что на самом деле стоит за этим термином.

Очередной заказ военных

В 1966 году научная группа из двух сотрудников System Development Corporation Евгения Гранта и Гарольда Сэкмана по заказу армии США сравнивала эффективность работы опытных программистов (тогда еще не придумали Сеньоров) при прямом доступе к компьютеру и работе через оператора.

В те времена для того, чтобы запустить программу, надо было принести ее в вычислительный центр. Помещение, размером с современный дата центр, мог занимать всего один компьютер с единой точкой ввода/вывода. Программисты отдавали свой код в распечатанном виде или на перфокартах оператору и вставали в очередь на его исполнение. Ждать результата иногда приходилось до двух дней.

Альтернативой была новая на тот момент концепция разделения времени вычислительных ресурсов компьютера между несколькими рабочими местами. С помощью телетайпа программист самостоятельно вводил свою программу в компьютер и почти тут же получал результат. Но на все это уходило много накладных расходов: было необходимо более дорогое и сложное оборудование, а на переключение контекста между пользователями требовалось дополнительное машинное время. Критики этой концепции опасались, что программисты будут лениться самостоятельно проверять свой код, часто запускать нерабочие и неэффективные программы и впустую тратить машинное время. 

Чтобы узнать, как каждый из этих двух подходов влияет на производительность, ученым поручили провести эксперимент. Для него отобрали 12 человек, которых произвольно разделили на две группы. У каждой было по две задачи.

• Лабиринт – надо было написать программу для выхода из представленного в виде таблицы 20х20 лабиринта.

• Алгебра – надо было написать программу, которая сможет интерпретировать введенное через телетайп алгебраическое выражение и решить его. Также требовалось обработать ошибки ввода, если они есть.

Обе задачи группы должны были решить с прямым и непрямым доступом к компьютеру. Чтобы сэмулировать работу через оператора, организаторы эксперимента наняли двух студентов и задали ряд правил. По ним участникам эксперимента можно было:

• отдавать код только с 8:00 до 17:00

• проинструктировать оператора, что и как вводить

• попросить распечатать отладочную информацию

• одновременно отдавать в работу не больше 2 программ в час

• получить результат через 2 часа, при условии его передачи до 15:00, в ином случае он мог быть готов лишь на следующий день

Для написания кода в эксперименте использовался 60-ти тонный транзисторный компьютер IBM AN/FSQ-32, который изначально создавался  для ядерных бункеров. Он поддерживал концепцию разделения времени между пользователями и имел несколько телетайпов для работы. В качестве языка программирования подопытные могли выбрать между JTS (процедурно-ориентированный язык «JOVIAL Time-Sharing») и SCAMP. 

На чем держится миф

В ходе эксперимента ученые замерили время, потраченное участниками на написание рабочей программы, и машинное время, потребовавшееся на тестовые запуски. Также они сопоставили размер получившихся программ и скорость их исполнения. 

В результате ученые сделали несколько выводов:

• При прямом доступе к набору и исполнению кода результат можно получить гораздо быстрее. В основном, из-за отсутствия задержки между вводом кода и получением результатов.

• Если позволить программистам самостоятельно запускать программы, то они начинают расходовать в среднем на 30% больше машинного времени.

Ученые также заметили значительный разрыв в производительности программистов. Несмотря высокую квалификацию всех участников эксперимента, разница между лучшими и худшими результатами была очень велика: от 5-тикратной до 28-кратной. При этом, ученые не обнаружили прямой корреляции ни с опытом работы, ни с оценками в стандартных тестах для программистов.

Полученные результаты передали военным, а также опубликовали в журнале IEEE Transactions on human factors in electronics с пометкой, что это первое известное исследование продуктивности программистов. Интересно, что в том же номере вышла статья, критикующая выводы ученых. Ее авторы указывали на ограниченность исследования, а также критиковали его параметры и методы.

Тем не менее, в семидесятых на сделанные в ходе упомянутого эксперимента выводы в книге «Мифический человеко-месяц или Как создаются программные системы» сослался Фредерик Брукс. Он обобщил их:

Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой‑либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)

После выхода книги о существовании 10x-программистов начали говорить как о факте. С тех пор некоторые компании ищут именно таких специалистов, ведь считается, что каждый из них способен один работать за целую команду. Начинающие программисты ищут способы стать “десятикратными” и часто выгорают по пути.

Хотя, если разобраться, за самим понятием не стоит ничего фундаментального.