Tag: produktywność

bookmark_borderTechnologiczno-narzędziowa zasada Pareto

Posted on by kalkus
narzędzia

Reguła Pareto jest ciekawą i dość znaną obserwacją. Mówi o tym, że większość rezultatów ma swoje źródła w mniejszości przyczyn. Na przykład w 1989 roku na najbogatsze 20% populacji przypadało 80% światowego PKB. Innymi słowy – to co z pozoru niewielkie zwykle wiele znaczy. To zaś co dominujące często nie jest aż tak ważne.

Jakiś czas temu rozpocząłem współpracę z nowym klientem. W kwestii używanych technologii nie różni się od innych – te same frameworki, języki i charakter pracy. To co go wyróżnia to podejście do narzędzi. Zamiast przeciętnego laptopa z Windowsem i mnóstwem korpo-oprogramowania konsumującego zasoby – MacBook. Zamiast siermiężnych Teamsów – Slack. W miejsce Outlooka – Google Workspace.

Wydawać by się mogło, że 80% wyniku powinny dawać technologie. Tymczasem okazuje się, że narzędzia, które zdają się być tymi paretowskimi dwudziestoma procentami – potrafią zabić lub ożywić produktywność programistów.

Z pozoru niewielkie spowolnienie powodowane przez ociężałe, niedostosowane do wymagań działów IT korporacyjne proxy, antywirusy i innego rodzaju oprogramowanie monitorujące jest w stanie ograniczyć wydajność programisty – moim zdaniem – nawet o połowę. Coś co w normalnych warunkach zajmuje 2 minuty może w takim środowisku zająć minut 10, a to już wystarczająco, by deweloper się zirytował i rozproszył. 2 minuty pozwolą pozostać we flow, a 10 minut frustracji przerodzi się w wizytę w kuchni albo chill-roomie, a następnie w kolejne kwadranse spędzone na powrocie do skupienia.

Podobnie sprawa ma się w zasadzie ze wszystkimi narzędziami. Oczywiście wybór dramatycznie złej technologii może mieć nawet poważniejsze konsekwencje – zastanówmy się jednak, czy tak naprawdę mamy wybór? Rynek pracy w ostatnich latach jest zdecydowanie rynkiem pracownika. Rekruterzy piszą już nawet ogłoszenia wierszem i ogłaszają się na egzotycznych portalach, byle tylko zachęcić koderów do zmiany pracodawcy. To trendy rynkowe decydują obecnie o wyborze technologii, a nie rozsądna, chłodna, inżynierska analiza. Mało kto będzie dziś na tyle odważny by prowadzić projekt np. w Ext JS. O narzędziach jednak decydować wciąż można. I często decyduje się zdecydowanie wbrew preferencjom programistów. A choć gazety lubią się w sensacyjnym tonie rozpisywać o ich rozpieszczeniu, to jednak ich sympatie względem pewnych narzędzi wynikają po prostu z tego, czy są one wygodne, czy nie. Wygodne, czyli pozwalające sprawnie wykonywać pracę. A mało co potrafi być tak irytujące jak codzienne pytanie na daily – czy coś cię blokuje – gdy wiemy, że są to narzędzia, których firma nie ma ochoty zmienić.

Dlatego warto przemyśleć, jakie narzędzia lubimy, które uważamy za najlepsze. Jeśli zarządzamy i decydujemy – dobrze słuchać w tej materii koderów. Jeśli zaś programujemy – warto przed zmianą pracodawcy lub klienta zapytać, z jakich narzędzi będziemy mogli korzystać? Może to być o pytanie o wiele ważniejsze niż mogłoby się wydawać…

bookmark_borderPrototyp, głupcze!

Posted on by kalkus

Tworzenie oprogramowania jest jednym z najbardziej złożonych przedsięwzięć, jakich podejmuje się nasza cywilizacja. Nie dotyczy to co prawda każdego projektu, istnieją rzeczy proste, trywialne, ale nawet za nimi ciągnie się ogon bibliotek, systemów operacyjnych, procesorów i całej koncepcji programowania, wraz z algorytmami, maszyną turinga i językami formalnymi. Są jednak również projekty same w sobie niezwykle skomplikowane – systemy tradingowe, symulacje fizyczne, oprogramowanie symulujące zwijanie białek…

Rękodzieło

Mimo całej tej złożoności, jest w programowaniu duch rękodzieła.

Pracujemy nieraz nad arcydziełami koronkowej abstrakcyjnej twórczości, rozpiętymi na setki tysięcy linii kodu w sposób jakbyśmy toczyli wazę za czasów dynastii Han.

Poniżej przykładowa waza. Piękna rzecz, ale od czasu panowania dynastii Han, 206 BC–220 AD, trochę czasu minęło…

Co złego w toczeniu wazy? Niby nic. Tyle, że w przypadku wazy można, jak sądzę, nadać jej jakiś początkowy kształt, a potem malować kolejne fragmenty nieco improwizując. Tutaj smok, tam feniks, jakiś ornamencik.

I często wychodzi ładnie.

Gorzej jednak, kiedy przełożymy to na programowanie. Robimy jakieś MVC, tam dwa przyciski, tu jakiś dropdown, pod spodem kontrolerek i repozytorium i jakoś to będzie.

I czasami wychodzi ładnie.

Warto by jednak było, zanim zaczniemy implementować, lepić, klecić i klepać, zastanowić się, co tak w zasadzie system ma robić. Bo co waza ma robić, to wiadomo, a czy będzie miała dwa smoki i i trzy feniksy, czy też pięć ornamentów i jednego smoka, to już detal, o ile się je ładnie namaluje. Trochę też krócej się tworzy taką wazę. Gorzej jednak, jak w trakcie lepienia naszej wazy-MVC przychodzi klient i mówi, że chce czajnik. I jeszcze raz za dwa tygodnie i dodaje, że elektryczny…

Agile w dwójnasób

Wydawać by się mogło, że brak planu na początku projektu może wynikać z dominacji Agile na rynku. Promuje ona tworzenie jak gdyby ad hoc, w krótkich odcinkach czasu. Sądzę jednak, że brak planu to coś naturalnego, amatorskiego. Tak projekty tworzą studenci. Siadają do kompilatora i próbują. Próbują, piszą, nie planują. Miło jest coś zacząć, dać się pochłonąć entuzjazmowi. Mniej sympatycznie jest tworzyć plan, analizować, przewidywać problemy, a potem tego planu się trzymać.

Jest taka słynna grafika w świecie Agile. Ilustruje tworzenie MVP na przykładzie budowania samochodu. Znalazłem swego czasu ciekawszą:

Przez pewien czas sądziłem, że w istocie jedynie dolny rysunek ukazuje właściwą drogę, a tradycyjny przykład z hulajnogą, rowerem, motocyklem i samochodem jest błędny.

Tymczasem oba są poprawne. W zależności jednak od sytuacji.

Wyróżniłbym dwa modele tworzenia produktu:

  • kreatywny
  • konserwatywny

Produkt tworzony kreatywnie może wyewoluować w dowolnym kierunku. Przykładowo – projektujemy pierwszy smartphone. Nie wiemy jak ma wyglądać. Produkt może ewoluować znacząco, a feedback od klienta jest kluczowy i ma prawo kompletnie zmienić produkt.

Produkt tworzony konserwatywnie jest czymś, co już istnieje na rynku i nie planujemy go rewolucjonizować (albo czymś coś wręcz wiemy jak ma wyglądać, bo wynika z regulacji rynku, ustawy itp.). Chcąc zbudować nowy model samochodu nie ma sensu tworzyć hulajnogi. Możemy poeksperymentować z nadwoziem, wyposażeniem, ale nie z samą koncepcją auta.

Prototyp

Wydawać by się mogło, że prototypowanie jest czymś oczywistym. Pisarze tworzą pierwsze szkice, które potem udoskonalają, ubierają w szczegóły, a czasami zupełnie przerabiają. Malarze zwykle zaczynają obraz od zarysowania głównych jego elementów, również tworząc na początku coś w rodzaju prototypu. Projekty samochodów zawsze zaczynają się od produkowanych w jednym, czy kilku egzemplarzach wersji demo. Tymczasem w oprogramowaniu bywa różnie.

Widziałem projekty, gdzie nigdy niczego nie prototypowano. Proces tworzenia oparty był o pełną implementację w każdym sprincie. Zupełnie bezrefleksyjnie marnotrawiono czas, choć można było narysować na kartce propozycje rozwiązań i dojść do konsensusu miesiące szybciej.

Moim zdaniem każda aplikacja, która posiada interfejs graficzny (co stanowi sporą część, jeśli nie większość rynku) MUSI zacząć się od designu, następnie przejść w „klikalny” prototyp, by w końcu zostać w pełni zaimplementowana.

Stworzenie designu ułatwia zrozumienie produktu i zadawanie właściwych pytań. Większość osób jest wzrokowcami i potrzeba im wizualnej reprezentacji tego, nad czym mają podjąć pracę.

Prototyp z kolei pozwala dostarczyć klientowi coś namacalnego w czasie o wiele szybszym od pełnej implementacji. Rozwiązuje to frustrację biznesu związaną z czekaniem na pierwszy rezultat. Nic pewnie nie irytuje bardziej, niż słuchanie przez dwa miesiące technicznych sprawozdań bez możliwości ujrzenia wyniku pracy, jeśli zainwestowało się kilkadziesiąt lub kilaset tysięcy złotych w rozwój produktu.

W wielu firmach specialiści od UI i UX są bagatelizowani lub w ogóle się ich nie zatrudnia. To błąd. To gigantyczne przeoczenie. Ich praca to nie tylko rysowanie okienek – ich wysiłek ułatwia wszystkim zrozumienie produktu oraz pracę nad nim. Projekty zaczynajmy od szkicu, designu, przechodźmy do prototypu, a kończmy na implementacji!

bookmark_borderKomunikacja asynchroniczna

Posted on by kalkus

Kiedy myślimy o zespole programistów, a konkretnie o jego wydajności – przychodzi nam na myśl zapewne jego doświadczenie, motywacja, czy uzdolnienia. Tymczasem sposób w jaki porozumiewają się członkowie zespołu może zaoszczędzić lub roztrwonić znaczące ilości czasu.

Komunikację w zespole można rozróżnić na synchroniczną i asynchroniczną. Pierwsza oznacza, że nadawca i odbiorca wiadomości muszą w tym samym czasie skupić swoją uwagę. Drugi rodzaj pozwala na odpowiedź po pewnym czasie.

Dominujący rodzaj komunikacji w zespole deweloperskim ma fundamentalne znaczenie dla jego wydajności.

Jeśli zespół komunikuje się synchronicznie, to każda rzecz wymagająca wyjaśnienia rozprasza programistów. Oderwanie dewelopera od kodu, choćby na pięć minut, rujnuje jego skupienie i obniża produktywność.

Przykłady komunikacji synchronicznej:

  • programista czegoś nie wie i potrzebuje zadać pytanie, wstaje, idzie do biurka kolegi i pyta
  • product owner odpowiada na pytania podczas regularnych spotkań, gdzie omawiane są po kolei wątpliwości różnych osób
  • tester nie wie jak przetestować zadanie, podchodzi do programisty i pyta
  • programista potrzebuje pomocy w debugowaniu, podchodzi do pierwszego z brzegu kolegi i prosi o pomoc

Marnujemy w ten sposób dużo czasu i energii. Z pozoru jest łatwiej – nie musimy czekać na pomoc, możemy omówić coś na żywo, wydawać by się mogło bardziej dogłębnie, a jednak… podczas spotkań głównie czekamy na swoją kolej, w trakcie pracy przy biurku współpracownicy przerywają nam flow.

Komunikacja asynchroniczna dla sporej ilości osób jest nieintuicyjna, ma jednak ma wiele zalet:

  • pozwala osiągać długie okresy skupienia
  • pozostawia pisemny ślad, do którego można się odwołać, który można przeszukiwać po jakimś czasie
  • pozwala udzielać bardziej przemyślanych, szczegółowych odpowiedzi na pytania

O ile dla pracowników “z biznesu” asynchroniczność może wydawać się dziwna, o tyle dla programistów powinna być oczywistością. Każdy przecież wie, że ponowne załadowanie kontekstu zajmuje czas, że czekanie na odpowiedź serwera blokuje wykonanie programu. Mimo to – w realnym życiu często zdarza nam się o tych zasadach zapominać.

Przykłady komunikacji asynchronicznej:

  • product owner odpowiada na pytania mailowo, nie natychmiast, ale sprawnie
  • tester zamiast pokazywać programistom problemy opisuje je słownie albo nagrywa filmy pokazujące błędy
  • programista mający pytanie zadaje je na slacku lub mailowo, a osoby z zespołu w momencie, gdy nie potrzebują skupienia odpowiadają mu

Najbardziej efektywne zespoły, w jakich miałem przyjemność pracować komunikowały się w dużym stopniu asynchronicznie. Analogicznie – najbardziej niewydajne, omawiały godzinami na spotkaniach w dużych grupach kwestie, które mogły zostać omówione w e-mailu.

Warto pochylić się nad sposobem w jaki organizujemy sobie pracę i dostrzec wzorce, a następnie zastanowić się, czy nie sabotujemy własnej produktywności złymi praktykami.

bookmark_borderProgramista 10x

Posted on by kalkus

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…