Przekrój poziomów umiejętności – zrozumieć grę

Autor: Konrad, Opublikowano: 07/10/2009

Artykuł ten tworzy serię Sztuka i Rzemiosło Programowania, w której staram się poruszyć kwestie interesujące zarówno początkujących programistów jak i tych z dużym doświadczeniem. Moim głównym celem jest pomóc lepiej zrozumieć istotę zachodzących dokoła procesów, w mniejszym stopniu tworzyć tysięczny kurs programowania. Artykuły nie są powiązane z konkretnym językiem czy środowiskiem, co powinno zapewnić równy dostęp dla wszystkich zainteresowanych. Artykuły mogą natomiast nawiązywać do siebie nawzajem – zwłaszcza do wcześniejszych. Głównie uwagę skieruję na kwestie pomagające zrozumieć pojawiające się podczas pracy problemy, stawić czoła różnym projektom, zwiększyć efektywność i potencjał swój jak i zespołu oraz wskazać dalsze drogi do własnej edukacji.

 

Dlaczego zaczniemy od przekroju poziomów umiejętności? Wbrew pozorom naszą najważniejszą grą jest własne doskonalenie – zwłaszcza w branży IT. Dzięki zdobytej wiedzy i umiejętnościom możemy realizować się w pracy. Dzięki pozyskanemu wynagrodzeniu zapewniamy sobie wszystko, czego potrzebujemy.

Występuje wiele sposobów podziału pracowników ze względu na poziom umiejętności. Mi szczególnie przypadł jeden zaczerpnięty z tradycji japońskiego teatru i stosowany choćby w sztukach walki. Nie koliduje on ze strukturami w firmach i organizacjach, a ponad 4 tysiące lat potwierdziło jego słuszność. Dodatkowo wprowadza ciekawy egzotyczny wątek – za co muszę podziękuję Alistairowi Cockburnowi. Budują go trzy poziomy Shu, Ha i Ri.

Shu to poziom osoby, która dopiero poznaje pierwsze ruchy trenowanej dyscypliny – w naszym przypadku programowania. Korzysta ona z podstawowych rozwiązań i z każdym wykonanym zadaniem rośnie jej biegłość i sprawność. Osoba na poziomie Shu, trenująca walkę, uczy się zadawać podstawowe ciosy – przez tysiące powtórzeń nabiera wprawy i doskonali wykonywany ruch. Programista również musi podążać tą drogą. Głównymi jego (lub jej) narzędziami są proste konstrukcje i najbardziej znane funkcje bazowych bibliotek. Na razie trochę bardziej złożony kod (np. w formie klas) cudzego autorstwa powoduje nagły atak paniki. Jeżeli taka osoba chce zrobić krok na kolejny poziom musi biegle opanować i zrozumieć narzędzia i biblioteki, z których korzysta – tak, aby czytając prosty kod innych programistów była w stanie wytłumaczyć, co robią jego poszczególne linie i znaleźć proste błędy logiczne lub składniowe. Jak do tego doprowadzić? Jest tylko jedna droga – praktyka i praca. Ostatnia rada: Czytaj mnóstwo książek.

Ha to kolejny poziom. Osoba pragnąca go opanować musi najpierw uzyskać biegłość w Shu. Ha można określić, jako drogę w rzemiośle łączenia poznanych do tej pory elementów w skuteczne techniki. W programowaniu przekłada się to na modyfikowanie znanych prostych konstrukcji pod własne potrzeby oraz tworzeniu nowych funkcjonalności w oparciu o dostarczone komponenty/biblioteki. Z czasem dostrzega się istotne miejsca w kodzie pozwalające kontrolować zapożyczoną większą całość. Rozpoczyna się przygodę z wielokrotnie wykorzystywanym częściowo modyfikowanym kodem. Później przyjdzie kolej na nowe Framework-i, komponenty, generatory, skróty a może nawet wzorce projektowe. Częstym błędem, z którym spotykam się u programistów na poziomie Ha, to zapominanie o tym, co się do tej pory nauczyli – i co ważniejsze, w jaki sposób. Drogę doskonalenia rzemiosła nagminnie zastępują magiczne skróty typu Ctrl+C i CTRL+V. Dlaczego jest to złe? Gdyż narząd nieużywany zanika. Tylko ciągłe poznawanie nowych wzorców, konstrukcji i rozwiązań zapewnia rozwój. Wszelakie skróty też są ważne, ale nie mogą stać się jedyną formą działania. Co do rozwoju: Tak jak na tym poziomie poznaje się na przykład znaczenie poszczególnych elementów klas, z czasem patrząc na ich konstrukcję, na zależności pomiędzy nimi i obiektami wyciąga się nowe wnioski. Na tym poziomie bardzo ważne jest, aby czytać jak najwięcej dokumentacji – nie tylko z elementów, z których się korzysta. Uczyć się komentowania własnego kodu i jego archiwizacji, by z czasem nie stał się dla nas tworem nie do ogarnięcia. Próbuj również sprawdzać własne pomysły programistyczne. Twórz własne eksperymenty – to pozwoli Ci dostrzec drogę sztuki w programowaniu. Udzielaj się w prostych dyskusjach. Obserwuj jak inni rozwiązują te same problemy – pomorze to rozwijać twoją kreatywność, co jest niezwykle ważne. Każdą wolną chwilę czytaj i programuj.

Ri to ostatni z poziomów, jak to sobie pozwolę powiedzieć, wtajemniczenia. Osoby, które uważają, że jest to koniec niestety zasmucę – tak naprawdę jest to poziom rozpoczęcia nauki prawdziwego programowania. Programowanie przestaje mieć wymiar kolejnych linijek kodu i powoli zwracamy uwagę na rzeczy pierwotne a głowę zaprzątamy niemal metafizycznymi rozważaniami typu: jakie mechanizmy zachodzą i dlaczego, jak zrobić to lepiej. Patrzy się na problemy z szerszego kontekstu. Nie przez pryzmat gdybania a doświadczenia z zakresu rzemiosła programowania. Również Ri wynika z biegłego opanowania poziomu niższego. Wiąże się on z rozwojem umiejętności tworzenia złożonych rozwiązań od podstaw. Wymaga to sporej wyobraźni, wiedzy i doświadczenia, ale daje również niezwykle dużo satysfakcji. Wiele osób spełnia się pisząc potężne projekty – często społecznie. Duża praktyka pozwala na błyskawiczne opanowywanie nowych bibliotek oraz planowanie i dostrzeganie tworzących się relacji i konstrukcji w kodzie – niczym Neo w Matrixe. Ma to też swoje wady. Od zbytniej gloryfikacji umiejętności po problemy w komunikacji, często przypadkowo pozbawionej jakże oczywistych i wynikających z siebie (jedynie dla autora), a niezwykle istotnych kroków w omawianych zagadnieniach. Stąd waga poprawnego rozwoju umiejętności wysławiania i notowania własnych myśli. Na tym etapie trzeba przyswoić (i wdrożyć w życie) takie rozwiązania jak Test Driven Development, wzorce projektowe, umiejętności projektowania architektury, planowania alternatywnych scenariuszy realizacji projektu, planowania złożoności projektów oraz najważniejsze: otwartość i kreatywność. Często też jest się mistrzem dla innych – doradcą, pierwszym źródłem sprawdzonej informacji czy pomocą w rozkładaniu dużych problemów na łatwe zadania. Teraz może trochę o błędach. Najważniejsze są dwa: nadmierna finezja oraz zbyt duże przeskoki myślowe. Częściowo już poruszyłem wspomniane problemy. Pierwszy z nich polega na zbytnim dopracowywaniu rozwiązania lub rozpracowywaniu problemu. Skutkuje to zbytnim wydłużeniem prac na poszczególnych jej etapach, a prawdziwym problemem staje się zbyt krótki termin oddania projektu. Również problemem stają się nadmiarowe produkty prac w formie dodatkowych narzędzi służących do realizacji projektu. Część z nich jest zbędna i nie zostanie efektywnie wykorzystana. Drugi problem jest przeciwnej natury. Polega on na tworzeniu złożonych rozwiązań pozbawionych jakiegokolwiek komentarza czy dokumentacji, z zagmatwaną architekturą zrozumiałą tylko dla autora i tylko w momencie realizacji projektu. Również dużym problemem może być zebranie dokumentacji środowiska i jego konfiguracji, by była możliwa kompilacja na innej maszynie. Często to podkreślam: Pamiętaj, aby tworzone oprogramowanie spełniało warunki, jakie stawiane są odgórnie, ale również by kod był przemyślany, zrozumiały, przejrzysty, z komentarzami, koniecznie konsekwentny i najważniejsze – napisany. Dlaczego? Jeśli ktoś dobrnął w swej edukacji i rozwoju aż tutaj to z doświadczenia może przytoczyć argumenty. Dla reszty: uwierzcie, tak musi być.

Dlaczego poświęciłem aż tyle miejsca wspomnianym poziomom? Warto wiedzieć, że różnice z nich wynikające wpływają na komfort i jakość komunikacji. Im wyższy poziom tym większym słownikiem osobistym dysponuje jego przedstawiciel. Podział ten pokazuje również kompetencje w wykonywaniu poszczególnych zadań. I tutaj kolejna uwaga, a zarazem odpowiedź na często zadawane pytanie. Nie należy obarczać osób zadaniami z poziomów wyższych niż ten, na który wskazują ich kompetencje, mimo ich potencjału – tym bardziej w projektach komercyjnych. Zadania, nazwijmy je rozwojowymi, należy przekazywać jedynie, jeżeli osoba znajduje się na danym poziomie co zadanie, a jeszcze nie jest na nim w pełni biegła.

Postaram się teraz nawiązać do wstępu. Czasami niesamowicie trudne jest uświadomienie sobie, że w naszym otoczeniu są osoby o określonych potrzebach i możliwościach. Zwłaszcza w koncepcji biznesowej gdzie obserwuje się głównie przez pryzmat liczb. Jakie duże zdziwienie wywołuje fakt, że np. wspieranie aktywności fizycznej pracownika umysłowego zwiększa jego kreatywność – przez co i wydajność. Natomiast nadmiarowe przeciążanie zmniejsza drastycznie efektywność wykonywanej pracy. W dodatku zasoby motywacji i energii trzeba odbudowywać przez długi czas – nie do następnego dnia. Tak samo nie uświadamiamy sobie znaczenia wspierania rozwoju. A to ułatwianie i wspieranie w grze osobistej najbardziej otwiera na grę zespołową. Przy odrobinie rozsądku, każda ze stron na tym zyskuje.