Od tak dawna, jak jestem w oprogramowaniu, mówi się o 10x developerze. To są ludzie, których chcesz, aby rozwiązali twoje problemy; zrobią to w 1/10 czasu, z 1/10 liczby linii kodu. Brzmią świetnie.
Ale skąd wziął się ten termin? Czy one istnieją? A nawet jeśli tak, to czy chciałbyś być jednym z nich?
Tom DeMarco i Tim Lister od 1977 roku prowadzą „Coding War Games”. Jest to publiczne badanie produktywności, w którym zespoły implementatorów oprogramowania z różnych organizacji konkurują o ukończenie serii benchmarków w minimalnym czasie z minimalnymi defektami. Wzięło w nich udział ponad 600 programistów.
Czego się dowiedzieli?
- Wybór języka programowania miał niewielki wpływ – czy był to COBOL/Fortran, czy język wysokiego poziomu, jak Pascal, rozrzut wyników jest mniej więcej taki sam. Jedynym wyjątkiem był język asemblera.
- Nie było korelacji między doświadczeniem a wydajnością, z wyjątkiem tego, że osoby z mniej niż sześciomiesięcznym doświadczeniem z danym językiem nie radziły sobie tak dobrze jak inni.
- Deweloperzy rozwiązań o zerowej liczbie defektów nie płacili żadnej kary za wykonywanie bardziej precyzyjnej pracy (w rzeczywistości zajmowało im to nieco mniej czasu!).
Odkryli oni jednak, że istniały ogromne różnice między organizacjami. Najlepsza organizacja pracowała 11,1 razy szybciej niż najgorsza. Dodatkowo, ci, którzy pracowali najszybciej, opracowali kod, który przeszedł testy akceptacyjne. Sprawa zamknięta?
Cóż, nie do końca. Badanie następnie przechodzi do korelacji środowiska pracy (które jest różne w różnych organizacjach) z wydajnością. Okazuje się, że cicha, prywatna, dedykowana przestrzeń robocza była znacznie lepsza.
Lesson learnt – najpierw zadbaj o swoje środowisko pracy, zanim zaczniesz się martwić o to, czy znajdziesz 10x programistów, czy nie!
Programista produkujący ujemne wartości netto
Schulmeyer zauważa, że niektórzy programiści są „programistami produkującymi ujemne wartości netto” (NNPP), to znaczy produkują tak wiele defektów, że usunięcie ich z zespołu zwiększa produktywność. To prawie przeciwieństwo 10x dewelopera – możliwe jest posiadanie w zespole kogoś, kto go pogarsza.
Jeśli negatywni producenci istnieją (- Nx deweloperzy?) to oczywiście możliwe jest posiadanie 10x programisty (pomijając matematykę).
Nie jest to jednak najlepszy argument za 10x programistą, prawda? Jeśli poprosiłbym dziecko w wieku szkolnym, aby dołączyło do zespołu, czy byłoby ono producentem netto-negatywnym? Prawdopodobnie, jeśli pozwolę im siedzieć w kącie i walić w jakiś kod (i jeśli w jakiś sposób mogą pchnąć do produkcji!). Jeśli jesteś rodzajem firmy, która pozwala ludziom siedzieć w kącie, nie daje informacji zwrotnej i pozwala im pchać się do produkcji, to myślę, że prawdopodobnie zasługujesz na to, aby mieć NNPP w swoim zespole!
Bardziej realistycznie, mam nadzieję, że w każdej normalnej firmie, jeśli kogoś zatrudnisz, dasz mu całe wsparcie, którego potrzebuje, aby być niesamowitym w swojej roli (wzajemna weryfikacja kodu, informacje zwrotne, mentor, zautomatyzowana analiza kodu dla informacji zwrotnych, materiały szkoleniowe itp.)
Myślę, że nadal jest możliwe, że możesz skończyć z NNPP, ale podejrzewam, że jest to wysoce nieprawdopodobne. To z pewnością nie wydaje się być najlepszą historią dla istnienia 10x programistów.
Eksploracyjne badania eksperymentalne porównujące wydajność programowania online i offline
Sackman, Erikson, Grant opublikowali w 1968 r. Papier o nazwie „Eksploracyjne badania eksperymentalne porównujące wydajność programowania online i offline”. Jeden z cytatów na końcu dotyczy różnic indywidualnych, a badania „ujawniły duże różnice indywidualne pomiędzy wysoką i niską wydajnością, często o rząd wielkości”. Czy to może być ten magiczny papier, który opisuje tę 10-krotną różnicę?
Opłaca się przeczytać całe badanie i umieścić wokół tego jakiś kontekst. Po pierwsze, te testy porównywały zarówno wydajność pióra i papieru, jak i online przy użyciu IBM AN/FSQ-32. Programiści pisali swój kod (albo na długopisie/papierze, by dać go operatorowi, albo bezpośrednio do komputera) używając języka zwanego JTS (pochodna ALGOL-a).
Mieli dwa zadania do rozwiązania, pierwsze polegało na interpretacji równań algebraicznych z jedną zmienną zależną. Otrzymali papier autorstwa Samelsona i Bauera, który miał im pomóc w implementacji rozwiązania. Obrazek z pracy jest przedstawiony poniżej:
Drugie zadanie polegało na rozwiązaniu labiryntu 20×20, który ma dokładnie jedną ścieżkę. Labirynt był opisany 400-elementową tablicą, w której każdy wpis zawierał informacje o wyjściach z każdej komórki. Do tego zadania nie dołączono żadnych materiałów pomocniczych. Rozwiązywanie labiryntów to fascynująca przestrzeń problemowa i zgaduję, że ci, którzy niedawno ukończyli kurs teorii grafów, mieli dużą przewagę!
Znając te zadania, nie jestem zaskoczony, że istnieją duże różnice indywidualne. W 1968 roku inżynieria oprogramowania dopiero co narodziła się jako dyscyplina. Zadania są natury matematycznej i nie jest jasne, jakie było tło uczestników. To z pewnością faworyzowałoby tych, którzy wzięli kursy matematyki na wyższym poziomie.
Myślę, że 10x osoba, którą znajdziesz z tego jest utalentowana w rozwiązywaniu tych problemów. Mogę uwierzyć, że w przestrzeni problemowej „rozwiązywania labiryntu + równań liniowych” może istnieć 10x programista, ale trudno jest przenieść to do jakiejkolwiek innej domeny.
Czy powinienem być 10x programistą?
Prawdopodobnie. Ale prawdopodobnie 10x lepszy w pisaniu kodu.
W tej doskonałej książce znajduje się znacznie lepsza dyskusja na temat metodologii badań stojących za mitem 10x programisty. Nawet jeśli 10-krotny programista istnieje, prawdopodobnie nie powinieneś aspirować do bycia nim; nawet jeśli możesz zaimplementować kod idealnie za pierwszym razem, prawdopodobnie odkryjesz, że rozwiązywałeś niewłaściwy problem w pierwszej kolejności.
Nawet jeśli te badania byłyby prawdziwe, inżynieria oprogramowania poszła do przodu (przynajmniej w mojej domenie rozwoju produktu).
W dawnych czasach mogliśmy zrobić jedno duże wydanie w roku, mieć pewne wymagania i spędzić rok na ich wdrażaniu. Zmieniło się to na podejście zwinne, w którym istnieje ciągły cykl elicytacji, wyobrażania sobie, wdrażania i weryfikacji. W tym modelu, wdrożenie nie jest (zazwyczaj) wąskim gardłem
Godzina zaoszczędzona na non-bottleneck jest mirażem. (Eliyahu Goldratt)
Co więc powinieneś zrobić zamiast tego? Cóż, skup się na byciu bardziej wartościowym dla swojej firmy. Czy potrafisz:
- Zidentyfikować problemy wartościowe dla Twojej firmy?
- Zaprojektować rozwiązanie, z którego ludzie mogą korzystać?
- Zbierać informacje zwrotne, aby ocenić, czy jest wartościowe?
- Pisać oprogramowanie, które robi prawdziwą różnicę dla prawdziwych ludzi?
- Skupiać się na prawdziwych problemach, a nie na tym, co interesujące?
- Rozwijać członków zespołu, aby byli niesamowici?
I milion i jedna rzecz, która jest bardziej wartościowa niż pisanie doskonałego kodu w rekordowym czasie (patrz t-shaped!).
Nie chodzi o to, że kodowanie nie jest ważne. Kodowanie jest ważne! Kod jest czytany 4x częściej niż jest pisany, więc jeśli piszesz łatwy do zrozumienia kod to opłaca się to dramatycznie w przyszłości (może gdzieś tam jest historia 10x, ale zostawię to na inny dzień). Inwestowanie czasu w swoje rzemiosło (czy to kodowanie, czy projektowanie, czy zarządzanie projektami) jest koniecznością, ale pamiętaj, że twoje rzemiosło nie istnieje w izolacji i istnieje po to, aby służyć wyższym celom.
Nie skupiaj się tylko na byciu najlepszym programistą na świecie, skup się na szerszym obrazie (pamiętaj o przewadze produktu nad projektem!). Naucz się szerokiego zestawu umiejętności (szczególnie tych związanych z ludźmi), a będziesz o wiele bardziej wartościowy i o wiele bliższy prawdziwemu „developerowi” 10x.
.