bookmark_borderProgramista 10x

Programista 10x to osoba, której wydajność jest dziesięciokrotnie większa od przeciętnego inżyniera oprogramowania. Niektórzy nie wierzą, że jest to możliwe, inni twierdzą, że sami są programistami 10, a nawet 100x.

Czy programista 10x istnieje? Jak zostać programistą 10x?

Początki

Źródeł terminu można się dopatrywać w eseju Zespół chirurgiczny z książki Legendarny osobomiesiąc Freda Brooksa, w którym pisze on o różnicach w wydajności programistów:

…w skrócie programista zarabiający 20 000$ rocznie może być 10 razy bardziej produktywny od od tego, który zarabia 10 000$ rocznie. Jak również na odwrót…

Sama idea bycia 10x krążyła w środowisku biznesowym od dość dawna – bycia dziesięć razy lepszym, tworzenia produktu przewyższającego konkrencję, organizowania czasu w sposób optymalny i w ogóle bycia produktywnym najbardziej jak się da.

Wydaje się, że do narodzin terminu Programista 10x bezpośrednio przyczynił się Grant Cardone, autor Reguły 10x. Jego książkę wydano w 2011 i właśnie od tamtego czasu termin zaczął żyć własnym życiem:

Mit, czy rzeczywistość?

Wiele osób przeczy możliwości istnienia programisty 10x. Wydaje się, że niemożliwym jest, by jedna osoba była dziesięciokrotnie bardziej produktywna od drugiej. Jest w tym jednak mentalna pułapka. Mysleć tak można tylko patrząc na programowanie jak na sport lub pracę fizyczną, w której jeden robotnik na taśmie nie może być znacząco szybszy od drugiego, gdzie wybitny sprinter nie przebiegnie dystansu czterokrotnie szybciej od konkurentów choćby był półbogiem.

Programowanie to dziedzina intelektualna, a inteligencja nie skaluje się liniowo.

Jakiś czas temu Jordan Peterson podczas jednego ze swoich wykładów, IQ, a rynek pracy, zaprezentował tabelę, w której rozpisał zalecane zawody odpowiadające różnym poziomom ilorazu inteligencji. Przykładowo przedział 87-93 IQ predestynować miałby do bycia pakowaczem lub dozorcą, zaś do bycia programistą zalecał kanadyjski psycholog coś pomiędzy 100, a 115.

Oczywiście IQ nie jest miarą programistycznego mnożnika. Warto o tym jednak pamiętać, że to geniusze posuwali ludzkość do przodu, że bez kilku tysięcy zaledwie wybitnych osób nie mielibyśmy elektryczności, silnika spalinowego, czy telefonii komórkowej.

Nie ma wątpliwosci, że jest możliwe, iż jedna osoba będzie umysłowo wielokrotnie bardziej wydajna od innej.

Cechy

Kim trzeba być by zostać programistą 10x? Co mają ze sobą wspólnego wysokowydajni inżynierowie oprogramowania?

Pewnie, by z należytą starannością odpowiedzieć na to pytanie trzebaby przeprowadzić badania, wziąć pod lupę takich programistów jak Linus Torvalds, Donald Knuth, Niklaus Wirth, Guido van Rossum, czy Dennis Ritchie.

Na to jednak czasu nie ma, więc trzeba pogdybać. Zacząłbym jednak od tego, że niekoniecznie musi to być osoba o wysokim IQ. Programowanie to nie fizyka teoretyczna. Inne cechy osobowe są tu równie istotne.

Pasja, profesjonalizm i odpowiedzialność

To te trzy cechy postawił bym na pierwszym miejscu ex aequo.

Nie wyobrażam sobie bycia efektywnym programistą nie pasjonując się swoim zawodem. Banał, a jednak jest to rzecz kluczowa. Nawet jeśli programistą zostaliśmy z pasji do bezpieczeństwa finansowego i klimatyzowanego biura, to wierzę, że da się zapałać miłością do pisania kodu. Bez niej trudno nam będzie wybić sie przed szereg.

Profesjonalizm to szeroki temat. Na pewnym forum przeczytałem kiedyś interesujące sformułowanie bazujące na zasadzie Pareto: 80% osób pracujących w dowolnym  zawodzie wykonuje go nieprofesjonalnie, jedynie 20% to prawdziwi specjaliści. W dużej mierze jest to spostrzeżenie trafne. Przy odpowiedniej dozie samokrytyki przyznamy autorowi rację.

Być profesjonalnym programistą oznacza dla mnie przede wszystkim traktowanie swojej pracy poważnie. Nieprofesjonalne jest:

  • pisanie kodu złej jakości
  • wybieranie technologii tylko dlatego, że nie chce nam się uczyć nowej
  • wybieranie technologii tylko dlatego, że chcemy się jej nauczyć
  • wszelkie formy lenistwa
  • nadmierna pedanteria

Programista 10x – jeśli można go opisywać przez brak – tych cech miał nie będzie. Wysoka jakość pracy, chłodne, analityczne podejście do wyboru narzędzi, pracowitość, pragmatyzm. Taki zestaw cech bez wątpienia podniesie naszą wydajność, jeśli nie dziesięciokrotnie, to przynajmniej dwukrotnie.

Ostatnia rzecz to odpowiedzialność – programista odpowiedzialny nie będzie obiecywał gruszek na wierzbie, nie będzie twierdził, że wykona produkt choć doskonale zdaje sobie sprawę, że w zadanym budżecie i czasie nie uda się zachować choćby minimalnej wymaganej przez zdrowy rozsądek jakośći. Programista wydajny będzie też odpowiedzialny w tym sensie, że nie będzie zaciągał bez wiedzy managementu długu technicznego, chwaląc się potem swoją wydajnością, a po cichu pozostawiając problem swoim następcom i firmie.

Warunki pracy i zaangażowanie

Nie wszędzie da się być wysokowydajnym. Jeśli jedno przedsiębiorstwo dysponuje łopatą, a drugie koparką, to siłą rzeczy nawet najbardziej zmotywowany, silny, zdrowy i wydajny kopacz rowów nie będzie bardziej efektywny przy użyciu łopaty.

Programistę 10x mogą pomóc stworzyć warunki pracy polegające na zapewnieniu mu dobrego sprzętu, świętego spokoju bez przerywania co chwila pracy, dostępu do wiedzy i partnerskiej, profesjonalnej relacji z przełożonymi.

Programista 10x jest bez wątpienia osobą bardzo, ale to bardzo zaangażowaną, wewnętrznie zmotywowaną. Być może lubi swoją pracę, może wierzy w projekt, możliwe, że ma w sobie ogromną dyscyplinę. Jaki by nie był powód – bez zaangażowania nie będzie pracowitości, a bez niej nie będzie efektu.

Podsumowanie

Programista 10x to ideał. Wymarzony pracownik każdej firmy, dla której tworzenie oprogramowania jest kluczowe. Można jego narodziny wspomóc tworząc odpowiednią strukturę organizacji, ale trzeba też umieć znaleźć go na rynku pracy. Warto jednak. Warto poświęcić czas, poszukać go, doskonale opłacić i wykorzystać ten rzadki talent. Być może dzięki tej jednej, kilku osobom to nasza organizacja będzie kolejnym gigantem, może to u nas powstanie przełomowa technologia, genialny produkt…

bookmark_borderStare spaghetti, czysta wódka i wujek Zdzisiek

Ktoś mnie ostatnio nazwał clean code evangelist. Pomyślałem – tytuł zobowiązuje. Trzeba napisać o czystym kodzie.

Co jednak napisać? Wszystko już było. Nic nowego pod słońcem. Krótkie metody, znaczące nazwy i ogólnie takie, takie. Co mógłbym ja, prosty programista, napisać o czystym kodzie pod koniec drugiej dekady XXI wieku? Dekady jaśniejącej tysiącem frameworków JavaScriptowych, dziesięciolecia mikroserwisów, chmury i dev-ops!

Metafory. Metafory zawsze służyły ludzkości. Horacy, Nostradamus, Popek. Wszyscy oni używali mglistego języka przenośni, by oddać esencję. Spróbujmy.

Spaghetti jest dobre, spaghetti smaczne jest, świeże spaghetti jest jak listek bazylii na pizzy, jak zapach wydechu Fiata w wąskiej uliczce Turynu, jak szynka parmezańska obsypana rukolą. Wszyscy lubimy gotować spaghetti. 8 minut i gotowe. Cottura 8 minuti i włala.

Kod spaghetti jest taki sam. Świeżo przygotowany pachnie soczystymi kaskadami ledwie widocznych zależności. Ma smak długich jak przedrelease’owe wieczory metod z posmakiem enigmatycznych nazw zmiennych, nazw dojrzewających w pełnym słońcu wschodzącego deadline’u.

Niestety, spaghetti nieskonsumowane przekształca się w to samo mniej więcej, co skonsumowane.

Spaghetti dojrzałe powoduje zaparcia, bóle głowy, a nawet rozwolnienia. Kod spaghetti tak samo – przydatny jest do spożycia w krótkim jedynie terminie.

Zastanawiając się, jaki pseudonim musiałbym sobie wybrać by zostać polskim Uncle Bob’em doszedłem do wniosku, że mógłbym być wujkiem Zdziśkiem. Na potrzeby tego i kolejnych akapitów – zostanę nim.

Posłuchajcie wujka. Wujek życie zna. Wujek pracował nad jednym projektem do emerytury w zakładzie pracy państwowym, nad projektem rządowym i wujek wie co to znaczy nieświeże spaghetti.

Rada wujka: kod ma być jak wódka.

Tak. Jak wódka ma być!

Wódka, jaka jest, każdy widzi. Jak koledzy z zespołu kod wódkę zobaczą, to przysiądą się, zaczną delektować się kodem wódką, zadowoleni będą, radośni. Kod wódka doskonale się integruje. Kod wódka nie ma zależności – można z ogórkiem, można z colą, wszystko co interfejs zakąska implementuje być może. Kod wódka powoduje najmniejszego kaca, o ile potrafimy go okiełznać.

Reasumując: kod ma być, jak wódka, czysty.

Tako rzecze wuj Zdzich.

bookmark_borderProgramowanie jest łatwe

Wiele osób, które nie miały wcześniej styczności z programowaniem myślą, że jest ono trudne. Częściowo wynika to z przekonania, że ma ono duży związek z matematyką, trochę z nieczytelnego wyglądu niektórych języków programowania, a odrobinę też z tego, że niektórzy ludzie z branży lubią pozować na magików, którzy zaklinają cyfrowe węże.

Prawdę powiedziawszy podstawy programowania są łatwe.

Element pierwszy: zmienne

Koncepcja zmiennej jest prosta, jak konstrukcja cepa. Mamy coś co ma nazwę i wartość oraz typ. Na przykład:

nazwa: ilość pieniędzy na koncie
wartość: 7000
typ: liczba

nazwa: imię mojego dziecka
wartość: Maciek
typ: litery

Element drugi: warunki

Warunki są koncepcją równie prostą, jak zmienne. W zależności od czegoś robimy coś albo coś innego. Banał.

Przykład:

Jeśli 
       data urodzin mojego dziecka jest równa dacie dzisiaj

To
       będę robić tort

Element trzeci: pętle

Pętle wykonują coś wiele razy. Proste? Proste.

Przykład:

Dopóki flaszka jest pełna
       nalej do kieliszka a potem wypij

Język

Oczywiście na końcu trzeba to wszystko zapisać w jakimś języku programowania. Kiedy ludzie myślą o nauce języka zwykle są przerażeni. Przychodzi im na myśl od razu ta wredna germanistka z podstawówki, rodzajniki, odmiana i czasy. I tysiące, nieskończone tysiące słówek do nauczenia.

Języki programowania są łatwe. Gramatyki prawie nie ma, a słów jest kilka.

Naprawdę.

Definicje zmiennych?

liczba: number;
napis: string;

Warunki?

ilośćCiastek = 5;
 if ( ilośćCiastek > 0 ) {
        jedzCiastka();
 }

Pętle?

while ( flaszka.czyJestPelna() ) {
        człowiek.pij()
 }

Oczywiście to są podstawy. Oczywiście jest dużo gorzej. Jednak nikt mi nie wmówi, że te podstawy są jakieś strasznie skomplikowane, że programowanie to matematyka i gramatyka niemiecka albo jeszcze gorzej.

Programowanie jest łatwe. I fajne!

bookmark_borderProject managerowie go nienawidzą! Programista z korpo odkrył jeden prosty trik jak wysadzić projekt w powietrze przy użyciu Jiry.

Za górami, za lasami, za siedmioma routerami, był sobie projekt. Był dobry. Deadline był odległy, a budżet zatwierdzony. Zespół liczny, doświadczony. Pomysł na produkt miał ręce i nogi.

Co mogło pójść nie tak?

Zabraliśmy się do pracy. Spotkania, telekonferencje, ustalenia. Planowanie za planowaniem, meeting za meetingiem, sprint za sprintem. Szybko okazało się, że głównodowodzący projektem ma osobowość radiowego spikera. Człowiek ten uwielbiał rozmawiać, mówić, przemawiać i omawiać. Nie ma w tym nic złego. Dobrze jest być towarzyskim. Projekt był rozproszony geograficznie, więc siedziało się na słuchawce godzinami, ale jeśli trzeba coś omówić, to przecież naturalne.

Po rozmowie wypadałoby zacząć pracę, a ustalenia spisać. Nasz lider jednak lubił jedynie mówić. Zadania, jakie dla nas tworzył składały się zwykle z jednozdaniowego opisu staniowącego tytuł.

Projekt trwał i trwał, postępy nie były imponujące. Nadszedł sezon urlopowy. Nasz lider również postanowił udać się na zasłużony wypoczynek. Dwutygodniowy. Przed opuszczeniem biura zorganizował – a jakże! – spotkanie, na którym omówił zadania, jakie przed nami stały. Wydawało nam się, że zrozumieliśmy jego intencję. Dla uspokojenia przekazał nam kontakt do dwóch osób, które miałyby rozwiać nasze wątpliwości w razie, gdyby takowe zaistniały.

Przyszedł kolejny tydzień. Zajrzeliśmy do notatek, zajrzeliśmy do zadania (z jednozdaniowym opisem). Po kilkunastu minutach pojawiły się wątpliwości. Po godzinie rozmawialiśmy z pierwszą osobą, jaka miała nas wspomóc. Okazało się, że zrozumiała naszego lidera inaczej, niż my. Zaniepokoiło nas to. Zadzwoniliśmy do kolejnej. I ona zrozumiała inaczej. Tyle tylko, że nie inaczej niż my, ale również inaczej niż pierwsza osoba. Mieliśmy trzy interpretacje i dwa tygodnie bez autora.

Puenta okazała się zaskakująca. Gdy lider wrócił z urlopu i zaczęliśmy drążyć, jak konkretnie mamy wykonać zadanie i na czym ma ono polegać, po kikudziesięciu minutach kluczenia przyznał, że nie wie.

To najjaskrawszy, z jakim miałem do czynienia, przykład jednego z grzechów programistów – pobieżnego opisywania tasków. Oczywiście nie można być pedantem i opisywać ich przesadnie szczegółowo, ale pewien sensowny poziom detalu i dbałości jest wymagany, by projekt nie eksplodował spotkaniami.

Zastanówmy się. Bierzemy do ręki, na warsztat nowe zadanie. Czytamy opis i połowy z niego nie rozumiemy. Co robimy? Idziemy do autora. Jeśli autor jest z biznesu, to pewnie jest na spotkaniu i nie idziemy, a wysyłamy mail. Czekamy albo bierzemy inne zadanie. Jeśli inne są równie dobrze opisane, to piszemy kilkanaście maili zanim uda nam się zabrać do roboty. Jeśli natomiast autor jest programistą z zespołu to idziemy do niego i… odrywamy go od pracy w skupieniu, przychodząc z naszym  pytaniem.

W obu scenariuszach tracimy czas. Wszyscy. Czas i efektywność.

Opis zadań powinien być precyzyjny, napisany prostym językiem i wystarczająco dokładny, żeby zrozumiała go osoba, która nie posiada naszej wiedzy, a wiedzę wspólną dla członków zespołu. Nie możemy wychodzić z założenia, że jak nie wie to dopyta. To nieefektywne, szkodliwe, złe. To tworzy kulturę rozproszeń, chodzenia od biurka do biurka w nieustającym rytuale dopytywania, ustalania, marudzenia jeden drugiemu. Programista powinien móc jak najdłużej pracować w skupieniu. Tylko tak tworzy się sprawnie dobrej jakości oprograowanie.

Opisuj taski. Opisuj je dobrze. Jeśli nie umiesz ich dobrze opisać, to może nie wiesz w ogóle co jest do zrobienia?