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

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.

Moje miejsce w procesach: Wstęp

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.

Każdy z nas ma swoją rolę – tak jak aktor w sztuce. Każdy z nas uczestniczy też w specyficznej grze, w której małe ruchy składają się na większe działania. Czasami musi upłynąć dużo czasu zanim w tej grze zacznie się wygrywać. Ale jak wygrywać skoro nie zna się jej reguł czy celu?

Jestem zwolennikiem pojęcia, które spotkałem w publikacji Alistara Cockburna, że praca to nieustająca gra pomysłowości i kreatywności. Niestety sporej części osób wydaje się, że ich rola w tej grze polega na wykonaniu zleconego zadania z jak najmniejszym zaangażowaniem, czekając na należne im wynagrodzenie. Zbudowanie zrozumienia zasad wspólnej pracy nad wspólnym sukcesem i zwiększania grona osób pomagających go osiągnąć nie jest łatwe. Jeżeli są to kwestie abstrakcyjne i niewyjaśniane uczestnikom procesu, bez najprostszej świadomej metodologii, będą doprowadzały do kolejnych upadków. Również im mniejsze zrozumienie dla tych zasad u osób kierujących zespołami, z tym wyższej pułki upadek – wręcz proporcjonalny do wypracowanego chwilowego sukcesu. Postaram się przedstawić zarówno rozwiązania pomagające odnaleźć swoje miejsce w procesie, doskonalić się w obrębie własnej gry oraz podnoszenia gry zbiorowej na wyższy poziom. Zachęcam do dyskusji i rozpoczynam zbiór artykułów na wspomniany temat.

Komunikacja w zespole

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.

W tym artykule skupię się zasadniczo na jednym temacie. Właściwie rolę tematu przejmie sentencja, którą osobiście powtarzam bardzo często i równie często stosuję, a mimo tego (o zgrozo!) zbyt często jest wstydliwie zapominana:

Jeżeli czegoś nie wiesz lub nie rozumiesz, pytaj. Pytaj od razu jak zdarzy się okazja!

Dlaczego jest to takie ważne? Wiele osób uważa pytanie za dowód ich niekompetencji czy braku wiedzy. Natomiast osoby, które mają okazję odpowiadać, mogą potwierdzić, że właśnie z każdą odpowiedzią rośnie ich wiedza i kompetencje. Na tym polega edukacja. Jeżeli czegoś nie wiesz, to szukasz odpowiedzi. Czy poprzez książkę, internet czy inne osoby – nie ma w tym nic wstydliwego. Niestety takie negatywne przekonanie rośnie z pozycją – rozprzestrzenia się nawet na wspomniane formy edukacji – bo jak tu przystoi starszemu programiście czytać książkę, czy coś sprawdzać? A właśnie każdemu przystoi. Im więcej wiesz, tym więcej musisz czytać i pytać by zdobyć ten coraz mniejszy i lepiej ukryty fragment potrzebnej lub nieznanej informacji. Nie należy się bać wymiany wiedzy z osobami bardziej czy mniej doświadczonymi. Ile razy byłem świadkiem uciekania przed pytaniem, które wracało ze zdwojoną siłą w formie problemu, za który musieli się wstydzić. Rozmowa pozwala też z każdym wypowiedzianym słowem lepiej precyzować swoje myśli i doskonalić swoje umiejętności komunikacji. Większość osób nie zdaje sobie z tego sprawy, ale około 20-40% problemów programistycznych można rozwiązać poprzez jasną i zrozumiałą komunikację – i to bez jednej linijki kodu. Takie zachowanie podnosi też poziom współpracy pomiędzy zespołem i sprzyja wymianie wiedzy – a nawet otrzymaniem gotowego kodu na zadane pytanie. Jeżeli jeszcze nie pytasz, to zacznij to robić!

Komunikacja w obrębie firmy

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

Jak często zdarza się wam przekazywać informację o zadaniu do wykonania lub takowe informacje pozyskiwać od innych? Ile z tych sytuacji kończy się pełnym zrozumieniem, a jaka część wręcz przeciwnie? Gdzie leżą podstawy powstających problemów, które często potrafią się spiętrzyć do zaciętych długich wojen lub nieprzyjemnych konfliktów międzyludzkich. Czy problem leży w niekompetencji, złych zamiarach czy przypadkowych błędach?

W tym artykule skupię się na jednym zasadniczym powodzie błędów, o którym niestety bardzo łatwo się zapomina, a którego zrozumienie daje bardzo duże efekty – mianowicie różnic wynikających z indywidualności naszych osobistych słowników. Każdy z nas ma różne doświadczenie, rożne poglądy i inaczej interpretuje określone zagadnienia – a nawet poszczególne słowa. Część słów ma dla nas zupełnie inne znaczenie. Dla jednych polecenie zrób jest obraźliwe, dla innych nieuprzejme czy niestarannie dobrane ale o neutralnym brzmieniu. Część pracowników ograniczy się do najkrótszej drogi inni włożą całe serce w jego wykonanie. Niektórzy oczekiwać będą wsparcia i motywacji bo w tym słowie nie odnajdą informacji o pilnym priorytecie. A raptem jest to tylko jedno słowo z wielu. Teoretycznie zdania czy pytania powinny rozwiewać niepewności ale mechanizmy z naszych osobistych słowników przechodzą w nich ze skali mikro do skali makro – i zamiast uzyskać spójną informację często uzyskujemy olbrzymią wariację możliwości i niedopowiedzeń. Jeżeli nie nauczymy się operować na pojęciach wspólnych, czy to w skali mikro czy makro, i nie znajdziemy dla nich jak najbardziej zgodnej interpretacji nie należy oczekiwać niczego dobrego. Relacje te zarówno tworzą się na poziomie pracownik – pracodawca ale również pracodawca – klient. Jak zaobserwować czy w naszej firmie/otoczeniu/społeczności występuje wspomniany problem? Wystarczy się przyjrzeć przepływowi ludzi – im większy tym większa skala. Im lepsze zrozumienie tym bardziej cenimy sobie długotrwałe relacje. Chciałbym jednocześnie ostrzec przed ekstremum w ograniczaniu przepływu – nierozwijany słownik, nawet idealnie działający teraz, z czasem staje się jednym z oddzielających nas od świata czynników. Idealny osobisty słownik to oparty na otwartości i pozytywnym nastawieniu, ciągle rosnący i zdolny do kompromisów.

Chciałbym teraz poświęcić akapit na pojęcia techniczne i definicje akademickie. Patrząc przez pryzmat informatyki i precyzyjniej programowania, tworzą się dwa obozy: przyjazny i wrogi. Przyjazny złożony jest z wyrazów, po które sięgnęły społeczności i używają go w publicznie akceptowanym jako właściwe znaczeniu (np. blog). Wrogi wypełniony wyrazami tłumaczonymi poprzez członków tego samego obozu lub  niejasnymi i niezrozumiałymi sformułowaniami. Tworzą go również pojęcia, które przeszły z grona przyjaznego do slangu zbyt hermetycznych grup – czy to poprzez nadmierne nasycenie znaczeniami, czy modyfikację znaczenia. Wróćmy do programowania. Czy w twoim otoczeniu używane są skróty, których nie rozumieją osoby z zewnątrz? Czy organizowane są spotkania podczas których tłumaczone są dla osób z którymi współpracujesz? Czy jesteś w stanie zrozumieć się z programistą siedzącym obok Ciebie? Czy jesteś w stanie wytłumaczyć, używając tylko słów, nad czym pracujesz? Czy jest to zrozumiałe i dla kogo?

Postaram się o przykład. Jakie nastawienie wywołują u Ciebie pojęcia drzewo czerwono-czarne, wzorce projektowe czy testy jednostkowe? Dla jednych osób część z nich to pojęcia wręcz potoczne dla innych mistyczne. Z każdym artykułem postaram się pracować nad naszym wspólnym słownikiem. Zwiększać go o nowe pojęcia i doprecyzować wspólnie znane. Chciałbym również zachęcić do dyskusji w naszych otoczeniach o wspólnych nawykach komunikacyjnych, o różnicach w postrzeganiu i nazywaniu oraz jakże ważnej atmosferze otwartości i przyjazności w komunikacji.