Po raz kolejny dałem się złapać na ten sam chwyt. Jak widzę, że na Helionie jest promocja, nie mogę się powstrzymać i zawsze kupuję jakąś książkę. Dobrze, jeśli kończy się tylko na jednej. Tym razem padło na „Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja” autorstwa Sandro Macuso, która została wybrana przez Helion książką roku 2017 w kategorii programowanie. O książce wiedziałem już wcześniej, ale nie byłem do niej dobrze nastawiony, ponieważ bycie rzemieślnikiem w programowaniu kojarzyło mi się ze żmudnym wyrabianiem godzin i klepaniem ciągle tego samego kodu. Ciekawe, kto chciał by napisać książkę na ten temat. Tak naprawdę ruch Software Craftsmanship promuje postawę ciągłego podnoszenia swoich umiejętności, dbania o jakość dostarczanych produktów i udoskonalania swojego programistycznego warsztatu. Celem jest dążenie do mistrzostwa w swojej profesji.

Różnica między zawodem programisty a tradycyjnymi profesjami

W zawodach o wieloletnich tradycjach, takich jak np. inżynier budownictwa, lekarz, czy prawnik, pracownik przez wiele lat pnie się po szczeblach kariery dostając coraz bardziej odpowiedzialne zadania. Zanim spotka go awans, musi jakiś czas spędzić na każdym poziomie. W branży IT ten proces przebiega znacznie szybciej i już mając kilka lat doświadczenia można zostać seniorem. Ma to swoje zalety i wady. Jedną z wad może być rozwijające się w programiście przeświadczenie o własnej wielkości powodujące brak pokory, zaprzestanie rozwoju i przekonanie o własnej nieomylności.

Inną cechą charakterystyczną branży IT jest to, że technologie bardzo szybko się zmieniają i doświadczenie liczone w latach nie musi być dobrą miarą umiejętności. Autor książki uważa, że 10 lat przepracowanych w tej samej firmie przy tym samym projekcie wykonujac cały czas te same zadania to tak naprawdę 1 rok doświadczenia powtórzony 10 razy. Odpowiedzią na szybko zmieniające się warunki jest ciągłe podnoszenie własnych umiejętności oraz dzielenie się swoją wiedzą z innymi. Nie wszyscy akceptują taki stan rzeczy, o czym trochę z przymrużeniem oka można przeczytać tutaj. Na zachętę mały cytat z tego linka:

I tutaj jest pies pogrzebany; nauczyciel, lekarz mają PAPIER na te swoje umiejetnosci, na swoją fachowosc. Jesli czegos zapomna to sobie przypomna, natomiast papier jest, to jest stale i daje jakas pozycje zyciowa.

A taki nedzny programista? Co on ma? Jaki on ma papier ?Najwyzej toaletowy.
Nie ma zadnego papieru na to kim jest, co umie w efekcie czego pozostaje mu uczyc sie bez przerwy, ciagle udoskonalac i swoja fachowosc CIĄGLE MUSI UDOWADNIAĆ.

To strasznie niepowazne, zdecydowanie nie dla 30+letniego mezczyzny ktory chce juz cos soba reprezentowac.

Kac agilowy

Zasady zwinnego wytwarzania oprogramowania zostały sprecyzowane w manifeście na początku XXI wieku i od razu zyskały wielką popularność. Od tego momentu każda firma z branży IT chciała być zwinna i zaczęła odchodzić od kaskadowych procesów produkcyjnych znanych z fabryk zastępując je krótkimi iteracjami, tablicami pełnymi karteczek samoprzylepnych i nowymi rodzajami spotkań. Kierunek, w którym rozwinął się ruch Agile był krytykowany nawet przez twórców manifestu:

Autor książki wpisuje się w ten głos i twierdzi, że źle rozumiany Agile skupia się tylko na zmianach organizacyjnych w zespole projektowym zaniedbując metody techniczne będące drugim równoprawnym filarem zwinnego wytwarzania oprogramowania. Chodzi głównie o metody Extreme Programming takie jak Test Driven Development, programowanie w parach, czy Continuous Integration. Zmiany organizacyjne w jakimś stopniu mogą poprawić efektywność, ale same w sobie nie spowodują, że zmniejszy się ilość błędów w kodzie. Ruch Software Craftsmanship ma za zadanie czuwać nad zwiększaniem jakości wytwarzanego oprogramowania i w tym celu sformułował swój własny manifest. Ruch jest przeciwwagą dla podejścia popularnego w biznesie, gdzie liczy się osiągnięcie krótkotrwałych celów i poprawne działanie oprogramowania w dłuższym okresie czasu schodzi na dalszy plan.

Zdobywanie wiedzy

Podnoszenie swoich umiejętności jest motywem przewodnim książki. Autor zachęca do korzystania w tym celu z książek, portali społecznościowych, blogów, a także do prowadzenia własnych projektów i udzielania się w projektach open source. Bardzo zaciekawił mnie dokonany podział książek branżowych na:

• techniczne – mówiące o konkretnych językach, narzędziach itp. Takie książki szybko pozwalają polepszyć konkretne umiejętności.
• pojęciowe – mówiące ogólniej o pewnych technikach jak np. TDD, czy programowanie funkcyjne. Przyswojenie wiedzy z takich książek wymaga więcej wysiłku, ale można ją stosować w różnych kontekstach.
• behawioralne – mówiące o jakiś postawach i wzorcach zachowań. Wiedzy z takich książek nie da się wprowadzić z dnia na dzień i poprawianie wspomnianych postaw może trwać nawet całe lata.

Jako oddzielna kategoria podane są książki przełomowe uznawane za klasykę gatunku, których znajomość przyda się każdemu programiście niezależnie od technologii z jakich korzysta, ponieważ stają się kamieniami milowymi w rozwoju branży, a odwołania do nich znajdują się w wielu innych publikacjach czy dyskusjach. Takie książki to np. Pragmatic Programmer, Clean Coder, Extreme Programming Explained. Książki przełomowe najczęściej zaliczają się do grupy behawioralnych lub pojęciowych, albo mieszanych. Rzadkością są przełomowe książki o charakterze technicznym, ale takie również się zdarzają np. K&R.

Swoje kwalifikacje powinniśmy podnosić inwestując własny czas i pieniądze. Jeżeli w firmie, w której pracujemy nie ma kultury podnoszenia umiejętności i nie mamy dostępu do książek, konferencji, czy szkoleń, nie może nas to ograniczać. W książce są również opisane praktyki firm, które chęć podnoszenia umiejętności swoich pracowników mają rozwinięte do poziomu, którego nawet nie byłem sobie w stanie wyobrazić. Przykładem jest opisana wymiana programistów pomiędzy firmami po to, żeby popracowali przez jakiś czas w innych projektach, wymienili się doświadczeniami i podnieśli swój warsztat. Dzięki temu programista może się czegoś nauczyć od osób z zewnątrz, ale może również wnieść do projektu świeże spojrzenie i jakieś nowe praktyki.

Autor w wielu miejscach wychwala programowanie w parach i proponuje wiele, czasem niekonwencjonalnych, zastosowań tej techniki. Jednym z nich jest wykorzystanie jej jako element procesu rekrutacji. Inne zastosowanie to programowanie w parze z developerem z innego zespołu. Jest to sposób na pokonanie rutyny w projekcie, polepszenie przepływu wiedzy i możliwość walidacji poczynionych decyzji projektowych. Jeszcze innym zastosowaniem programowania w parach są wspólne ćwiczenia. W ramach ćwiczenia robimy jakieś zadanie np. z kode kata i skupiamy się na nauczeniu czegoś nowego np. innego języka, IDE, metodologii. Zdaniem autora idealną sytuacją jest wspieranie tego typu inicjatyw zarówno przez firmę, jak i pracowników. Aby podkreślić zaangażowanie obu stron sesje ćwiczebne mogą się odbywać przez 2 godziny – jedna godzina z czasu pracy, a druga z czasu wolnego pracownika.

Wprowadzanie zmian

Kilka rozdziałów zostało poświęconych temu jak wprowadzać dobre praktyki do swojego środowiska pracy. Nie jest to zadanie proste, ponieważ nie dość, że sami musimy w sobie znaleźć motywację do rozwoju, poznawania tych praktyk i wcielania ich w życie, to jeszcze musimy przekonać do tego przełożonych i współpracowników. Autor udziela wielu praktycznych wskazówek jak to zrobić. Do osób zarządzających trzeba mówić ich językiem. Zamiast wchodzić w szczegóły techniczne, należy pokazać jak proponowane praktyki przyczyniają się do mniejszej ilości błędów, szybszego wprowadzania zmian i dodawania nowych funkcjonalności. Często większym problemem jest opór innych developerów. W książce zostało opisanych wiele postaw osób nastawionych sceptycznie. Możemy wyróżnić osoby, które:

• chcą tylko odwalić zadaną robotę i iść do domu,
• nauczyły się coś robić w konkretny sposób i boją się zmian,
• są zawalone robotą i nie mają czasu na eksperymenty,
• kiedyś próbowali coś zmienić, ale im się nie udało i się poddali,

i kilka innych grup. Zdaniem autora przekonanie takich osób sprowadza się do bycia dobrym przykładem i próby rozbudzenia, czy też przywrócenia w tych osobach pasji i zainteresowania tym co robią.

Rektrutacja

W książce dużo miejsca zostało poświęcone procesowi rekrutacji zarówno z punktu widzenia pracownika, jak i firmy. Autor stawia tam bardzo odważne tezy. Według jego kryteriów wszystkie oferty pracy, jakie do tej pory widziałem nie dość, że są źle sformułowane, to jeszcze znamionują problemy firmy z organizacją i kulturą pracy. Jego zdaniem proces rekrutacji powinien pomagać w znajdowaniu programistów pasjonatów, którzy dbają o rozwój i kultywowanie dobrych praktyk. Zamiast tego rekruterzy najczęściej szukają ludzi, którzy przepracowali odpowiednią ilość czasu z konkretnymi technologiami. Takie podejście ma dwie wady. To, że ktoś pracował w podobnym projekcie nie oznacza wcale, że robił to dobrze. Taka osoba może przyjść w nowe miejsce i powielać złe praktyki. Po drugie dobrzy programiści, którzy na przykład nie mają doświadczenia w konkretnej branży, albo z konkretnym frameworkiem są odrzucani. Autor sugeruje, aby podczas rekrutacji zamiast o stanowiska w poprzednich firmach i zrealizowane projekty należy pytać o konto na GitHubie, udział w konferencjach i ulubione książki programistyczne. Takie podejście na pewno pozwoli znaleźć ludzi z pasją, ale wydaje mi się utopijne. Ciężko mi wyobrazić sobie przekonanie do takiego sposobu rekrutacji osoby decydujące o pieniądzach.

Rozmowy rekrutacyjne zamiast składać się z przepytywania z kruczków związanych z konkretną technologią i pisania kodu na tablicy powinny mieć na celu głównie poznanie ogólnego podejścia do programowania i podejścia do takich aspektów jak  czystość kodu, Agile, TDD, czy Continuous Integration. Weryfikacją umiejętności kandydata powinien jednak być kod. Zadanie do rozwiązania na tablicy w niczym nie przypomina pracy w rzeczywistych warunkach. Zamiast tego autor proponuje zadania domowe np. tydzień na zrealizowanie jakiegoś miniprojektu. Innym proponowanym sposobem jest sesja programowania w parach. Dzięki tym technikom można poznać styl nazywania funkcji, komentowania kodu, refactoringu, używania narzędzi rekrutowanej osoby.

Moim zdaniem dzięki pytaniu na rozmowie kwalifikacyjnej o konkretne sytuacje z poprzednich projektów można dowiedzieć się wiele zarówno o podejściu do praktyk programistycznych, jak i o szczegółowej wiedzy technicznej, która też jest potrzebna. Osoba z pasją, która chętnie się uczy, ale jednocześnie ma już doświadczenie w podobnym projekcie zetknęła się już z wieloma problemami i ma na nie gotowe rozwiązania. Dzięki temu może zwiększyć efektywność całego zespołu. Jednak taka wiedza wydaje mi się deprecjonowana przez autora.

Rozwój kariery

Książka porusza również ciekawy aspekt dotyczący kariery w branży IT. Utarło się bowiem przekonanie, że bycie developerem przez dłuższy czas oznacza brak rozwoju zawodowego. Osoba zdolna powinna awansować na stanowisko architekta, managera, team lidera, czy inną pozycję, gdzie głównym obowiązkiem przestaje być programowanie. Dzieje się tak dlatego, że wymienione posady są lepiej płatne i uznawane za bardziej prestiżowe. Autor udowadnia, że osoby na tych stanowiskach przez to, że nie mają na co dzień takiej styczności ze sprawami technicznymi, a na nich spoczywają decyzje, są często przyczyną problemów w projektach. Przejście ze stanowiska developera na architekta, czy kierownika nie jest rozwojem kariery, tylko zmianą jej ścieżki. Na tych stanowiskach są potrzebne inne umiejętności i to, że ktoś jest dobrym programistą nie znaczy, że będzie dobrym managerem, ani że będzie mu to sprawiało przyjemność.

Podsumowanie

Książka „Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja.” jest kierowana do programistów, ale nie zawiera ani linijki kodu. Dzięki temu szybko się ją czyta, ale poruszane w niej tematy skłaniają do przemyśleń na temat podejścia do pracy programisty. Mogę spokojnie polecić tę książkę osobom pracującym w branży IT. Myślę, że nie tylko programiści znajdą w niej coś dla siebie, ale także np. managerowie, rekruterzy czy testerzy.