"Хороший програміст може бути в 10 разів більш продуктивним, ніж посередній" [закрито]


54

Я читав інтерв'ю з чудовим програмістом (це не англійською), і в ньому він сказав, що "чудовий програміст може бути в 10 разів кращим, ніж посередній", що дає причину, чому хороші програмісти дуже добре платять і чому програми-компанії надають багато можливостей для своїх співробітників. Ідея полягала в тому, що існує дуже великий попит на хороших програмістів, через вищезазначену причину, і саме тому компанії платять дуже багато, щоб їх залучити.

Чи згодні ви з цим твердженням? Чи знаєте ви якісь об'єктивні факти, які могли б це підтвердити?

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


чи можете ви опублікувати посилання на інтерв'ю?
Мірко

1
@ Area404 Як я вже сказав, це не англійською мовою: economie.hotnews.ro / ...
m3th0dman


9
10-кратна різниця в продуктивності - відомий факт, виміряний для програмістів (McConnell 1 , 2 )
gnat

Відповіді:


41

Досить ретельний огляд та аналіз досліджень різниці в продуктивності наведено у двох статтях, написаних Стівом МакКоннелом :

У першій статті ( Варіації продуктивності ... ) зазначено:

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

Детальне вивчення висновків Сакмана, Еріксона та Гранта показує деякі недоліки в їх методології ... Однак навіть після обліку недоліків їхні дані все ще показують більш ніж 10-кратну різницю між найкращими програмістами та найгіршими.

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

Ця стаття також має цікаву сторону:

Цей ступінь варіації не характерний для програмного забезпечення. Дослідження Норма Августина виявило, що за різними професіями - писемністю, футболом, винаходом, поліцейською роботою та іншими професіями - топ-20 відсотків людей виробляли близько 50 відсотків продукції, незалежно від того, чи є це виправлення, патенти. , вирішені справи або програмне забезпечення (Августин 1979).


Друга стаття ( ... Наскільки достовірними є основні дослідження? ) Написана головним чином для критичного огляду першого Лорана Боссавіта :

У другій статті, в розділі «Більш глибоке занурення в дослідження, що підтримують« 10 разів », МакКоннелл переглядає більш детально посилання, використані в першій статті, і робить висновок:

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

... комплекс досліджень, що підтримують 10-кратну заяву, настільки ж міцний, як і будь-яке дослідження, проведене в інженерії програмного забезпечення. Дослідження, що підтримують заяву 10x, поодиноко не підлягають методологічному обмеженню, описаному на рисунку 1, оскільки вони вивчають саму індивідуальну мінливість (тобто лише ліву частину фігури). Боссавіт не наводить жодного дослідження - хибного чи іншого -, яке протидіє 10-кратній заяві, і я не бачив таких досліджень. Той факт, що жодне дослідження не дало висновків, що суперечать 10-кратній заявці, надає ще більшої впевненості в заяві 10-кратної. Коли я розглядаю кількість проведених досліджень, то в сукупності я вважаю, що дослідження є не лише сугестивними, але й переконливими, що є рідкісним у дослідженні інженерних програм.


Для повноти перелік посилань, які використовуються у варіаціях продуктивності ... , також цитується нижче:

Список літератури

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

Бум, Баррі В. і Філіпп Н. Папаччо. 1988. "Розуміння та контроль витрат на програмне забезпечення". Операції IEEE з інженерії програмного забезпечення SE-14, вип. 10 (жовтень): 1462-77.

Boehm, Barry et al., 2000. Оцінка витрат на програмне забезпечення з Cocomo II, Бостон, Массачусетс: Аддісон Веслі, 2000.

Boehm, Barry W., TE Grey, T. Seewaldt. 1984. "Прототипізація посилань: багатопроектний експеримент." Операції IEEE з інженерії програмного забезпечення SE-10, вип. 3 (травень): 290-303. Також у Jones 1986b.

Карт, Девід Н. 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. "Дослідницькі експериментальні дослідження, що порівнюють ефективність програмування в Інтернеті та офлайн". Зв'язок ОСБ 11, вип. 1 (січень): 3-11.

Валетт, Дж. Та Ф.Е. Макґаррі. 1989. "Підсумок досвіду вимірювання програмного забезпечення в лабораторії інженерії програмного забезпечення". Журнал систем та програмного забезпечення 9, вип. 2 (лютий): 137-48.

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


13
"тіло досліджень, що підтримують 10-кратну заяву, настільки ж міцне, як і будь-яке дослідження, проведене в інженерії програмного забезпечення" - так, це дійсно так погано. :)

Дивіться також дискусію між Боссавітом та МакКоннеллом (та іншими) у коментарях до другої статті
ДНК

92

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

І справді чудовий програміст може робити те, чого бідні та середні програмісти просто ніколи не досягли, незалежно від того, скільки часу ви їм приділили.

Тож з цих причин важко говорити про "10x настільки продуктивно" або "100x asproductive".

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

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


33
Так само, як жахливі програмісти можуть знизити продуктивність оточуючих, великі програмісти можуть підвищити продуктивність тих, хто їх оточує. Вони виробляють код, який легко розширити, і п'ятихвилинна розмова з ними може привести інших програмістів до кращого шляху.
Gort the Robot

8
Порівняно з вашим справді жахливим програмістом, програміст з нульовою продуктивністю був би надзвичайним.
Гленатрон

Як би ви міряли, щоб хороший поет був більш продуктивним, ніж поганий поет? Якщо ви хочете отримати найвищу якість продукції, деякі люди, можливо, зможуть її виготовити, а інші можуть не отримати її. Тепер ваша компанія створює вірші чи надсилає клієнтам повідомлення з нагадуванням? : P
mika

30

Факти та помилки станів програмної інженерії (Факт 2, доступний у попередньому перегляді Amazon):

Найкращі програмісти в 28 разів кращі за найгірших програмістів, згідно з дослідженнями "індивідуальних відмінностей". Зважаючи на те, що їхня оплата ніколи не пропорційна, вони є найбільшими угодами в галузі програмного забезпечення.

(дивіться список джерел для дослідження)

Звичайно, якщо порівнювати продуктивність непрограміста (або дуже поганого програміста) з хорошою (з точки зору досвіду та знань), різниця може бути нескінченно великою ( n/0 == infinityдля будь-якого позитивного n), але вона не є ні справедливою ні розумне порівняння.

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

  • Використовувані технології
  • Країна / штат, в якому ви працюєте
  • Багатство компанії
  • Тип діяльності компанії
  • Кількість розробників у компанії
  • Як довго ви працюєте в компанії
  • Офісна політика

разом із вашим особистим ...

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

20

Моя відповідь - "так, але будьте уважні, як ви використовуєте цю метрику".

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

Але ...

Ви обережно ставитесь до цього. Я дійсно не довіряю більшості вимірювань продуктивності, оскільки я бачив нескінченні випадки, коли майже кожна відома метрика не вдається розглянути те, що я вважаю життєво важливим для продуктивності команди. Тому я взагалі ненавиджу такі важкі цифри за "продуктивність". Ось кілька прикладів:

  • Рядки коду (LOC) - це загалом ненависна метрика, оскільки бездумний програміст може генерувати багато жахливих, багатослівних, неефективних, важких для налагодження рядків коду, тоді як хороший програміст створює кілька, елегантних, легких у виправленнях, рідко ламаних рядків коду більше часу, але які в цілому кращий вибір.
  • Помилки, що генеруються та / або час виправляти - кожен створить помилки, і найчастіше найдорожчі помилки генеруються низкою неправильних рішень, для яких генератор проблеми є лише останнім в ефекті доміно. Крім того, ваші чудові налагоджувачі не завжди є вашими чудовими дизайнерами - вам потрібно і те, і інше.
  • Практично за будь-якою метрикою є великі розробники, які так сильно відчувають себе в команді, що 1 "суперпродуктивний" розробник відіб'є 10 в основному хороших розробників, і я рідко бачу когось, хто може все зробити добре, тому нам знадобиться більше 1 людини на проекті.
  • Немає можливості легко пояснити тих чудових людей, які бачать проблеми, що виникають раніше, ніж вони серйозні, і вирішують їх, особливо коли проблема - це розрив у процесі - несправна CM, неефективна збірка, розрив у тестуванні, недолік безпеки - це часто виглядають як велика марнотрата часу, поки ви не зрозумієте, що вони рятують вас від катастрофи - немає способу це виміряти.
  • Крім того, є команди, які я вважаю за потрібне в команді певного розміру, яку я б назвав "будівельниками згуртованості" - рідко це абсолютний верх продуктивності, вони зазвичай все ще у верхніх 20%, і вони виконують неоціненну роботу, допомагаючи нарощувати нові люди, з'єднуючи крапки і переконуючись, що правильні запитання задаються, а потрібні люди тримаються в циклі, вони пишуть (не задані!) ключовий фрагмент документації, на який звертаються всі, оскільки це не тільки правильний документ, але і це складено просто правильним шляхом. Якщо ви хочете, щоб 10 людей працювали з максимальною ефективністю, вам абсолютно потрібен один із цих людей, і ви цього не отримаєте, якщо помістите 10 супер супер розробників в кімнату.

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

Отже, мій великий застереження - що ти збираєшся робити з цією метрикою? Я буду використовувати щось подібне, щоб усвідомити, що правильні інструменти та талант можуть спричинити велику різницю в роботі, але якщо ви спробуєте оптимізувати команду, де кожен індивід виробляє 10-кратний "типовий" результат, ви зобов'язані випадок розчарування. Краще - знайти спосіб змусити вашу команду зробити 2-3 рази те, що вони робили раніше, працюючи разом краще.


Само собою, я теж маю. :)
bethlakshmi

Це дуже хороший момент, який повинен бути очевидним для людей, які роблять і вірять 10-кратній претензії. Як ви вимірюєте продуктивність програміста? Поки ми не зможемо зробити це точно, точно та надійно, претензія є лише міфом.
Джордан Рігер

Це не міф, див. Посилання в інших відповідях. Подані тут пункти не є спростуванням, а радше дають ширший спектр продуктивності.
foo

10

У своїй книзі Лепрекони програмної інженерії Лоран Боссавіт описує дослідження 10-кратної заявки на продуктивність. Він виявив, що за цим не стоїть звукових цифр - претензія перейшла від спекуляцій до «встановленого факту» телефонною грою послідовно більш конкретних тверджень у цитуванні. Повідомлення в блозі, що містить розділ про 10-кратну претензію та містить відповідні цитати та неправильні цитати, є фактом та фольклором у розробці програмного забезпечення .

Він знайшов щось подібне: хтось у 1968 році робив дослідження, в якому порівнював людей, які вирішували певну проблему налагодження, і виявив, що деякі з них робили це в 10 разів швидше, ніж інші. З цього можна зробити висновок, що деякі люди в 10 разів краще вирішують цю проблему , або ми могли б зробити висновок, що деяким людям пощастило , або широкий спектр різних речей. Деякі люди вирішили цитувати це як (це все парафрази) "дослідження (Sackman et al, 1968) виявило, що деякі програмісти працюють в 10 разів швидше, ніж інші". Тоді це стало "дослідження показали, що хороші програмісти в 10 разів кращі за середні", то, нарешті, "загальновідомо, що продуктивність програміста змінюється в 10 разів між особами". Тоді хтось збирає всі ці цитати, неправильно цитуючи одне оригінальне джерело сказати "багато дослідників вірять ...".

Звичайно, це не була б телефонною грою, якби змінилася лише правдивість твердження: множник переходить на 11 і більше .


Дивіться також дискусію між Боссавітом та МакКоннеллом (та іншими) у коментарях до другої статті
ДНК

2

" Продуктивний програміст у такому середовищі - це той, хто найкраще розуміє та реалізує потреби користувачів, а не той, хто може написати найрозумніший код. " (З відповіді Carson63000 )

Цей ключовий момент у поєднанні з бетлакшміБали складають величезний момент. Чудовий розробник може бути чудовим у своєму одному фрагменті реальності, але розпадається, як тільки світ змінюється. Можливість бути в курсі потреб бізнесу набагато важливіше, ніж усе інше. Зрештою, якщо ваш бізнес не є технологією, бізнес не дбає про технології; їм потрібні рішення. Тож, що бути чудовим з дизайнерськими моделями, не означає прискіпливо присідати для кінцевих користувачів, яким просто потрібен дамп даних для показу на веб-сторінці. Я бачив посередніх розробників, щоб забезпечити собі роботу, обслуговуючи бізнес, який їх підтримує, тоді як великим розробникам нудно і піти в пошуках нескінченного виклику. Залежно від вашої організації та проектів, ви можете годувати цих розробників, які голодують на виклик, але, швидше за все, настане момент, коли ви просто не зробите ' t потрібна ця кількість процесорної потужності. Ці розробники не люблять просто сидіти простою, як процесор. Вони закриють і перезавантажать в іншому місці.

Нарешті, я скажу, що це нормально, щоб знати, хто твої "ключові" виконавці, але "команда" розвитку - все ж команда. Щоб повторити бетлакшмі, " що ти збираєшся робити з цією метрикою?"Якщо вам потрібна команда, яка поводиться як команда, я б не зосереджувався на таких показниках. Я зрозумів би, що навіть найменший гравець все ще є важливою частиною команди. Навіть при 60% меншій продуктивності вашого ключа гравцеві, той один гравець може давати вашій команді щось необхідне. Дізнайтеся, що це таке, і спробуйте примножити це. Не вигорайте свого ключового гравця, припускаючи, що він повинен очолити команду, знайдіть способи примножити і його вихід, забруднюючи інших гравців такою величністю. Це вимагає трохи творчості, а не просто цифр. Зрештою, ви можете дізнатися, що те, що робить хорошого програміста, навіть не тим програмістом, це можуть бути його однолітки, його можливості на робочому місці або це навіть ти.


Оцініть правки. Тепер, чому голосування проти? Чи ми говоримо, що динаміка команди є марною при вивченні вартості та продуктивності розробника?
Драгон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.