«Хороший программист может быть в 10 раз продуктивнее посредственного» [закрыто]

Я читал интервью с великим программистом (оно не на английском языке), и в нем он сказал, что «великий программист может быть в 10 раз лучше среднего», объясняя, почему хорошим программистам платят очень хорошо и почему программирующие компании предоставляют много возможностей для своих сотрудников. Идея заключалась в том, что спрос на хороших программистов очень велик из-за вышеуказанной причины, и именно поэтому компании платят очень много за их привлечение.

Согласны ли вы с этим утверждением? Знаете ли вы какие-либо объективные факты, которые могли бы это поддержать?

Изменить: вопрос не имеет никакого отношения к опыту; если вы говорите об одном великом программисте с 1-летним стажем, то он / она должен быть в 10 раз более продуктивным, чем посредственный программист с 1-летним стажем. Я согласен, что с годами опыта вещи начинают рассеиваться, но это не является целью вопроса.

Довольно подробный обзор и анализ исследований различий в производительности представлен в двух статьях, написанных Стивом Макконнеллом :

• Изменения производительности среди разработчиков программного обеспечения и команд: происхождение «10x»

• Происхождение 10X - Насколько обоснованным является базовое исследование?

Первая статья ( Изменения производительности ... ) гласит:

... В конце 1960-х годов Сакман, Эриксон и Грант (1968) провели первоначальное исследование, в котором были обнаружены огромные различия в производительности отдельных программ. Они изучали профессиональных программистов со средним опытом работы 7 лет и обнаружили, что соотношение времени начального кодирования между лучшими и худшими программистами было около 20 к 1; соотношение времени отладки свыше 25 к 1; размером программы от 5 до 1; и со скоростью выполнения программы около 10 к 1. Они не нашли никакой связи между опытом программиста и качеством кода или производительностью.

Детальное изучение выводов Сэкмана, Эриксона и Гранта показывает некоторые недостатки в их методологии ... Однако даже после учета недостатков их данные по-прежнему показывают более чем десятикратную разницу между лучшими программистами и худшими.

За годы, прошедшие с момента первоначального исследования, общий вывод о том, что «между программистами существуют различия по порядку величины», был подтвержден многими другими исследованиями профессиональных программистов (Curtis 1981, Mills 1983, DeMarco и Lister 1985, Curtis et al. 1986 , Card 1987, Boehm and Papaccio 1988, Valett и McGarry 1989, Boehm et al 2000) ...

^{Эта статья также имеет интересное примечание:}

^{Эта степень вариации не уникальна для программного обеспечения. Исследование, проведенное Нормом Августином, показало, что в самых разных профессиях - писательском деле, футболе, изобретательстве, работе в полиции и других профессиях - около 20 процентов людей производят около 50 процентов результатов, независимо от того, являются ли результаты приземлениями или патентами. , раскрытые дела или программное обеспечение (Августин 1979).}

Вторая статья ( ... Насколько обоснованным является базовое исследование? ) Была написана в основном для критического обзора первой статьи Лорана Боссавита :

• оригинальная критика на французском языке: Folklore ou fait scientifique, comment les différencier
• Английский перевод: Факт и фольклор в разработке программного обеспечения .

Во второй статье, в разделе « Более глубокое погружение в исследования, поддерживающее« 10x »», Макконнелл более детально проверяет ссылки, использованные в первой статье, и делает вывод:

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

... объем исследований, поддерживающих утверждение 10x, столь же прочен, как и любые исследования, которые проводились в области разработки программного обеспечения. Исследования, которые подтверждают утверждение 10x, как правило, не подлежат методологическому ограничению, описанному на рисунке 1, поскольку они изучают саму индивидуальную изменчивость (т. Е. Только левую сторону рисунка). Bossavit не ссылается ни на одно исследование - ошибочное или иное, - которое опровергает требование 10x, и я также не видел таких исследований. Тот факт, что ни одно исследование не дало результатов, противоречащих заявке 10х, обеспечивает еще большую уверенность в заявке 10х. Когда я рассматриваю количество проведенных исследований, в совокупности я нахожу исследование не только наводящим на размышления, но и убедительным, что редко встречается в исследованиях по разработке программного обеспечения.

Для полноты, список ссылок, используемых в вариациях производительности ... также цитируется ниже:

Рекомендации

Августин, NR 1979. "Законы Августина и основные программы развития системы". Обзор управления оборонными системами: 50-76.

Бём, Барри В. и Филипп Н. Папаччо. 1988. «Понимание и контроль стоимости программного обеспечения». IEEE Сделки по программной инженерии SE-14, нет. 10 (октябрь): 1462-77.

Бём, Барри и др., 2000. Оценка стоимости программного обеспечения с Cocomo II, Бостон, Массачусетс: Addison Wesley, 2000.

Boehm, Barry W., TE Grey и T. Seewaldt. 1984. «Прототипирование против спецификации: мультипроектный эксперимент». IEEE Транзакции по программной инженерии SE-10, нет. 3 (май): 290-303. Также в Джонс 1986б.

Кард, Дэвид Н. 1987. "Программа оценки программных технологий". Информационные и программные технологии 29, нет. 6 (июль / август): 291-300.

Кертис, Билл. 1981. «Обоснование изменчивости программиста». Труды IEEE 69, нет. 7: 846.

Кертис, Билл и др. 1986. «Психология программного обеспечения: необходимость междисциплинарной программы». Труды IEEE 74, нет. 8: 1092-1106.

Демарко, Том и Тимоти Листер. 1985. "Работа программиста и влияние на рабочем месте". Материалы 8-й Международной конференции по программной инженерии. Вашингтон, округ Колумбия: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Люди: продуктивные проекты и команды, 2-е изд. Нью-Йорк: Дорсет Хаус, 1999.

Миллс, Харлан Д. 1983. Производительность программного обеспечения. Бостон, Массачусетс: Литтл, Браун.

Sackman, H., WJ Erikson и EE Grant. 1968. «Исследовательские экспериментальные исследования, сравнивающие эффективность онлайн и оффлайн программирования». Коммуникации ACM 11, нет. 1 (январь): 3-11.

Валетт Дж. И Ф.Е. МакГарри. 1989. «Краткое изложение опыта измерения программного обеспечения в лаборатории разработки программного обеспечения». Журнал систем и программного обеспечения 9, нет. 2 (февраль): 137-48.

Вайнберг, Джеральд М. и Эдвард Л. Шульман. 1974. «Цели и производительность в компьютерном программировании». Человеческий фактор 16, нет. 1 (февраль): 70-77.

По-настоящему ужасный программист может иметь производительность ниже нуля (исправляемые ими ошибки занимают больше времени, чем просто выполнение всей их работы за них).

И действительно великий программист может делать то, чего никогда не добьются бедные и средние программисты , независимо от того, сколько времени вы им дали.

Поэтому по этим причинам трудно говорить о «10-кратной производительности» или «100-кратной производительности».

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

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

Факты и ошибки состояний разработки программного обеспечения (Факт 2, доступный в предварительном просмотре Amazon):

По данным исследования «индивидуальных различий», лучшие программисты в 28 раз лучше худших. Учитывая, что их зарплата никогда не бывает соразмерной, они являются самыми крупными сделками в области программного обеспечения.

(посмотрите список источников для исследования)

Конечно, если вы сравните производительность непрограммиста (или очень плохого программиста) с хорошей (с точки зрения опыта и знаний), разница может быть бесконечно большой ( n/0 == infinityдля любого положительного n), но это не справедливо ни толкового сравнения.

Ваша зарплата может зависеть от нескольких факторов (в случайном порядке):

• Используемые технологии
• Страна / штат, в котором вы работаете
• Богатство компании
• Тип бизнеса компании
• Количество разработчиков в компании
• Как долго вы работаете в компании?
• Офисные политики

вместе с вашим личным ...

• производительность
• знания и опыт
• участие в бизнесе компании (для стартапов)
• навыки ведения переговоров
• сексуальная привлекательность и навыки, смеется (ну, интеллект сексуален)

Мой ответ "да, но будьте осторожны, как вы используете этот показатель".

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

Но...

Вы должны быть осторожны, измеряя это. Я действительно не доверяю большинству показателей производительности, поскольку видел бесконечные случаи, когда почти все известные показатели не учитывают то, что я считаю жизненно важным для продуктивности команды. Поэтому я вообще ненавижу такие жесткие цифры за «производительность». Вот несколько примеров:

• Строки кода (LOC) - обычно ненавистная метрика, так как бездумный программист может генерировать много ужасных, многословных, неэффективных, трудных для отладки строк кода, в то время как хороший программист создает несколько элегантных, легко исправляемых, редко разбитых строк кода. через некоторое время, но в целом это лучший выбор.
• Сгенерированные ошибки и / или время для исправления - каждый генерирует некоторые ошибки, и часто самые дорогие ошибки генерируются серией плохих решений, для которых генератор проблемы является лишь последним в эффекте домино. Кроме того, ваши великие отладчики не всегда ваши великие дизайнеры - вам нужны оба.
• Практически по всем показателям есть отличные разработчики, которым так тяжело в команде, что 1 «сверхпродуктивный» разработчик изгонит 10 в основном хороших разработчиков, и я редко вижу того, кто может сделать все хорошо, поэтому нам понадобится более 1 человека на проекте.
• Нет никакого способа легко объяснить тех замечательных людей, которые видят проблемы, возникающие до того, как они станут серьезными, и устраняют их, особенно когда проблема заключается в разрыве в процессе - неисправный CM, неэффективная сборка, разрыв в тестировании, недостаток безопасности - эти часто выглядят как пустая трата времени, пока вы не поймете, что они спасут вас от катастрофы - это невозможно измерить.
• Кроме того, есть люди, которых я считаю необходимыми в команде определенного размера, которую я бы назвал «строителями сплоченности» - редко абсолютная вершина производительности, они обычно все еще находятся в верхних 20%, и они делают неоценимую работу по содействию наращиванию новые люди, соединяя точки и следя за тем, чтобы правильные вопросы задавались, а правильные люди были в курсе, они пишут (без ответа!) ключевую часть документации, на которую все ссылаются, потому что это не только правильный документ, но и это правильно воедино. Если вы хотите, чтобы 10 человек работали с максимальной эффективностью, вам абсолютно необходим один из этих людей, и вы не получите его, если разместите 10 супер-разработчиков в комнате.

Многие измерительные системы пытались принять во внимание эти факторы, но мне еще предстоит увидеть, что есть такая, которая учитывает все эти проблемы, поэтому меня никогда не впечатляют такие факторы, как «хороший разработчик в 10 раз продуктивнее, чем посредственный ", потому что я должен задаться вопросом, действительно ли метрика учитывает всю работу, которая должна быть включена в успешный продукт или успешную, процветающую команду.

Итак, мое большое предостережение - что вы собираетесь делать с этим показателем? Я буду использовать что-то вроде этого, чтобы знать, что правильные инструменты и талант могут привести к большой разнице в том, как выполняется работа, но если вы попытаетесь оптимизировать работу в команде, где каждый человек в 10 раз увеличивает «типичный» результат, вы обязаны случай разочарования. Лучше найти способ заставить вашу команду делать в 2-3 раза больше, чем раньше, лучше работать вместе.

В своей книге «Лепреконы разработки программного обеспечения» Лоран Боссавит описывает исследование 10-кратного заявления о производительности. Он обнаружил, что за этим нет убедительных цифр - претензия перешла от спекуляций к "установленному факту" в результате телефонной игры последовательно более конкретных претензий в цитировании. Сообщение в блоге, которое включает главу о требовании 10x и включает в себя соответствующие цитаты и неправильные цитаты, является фактом и фольклором в разработке программного обеспечения .

Он обнаружил, что-то вроде этого: кто-то в 1968 году провел исследование, сравнивая людей, решающих определенную проблему отладки, и обнаружил, что некоторые из них сделали это в 10 раз быстрее, чем другие. Из этого мы можем сделать вывод, что некоторые люди в 10 раз лучше решают эту проблему , или мы можем сделать вывод, что некоторым людям повезло , или широкому кругу разных вещей. Некоторые люди решили процитировать это как (это все перефразирование) «исследование (Sackman et al, 1968) показало, что некоторые программисты работают в 10 раз быстрее, чем другие». Затем выяснилось, что «исследования показали, что хорошие программисты в 10 раз лучше, чем в среднем», и, наконец, «общеизвестно, что производительность программистов варьируется в 10 раз среди людей». Затем кто-то собирает все эти цитаты, цитируя один первоисточник сказать «многие исследователи верят ...».

Конечно, это не была бы телефонная игра, если бы изменилась только достоверность утверждения: множитель также достиг 11 и выше .

« Продуктивный программист в этой среде - это тот, кто лучше всех понимает и реализует потребности пользователей, а не тот, кто может написать самый умный код». (От Carson63000 answer)

Этот ключевой момент в сочетании с бетлакшмиОчки имеют огромное значение. Великий разработчик может быть великим в своей части реальности, но развалится, как только мир изменится. Возможность идти в ногу с потребностями бизнеса гораздо важнее, чем что-либо еще. В конце концов, если ваш бизнес не является технологией, бизнес не заботится о технологиях; им нужны решения. Таким образом, отличная работа с шаблонами проектирования не означает, что вы будете сидеть на корточках перед конечными пользователями, которым просто необходим дамп данных для отображения на веб-странице. Я видел, как посредственные разработчики обеспечивают себе работу, обслуживая бизнес, который их поддерживает, в то время как великие разработчики скучают и уходят в поисках бесконечной проблемы. В зависимости от вашей организации и проекта (-ов), возможно накормить этих измученных разработчиками, но, скорее всего, наступит момент, когда вы просто не Мне нужно такое количество вычислительной мощности. Эти разработчики не любят сидеть сложа руки, как процессор. Они выключатся и перезагрузятся в другом месте.

Наконец, я скажу, что все в порядке, чтобы знать, кто ваши «ключевые» исполнители, но «команда разработчиков» все еще остается командой. Чтобы повторить Бетлакшми, « что ты собираешься делать с этим показателем?«Если вам нужна команда, которая ведет себя как команда, я бы не стал фокусироваться на таких показателях. Я бы понял, что даже самый маленький игрок по-прежнему является важной частью команды. Даже при снижении производительности вашего ключа на 60% игрок, что один игрок может дать вашей команде то, что ей нужно. Узнайте, что это такое, и попробуйте умножить его. Не сжигайте своего ключевого игрока, предполагая, что он должен возглавить команду, также найдите способы умножить свои результаты, заражая других игроков этим величием. Это требует немного творчества, а не просто цифр. В конце концов, вы можете узнать, что то, что делает хорошего программиста даже не тем программистом, это могут быть его сверстники, его возможности на рабочем месте или это может быть даже ты.