Świetna wydajność programisty - 10 000-krotna różnica? [Zamknięte]

19

Wielki operator tokarki rozkazuje kilka razy więcej niż przeciętny operator tokarki, ale wielki pisarz kodu oprogramowania jest wart 10 000 razy więcej niż przeciętny pisarz oprogramowania. - Bill Gates

Powiedzmy, że w tym samym zespole jest „świetny” inżynier oprogramowania i „przeciętny” inżynier oprogramowania. Jak możesz policzyć, że jeden inżynier jest 10 000 razy bardziej wydajny? Nie mogę tego w pełni zrozumieć, biorąc pod uwagę, że obaj biorą udział w funkcjach, błędach i badaniach i konsekwentnie dostarczają jakość. Czy mój opis prawdopodobnie uzasadniałby, że są powyżej „przeciętnej”? "świetny"?

Wpływ
źródło
2
Nie jestem pewien, czy to pytanie jest odpowiednie dla przepływu stosu, ale jestem również zainteresowany odpowiedziami.
Austin Henley,
18
Cytat mówi, że świetny jest wart 10k razy więcej niż przeciętny, nie ma w tym nic o „produktywności”.
Oded,
4
W rzeczywistości świetny programista może być znacznie mniej produktywny niż przeciętny. Zamiast wykonywać swoją „pracę”, zrobił coś lepszego niż to, co było poza radarem, a może nawet stworzył zupełnie nową linię produktów, która zdezaktualizowała pracę produktywnego programisty.
hotpaw2
2
Jestem pewien, że potrzebujesz obu, jeśli chcesz zarówno wprowadzać innowacje, jak i robić! @ # $ Gotowe.
Erik Reppen
6
Abe Lincoln powiedział kiedyś: „Gdybym miał osiem godzin na ścięcie drzewa, spędziłbym sześć godzin na ostrzeniu siekiery”, to nigdy więcej nie jest prawdą w programowaniu, gdzie wykonanie „dobrej” pracy znacznie przewyższa szybką pracę. Dobry programista może wydawać się mniej produktywny, ale przygotowuje się na wszystkie nadchodzące problemy.
BeardedO,

Odpowiedzi:

57

Nie chodzi o to, że jeden z nich jest 10 tys. Razy bardziej produktywny, to taki, że jeden jest 10 tys. Razy drugi. Oprogramowanie ma wyjątkowy warunek, w którym wadliwy projekt lub implementacja może pozostawać w stanie uśpienia przez lata (źle wykonana część zwykle „po prostu„ nie działa ”i nie trafia w teren), aż do cyklu życia produktu, dopóki dzień podnosi głowę w trudnej sytuacji.

Wszyscy powinni być zaznajomieni z wykładniczym kosztem naprawy defektu w fazie projektowania, wdrożenia, testowania, produkcji i konserwacji.

Kiedy bierzesz pod uwagę możliwą odpowiedzialność, a także reputację firmy, łatwo jest stwierdzić, że programista, który wiedział wystarczająco, aby uniknąć problemu, jest wart 10 000 razy ten, który nieświadomie lub naiwnie wdrożył złe rozwiązanie.

Edycja (wiosna 2014): „Heartbleed”

Dave Nay
źródło
1
Subtelne, że to brak odpowiedzialności sprawia, że ​​programista jest wart 10 000 razy więcej niż inny. Nie myślałem o tym pierwotnie, dziękuję. Wydaje się to jednak niezwykle trudną rzeczą do zmierzenia.
TheImpact,
2
@TheImpact: Trudno jest „zmierzyć”, ponieważ zwykle staje się to widoczne dopiero po zakończeniu kodowania i uruchomieniu projektu na całym świecie. Wydajność i niezawodność oraz ogólnie po myśli „przeciętnego” programisty; podczas gdy są one wbudowane w samą konstrukcję, która pochodzi od świetnego programisty.
NotMe
10
+1. Jeśli wartość dobrego programisty wynosi 100, ile razy to więcej niż -10?
Nicole
3
Istnieje również kwestia podaży i popytu. Raymond Chen: „Ufam tylko około pięciu osobom na świecie, że piszą tak zaawansowane kody i nie jestem jednym z nich. - blogs.msdn.com/b/oldnewthing/archive/2011/04/15/10154245 .aspx . ” Dotyczy to szczególnie kodowania związanego z bezpieczeństwem, ponieważ problemy mogą pozostawać niezauważone (a przynajmniej niezauważone przez białe czapki) przez lata. Schneier komentuje, że większość programistów potrafi napisać algorytm szyfrowania, którego sam programista nie może złamać. Zauważam, że nie oznacza to, że ktoś lepiej nie może tego zrobić ... chyba że pisarz jest najlepszy.
Brian,
1
Rozważ pierwsze uruchomienie rakiety Ariane V. Wystąpił nieprzechwycony podział przez zero, który spowodował zniszczenie rakiety. Nie tylko to, ale kod, o którym mowa, przestał mieć jakąkolwiek wartość w momencie, gdy rakieta została zapalona. Pomyśl o milionach, które zaoszczędziliby dzięki lepszemu programistowi.
Loren Pechtel
44

Przeciętny pływak olimpijski może pływać z odległości około 2,5 mil na godzinę.

Przeciętny człowiek (który umie pływać) może pływać około 1,5 mili na godzinę na odległość.

Oznacza to, że przeciętny pływak olimpijski może przepłynąć Kanał La Manche w około 8 godzin.

Byłoby zatem uzasadnione, że pływaczka olymiczna jest o 60% szybsza niż średnia i że przeciętny pływak ukończy wyścig około 13 godzin ...

Tyle że jeśli ja, przeciętny pływak, próbuję przepłynąć Kanał La Manche, jedynym sposobem, przez który przejdę, jest mycie na brzegu tydzień później.

Wiele aspektów programowania przypomina pływanie po kanale La Manche. To jest zlew lub pływanie. Nie wiem nawet, czy 10.000X lepiej jest naprawdę dokładnym sposobem na opisanie różnicy między ukończonym oprogramowaniem, które działa, a niekompletnym oprogramowaniem, które nie działa.

Morgan Herlocker
źródło
31

Powiedzmy, że w tym samym zespole jest „świetny” inżynier oprogramowania i „przeciętny” inżynier oprogramowania. Jak możesz policzyć, że jeden inżynier jest 10 000 razy bardziej wydajny? Nie mogę tego w pełni zrozumieć, biorąc pod uwagę, że obaj biorą udział w funkcjach, błędach i badaniach i konsekwentnie dostarczają jakość. Czy mój opis prawdopodobnie uzasadniałby, że są powyżej „przeciętnej”? "świetny"?

To wiele „zalet” dla „przeciętnego” inżyniera oprogramowania. W rzeczywistości wielki inżynier oprogramowania rozwiązuje problemy w ciągu kilku godzin, których przeciętny inżynier nigdy nie rozwiąże poprawnie. Świetny inżynier oprogramowania rozwiązuje zwykłe problemy w jednej trzeciej czasu przy jednej piątej tyle kodu i jednej dziesiątej tyle błędów. Kod wielkiego inżyniera oprogramowania działa w O (n), podczas gdy kod przeciętnego inżyniera oprogramowania działa w czasie O (n ^ 3). Wielki inżynier oprogramowania może dostosować swoje rozwiązanie, gdy czekasz, podczas gdy przeciętny inżynier oprogramowania narzeka na późne zmiany specyfikacji i mówi, że spełnienie nowych wymagań zajmie tygodnie. To są wszystkie prawdziwe różnice, które widziałem, kiedy wielki inżynier przerabia pracę przeciętnego inżyniera.

Kevin Cline
źródło
6
+1: niestety często zdarza się, że problemy nie otrzymują poprawnych rozwiązań. To szalone, jak często występują obejścia i sprzęgła, które tylko „naprawiają” bezpośredni problem, ale prawie na pewno spowodują jeszcze więcej problemów w ciągu kilku tygodni. „Ale to za kilka tygodni, pozwólmy naszym przyszłym sobą rozwiązać te problemy!”
Joachim Sauer
Różnica między działającym i niedziałającym rozwiązaniem prawie niemożliwego problemu zbliża się do nieskończoności, np. Organizacja przeżywa, kontra bankrutuje lub coś wybucha w laboratorium i zabija wszystkich inżynierów (klasyczna fabuła dramatu telewizyjnego ...) itp. ,
hotpaw2
@ hotpaw2: To prawda, nie myślałem o niczym tak dramatycznym. Myślałem o problemach z odrobiną złożoności matematycznej, np. Obliczeniach graficznych, takich jak sortowanie topologiczne. Przeciętny inżynier może spędzać tygodnie pisząc powolne i błędne rozwiązanie. Świetny inżynier odwzoruje wymagania biznesowe na dobrze znany problem, a następnie wyszuka opublikowaną bibliotekę lub algorytm.
kevin cline
9

Spróbuję rozwiązać ten problem pod względem różnic:

Świetny inżynier wykona następujące czynności lepiej niż przeciętny:

  • Projekt - twórz projekty, które będą wymagały mniej modyfikacji i będą bardziej elastyczne. Przekłada się to na oszczędności w całym okresie użytkowania oprogramowania.
  • Funkcje - będą wdrażane na bieżąco i będą czystszymi implementacjami.
  • Błędy - zostaną znalezione szybciej, zostaną dobrze naprawione i nie wprowadzą mniej przyszłych błędów.
  • Dochodzenia - zostaną zakończone szybciej dzięki lepszym rozwiązaniom i wynikom.

Reasumując, pozwoliłyby one zaoszczędzić firmie dużo pieniędzy w czasie programowania i sprawić, że firma dużo pieniędzy w dodatkowe możliwości.

Oded
źródło
4

Świetny programista często nie tylko „bierze udział w funkcjach, błędach i badaniach”, aby zarobić pensję. Czasami odchodzą i zakładają własną firmę, dołączają do startupu lub rozpoczynają nowy projekt skunkworks, a może w dawnych czasach dołączyli do znanego na całym świecie niebieskiego nieba laboratorium badawczo-rozwojowego i wprowadzają innowacje do produktu, którego nikt nie uważa za potrzebny lub można było pomyśleć o oprogramowaniu, zanim wiedza, umiejętności i pot tego wielkiego programisty były możliwe.

Wiele z tych „wartości” tego programisty dotyczy proporcjonalnej nagrody za ryzyko. Programista mógł nawet zostać zwolniony za myślenie o tak zwariowanych produktach programowych, zamiast zarabiania 2X lub więcej.

Co dzieje się z okazjonalnym uruchomieniem oprogramowania: upublicznienie za milion / miliardy lub zdobycie przez Google lub Facebook, i in. w podobnych ilościach rzadko zdarza się operatorom tokarek (chociaż przynajmniej jeden założyciel firmy technologicznej z Doliny Krzemowej miał tokarkę w swoim warsztacie).

hotpaw2
źródło
4
„.... giełdę na milion / miliardach, .....” Pomimo retoryki mediów zdarza się to rzadko dla inżynierów oprogramowania albo. Dla każdego, kto „robi to” tysiące wpaść w zapomnienie i / lub przejść chociaż jeden zbyt wiele rund VC i wrócić do pracy 9-5 dni z niczym więcej niż gorzki smak w ustach ...
mattnz
1
@mattnz: Prawdopodobnie nieco lepszy niż kurs 10 000 na 1, który idzie w parze z rzekomą wartością 10 000X tego programisty.
hotpaw2
3

Istnieją rozwiązania, które będą w stanie rozwiązać tylko najlepsi programiści. Rzucanie tysięcy miernych nie zadziała. Jest to także trudniejsze do koordynacji wysiłków, nawet gdyby mogli wspólnie połączyć kawałki ich wiedzy.

Odpowiedzi na pytania dotyczące SO nie są inne. Istnieje wiele problemów, gdzie z grupy przeciętnych programistów, jedna jest w stanie wymyślić odpowiedzi. Strony te prawdopodobnie zrobić o wiele lepiej koordynowania wysiłków niż większości zespołów programistycznych, który jest smutny.

JeffO
źródło
3

Myślę, że istnieją pewne dowody empiryczne, które obsługuje cytat Gatesa. Pamiętam czytanie (choć nie pamiętam źródła), że w basenach wpisując różnica w wydajności (łatwo mierzalnych dla puli typowania) między tymi w 5. percentyla i te w 95% percentyla było coś jak 3 do 1. Ale po oprogramowanie do przetwarzania słowo stało się dostępne, wskaźnik wzrósł do czegoś jak 10 lub 20 do 1, ponieważ ci, którzy mogliby korzystać z zaawansowanych funkcji oprogramowania zyskał jeszcze bardziej względną przewagę.

Przypuszczalnie w przypadku tworzenia oprogramowania współczynnik byłby jeszcze wyższy, ponieważ istnieje jeszcze większa swoboda w korzystaniu z wszelkiego rodzaju narzędzi, technik itp. Trudniej jest zmierzyć różnice, ale większość prób wychodzi z co najmniej 10 do 1, i że to prawdopodobnie nie doceniając znaczenia, ponieważ jest pomiar tylko to, co jest łatwe do zmierzenia.

Przy pisaniu na maszynie lub obsługiwaniu tokarki osoby w górnym 1% są prawdopodobnie bliskie osiągnięcia fizjologicznych granic tego, co jest możliwe. W przypadku programowania wyraźnie nie są (stosunek jak długo to trwa do zapisu kodu versus jak długo to trwa, aby wpisać się kod jest ogromny), więc nie powinno być miejsca dla większego zróżnicowania więcej.

psr
źródło
1
Łał. Mów o pomijaniu sedna. Każda miara produktywności programisty, która zaczyna się od „prędkości pisania” jako punktu kontrolnego, z pewnością uzyska asinine odpowiedź.
riwalk