Od czeladnika do mistrza. Jak nie zostać początkującym ekspertem

Kilka dni przed napisaniem artykułu o drodze od czeladnika do mistrza, zostałem poproszony przez jednego ze znajomych managerów, aby odpowiedzieć na ankietę prowadzoną przez pewną politechnikę. Sprowadzała się ona do pytania, jakich umiejętności brakuje absolwentom studiów inżynierskich, którzy zaczynają karierę w branży IT. Padł wtedy również pomysł, aby podejść do tematu nieco szerzej i spisać doświadczenia moje i kolegów.

Będę opowiadać o wspólnych cechach ludzi, których rekrutowałem, a później okazali się przysłowiowym “strzałem w dziesiątkę” jako współpracownicy w projektach. W wielu przypadkach kontakt z zatrudnionymi nie zakończył się na interview, miałem wielokrotnie okazję zrewidować swoje początkowe spostrzeżenia. Regułą jest, że dobrzy programiści nie są dziełem przypadku, ich profesjonalizm jest efektem ukierunkowanego postępowania w dłuższym horyzoncie czasowym. Esej kieruję raczej do początkujących lub tych, którzy mają poczucie, że utknęli na zbyt stabilnym stanowisku np. w dziale application maintenance.

Marcin Sztandarski. Technical Architect w PolSource. Przez 15 lat obecny w branży IT. Pracował jako administrator unix, tester oprogramowania, database administrator oraz programista. Do zespołu PolSource dołączył na początku 2016 roku jako senior software developer. Od dwóch lat pracuje jako technical architect w warszawskim oddziale firmy. Prywatnie interesuje się psychologią społeczną, filozofią i różnymi aspektami obecności technologii w życiu człowieka.

Firma zatrudni początkującego programistę

Wracając do pytania o oczekiwane umiejętności absolwentów uczelni technicznych – można na nie odpowiedzieć listą wymagań związanych ze stosem technologicznym używanym w projektach, podobnie jak czynią to działy HR w ofertach pracy. Weryfikacja wiedzy na temat technologii nie stanowi z reguły większych problemów. Z drugiej zaś strony zatrudniając początkującego programistę nie można oczekiwać od niego dobrej i praktycznej znajomości przedmiotu, bo po prostu nie miał jak jej nabyć. Ogłoszenia pomijają jednak trudne do zwerbalizowania oczekiwania w stosunku do osoby kandydata.

Niemniej ważny jest portret psychologiczny kandydata (team player, introwertyk…), czasem weryfikowany pobieżnie przez dział HR. Ostatecznie znaczenie mają specyficzne wymagania firmy, które rzadko ujawniane są w ogłoszeniach. Są one jednak równie ważne i mogą zdeterminować całkiem spory wycinek twojej kariery.

Przyjrzyj się gdzie aplikujesz i komu powierzysz swój czas

Dobry programista nie marnuje czasu w kiepskim środowisku. Jeżeli firma nie przykłada wagi do konieczności rozwoju swoich pracowników, a jedynie skupia się na ich eksploatowaniu, może już na początku przestawić karierę na niewłaściwy tor. Szukając pracy warto sprawdzić czy twój pracodawca oprócz wymagań będzie wspierał twój rozwój zawodowy. Być może jako początkujący nie jesteś zbyt pewny swoich umiejętności i będziesz miał opory z zadaniem takiego pytania podczas rozmowy. Jednak zapewniam cię, że dla firmy, w której obecna jest kultura ciągłego uczenia się, pytania o możliwości rozwoju nie wprawią jej przedstawicieli w zakłopotanie, a wręcz przeciwnie – dyskusja na ten temat będzie mile widziana.

Może to świadczyć o tym, że firma nie jest “kontraktownią” nastawioną na tzw. body leasing i szybką “monetyzację”. Oczywiście praca w tego typu firmach za uczciwą stawkę nie jest niczym złym, o ile jesteś doświadczonym programistą i potrafisz znaleźć czas i siłę na rozwój w czasie wolnym. W każdym pozostałym przypadku, gdy zamierzasz się rozwijać lub jesteś na początku drogi, przyda ci się być częścią organizacji z kulturą ciągłego uczenia się. Nie musi to oznaczać wcale wyjazdów na szkolenia czy konferencje.

Jednorazowe “strzały szkoleniowe” oczywiście mogą być pomocne w rozwoju, jednak ważniejsze są praktyki związane z podnoszeniem kwalifikacji, które wykonywane są w sposób cykliczny np. raz w tygodniu.

Może odbywać się to w formie cotygodniowych spotkań, w których zespoły dzielą się wiedzą o rozwiązaniach z obecnych projektów lub obowiązkowy mentoring, w ramach którego otrzymasz wsparcie od osoby bardziej doświadczonej. Możliwości jest wiele, ważne żeby jakiś procent twojego czasu spędzanego w firmie przeznaczony był na regularne podnoszenie kwalifikacji.

Czy developer zajmuje się pisaniem kodu?

Jeżeli zapytasz programistę czym się zajmuje, zapewne odpowie zdawkowo – programowaniem. Bardziej oświeceni koledzy mogą odpowiedzieć ewentualnie – inżynierią oprogramowania. Można pokusić się o stwierdzenie, że pisanie kodu jest pochodną tego, co i jak myślisz. Nie będziemy zajmować się coraz rzadziej spotykaną profesją “kodera”, którego zadaniem jest zamianą precyzyjnie określonych wymagań na kod w dowolnym języku. Skupmy się zatem na przykładach praktyk sprawiających, że dobry programista wypada znacznie lepiej w stosunku do przeciętnego, albo co gorsza kiepskiego.

Chciałbym również podążać za tezą, że zawód programisty to coś więcej niż pisanie kodu (ewentualnie kopiowanie go ze stackoverflow), czyli “robienie projektów”. Zawód programisty rządzi się określonymi prawami, zaś jakość pracy i rozwój możliwy jest dzięki wyznawaniu określonych wartości i stosowaniu sprawdzonych wzorców. Na podstawie własnych doświadczeń i obserwacji zakładam, że techniczne umiejętności, znajomość kolejnych frameworków i pracoholizm nie są wystarczającym pomysłem na karierę w szerszym horyzoncie czasowym.

Jeśli uważasz inaczej – gwarantuję ci, że nasza branża pełna jest ludzi, którzy obecnie mentalnie siedzą na “ławce rezerwowych” z powodu wypalenia lub takich, którzy mimo dziesięciu lat w branży, utknęli w ślepym zaułku “zaawansowanego początkującego”.

Dobry programista to rzemieślnik dbający o rzemiosło. Dwudziestolecie wydania książki “Pragmatyczny Programista. Od czeladnika do Mistrza”

Profil programisty składa się, tak jak omówiłem w pierwszym akapicie, z kilku wymiarów. Na rozwój (bądź przeciwnie, degradację) kariery wpływają świadome lub przypadkowe wybory modelujące te aspekty w trakcie trwania aktywności zawodowej. Czy istnieje zatem jakiś stały model pozwalający przejść ścieżkę od “absolwenta uczelni” do zaawansowanego senior developera w możliwie optymalny sposób? Pod pojęciem optymalnej drogi rozumiem ciągły rozwój bez wypadków wypalenia się po drodze, czy też utraty pasji do tego co się robi.

Tak, to trudne pytanie. Przy takiej mnogości technologii, wciąż zmieniających się oczekiwaniach rynkowych, nierzadko też w stresie związanym z “dowożeniem opóźnionego projektu”, każda kariera wygląda nieco inaczej. Stały model kariery może brzmieć jak oksymoron. Czy jest zatem coś na czym można polegać?

Może nie będzie zbyt odkrywcze, jeżeli pracę, którą wykonuje programista nazwiemy rzemiosłem, o które trzeba dbać. Z takim podejściem można spotkać się choćby w książce “Pragmatyczny Programista, od czeladnika do mistrza”. Jest to bez wątpienia dzieło wyjątkowe, omawia w szczegółach czym jest postawa pragmatyczna. Aktualnie dostępne jest jej kolejne poprawione wydanie, które ukazało się po dwudziestu latach.

Zapewniam cię, że książka nie zdezaktualizowała się ani odrobinę i jest to jedna z pozycji, która radykalnie zmieniła moje spojrzenie na zawód programisty. Spotkałem się kiedyś z zarzutem, że książka jest przestarzała, bo pojawia się w niej zachęta do stosowania języka Perl. Nic bardziej mylnego. Ta książka traktuje głównie o uniwersalnych wartościach, które pragmatyczny programista może stosować w określonych okolicznościach. Nie jest to książka kucharska, która poda ci przepis jak pisać w określonej technologii.

W publikacji wspomniany jest na przykład język Eiffel i egzotycznie brzmiąca dla początkujących koncepcja Design-by-Contract. Zrozumienie sensu tej techniki może odmienić sposób w jaki piszesz kod. Nie będę streszczał treści – po prostu ją przeczytaj. Niezależnie od poziomu zaawansowania “Pragmatyczny Programista. Od czeladnika do Mistrza”, to lektura obowiązkowa, szczególnie jeśli jej nie czytałeś. Jeżeli tak jak ja czytałeś ją dziesięć lat temu – przeczytaj ponownie.

O początkach stawania się dobrym programistą

Czy możliwe jest zmuszenie kogoś do bycia dobrym? Nie widziałem takiego przypadku. Bycie dobrym bierze się z chęci zostania kimś lepszym niż się jest obecnie. Pochodną tego jest chęć ciągłego uczenia się i dbania o rzemiosło, albo wręcz kult ciągłego uczenia się i doskonalenia warsztatu. Z doświadczenia wiem, że prędzej dobry administrator baz danych stanie się dobrym programistą, niż kiepski programista z wieloletnim stażem, który sobie “odpuścił”.

Staż pracy ma oczywiście znaczenie. Nie wiem czy słyszałeś o popularnym micie 10 000 godzin, spopularyzowanym przez książkę Malcolma Gladwella “Poza Schematem”? Wynika z niego, że mniej więcej po kilku latach programowania powinieneś osiągnąć wyżyny. Niestety w przypadku developerów – model ten znacznie się komplikuje. Spotykam bardzo często ludzi, którzy twierdzą, że są senior developerami przez “wysługę lat”. Niestety na ogół na rozmowie kwalifikacyjnej okazuje się zupełnie inaczej. Przeskakiwanie kolejnych szczebli nie zależy tylko od ilości godzin spędzonych w IntelliJ lub Visual Studio. Sprawy tym bardziej się komplikują, że część wiedzy, którą nabywasz, dość szybko traci na wartości.

Nie wystarczy tak po prostu pisać kod.

Na jednej z rekrutacji zapytałem kandydata, co sprawia, że jest senior developerem? Czym różni się jego podejście do programowania np. w stosunku do przeciętnego developera? Usłyszałem kuriozalną, ale prawdziwą odpowiedź: „takie stanowisko dostałem w poprzedniej firmie”. Chciałbym doprecyzować – nie będziemy posługiwać się kryterium stażu lub zaszeregowania w programie płacowym.

Z udziału w wielu rekrutacjach wiem, że to się nie sprawdza. Jeżeli uważasz, że jesteś senior developerem, to znaczy, że potrafisz samodzielnie rozwiązywać zarówno typowe, jak i nietypowe problemy. Widzisz też swój kod jako część całości np. przewidujesz skutki pewnych decyzji projektowych. Niemniej ważne jest dotrzymywanie wysokich standardów etycznych. Może oznaczać to bycie w elitarnej grupie np. 10% programistów.

Rola retrospektywy

Czas i doświadczenie projektowe będą ci służyć, o ile dokonujesz retrospektyw i uczysz się na błędach. Nie wiesz jak? Przeczytaj świetną książkę Matthew Syeda “Metoda czarnej skrzynki”. Nie jest to książka o programowaniu, ale jest fascynującą podróżą o naprawianiu lotnictwa, o poprawianiu skuteczności praktyk medycznych, a nawet o optymalizacji pracy dysz służących do produkcji proszku do prania. Wbrew temu co możesz wywnioskować z opisu, te techniki, bardzo przydają się w programowaniu. Właściwie możemy powiedzieć, że czarna skrzynka jest systemem pętli zwrotnej do “naprawiania świata”, także programistycznego.

Jeżeli chcesz wykorzystać owocnie kolejne lata pracy – stwórz swój własny “black box”. Przychodzi mi do głowy przykład z techniką, pre-mortem, która jest zupełnie “nieinformatyczna”. Używa się jej zarówno w zarządzaniu, jak i medycynie. Pre-mortem wdrożyłem wraz z moim zespołem na jednym z ryzykownych projektów. Praktyka polega na takim przemodelowaniu swojego myślenia, w którym wychodzisz z założenia, że twój kod nie działa lub release doprowadził do katastrofy w systemie produkcyjnym.

Stawiasz hipotezę – to się nie uda i spekulujesz na temat przyczyn. Ma to służyć kompensacji niektórych błędów poznawczych podczas analizy wdrażanego rozwiązania. Technika jest bardzo prosta i kilkukrotnie uratowała nam skórę, albo pozwoliła uniknąć zarwanej nocy po nieudanym wdrożeniu.

Kolejne stopnie wtajemniczenia, o stawaniu się lepszym według braci Dreyfus

Rozważałem na początku umieszczenie profili programistów, czyli tego kim jest junior, regular oraz senior developer. Skala ta wydaje się jednak niewystarczająca. Znanym modelem, którym posługują się np. autorzy książki “Pragmatic Thinking and Learning” jest podział pochodzący z badań braci Dreyfus nad pozyskiwaniem umiejętności u pilotów Air Force. Nie będziemy prowadzić podobnych badań, ani omawiać szczegółowo każdy z etapów rozwoju umiejętności, bo znacznie wykraczałoby to poza zakres tego artykułu. Skupimy się na etapach, na których znajdują się początkujący.

Badanie przeprowadzone przez wyżej wymienionych ujawniły interesujące fakty dotyczące rozwoju umiejętności – to nie jest tylko kwestia ilości wiedzy, którą zdobywasz – zmiany, które dokonują się podczas “przeskakiwania” kolejnego szczebla to radykalne zmiany w myśleniu, które sprawiają, że postrzegasz domenę problemów w innym świetle niż na pozostałych stopniach wtajemniczenia. Innymi słowy – widzisz świat na innych poziomach. Jeżeli chcesz poznać temat dogłębnie, polecam lekturę “Pragmatic Thinking and Learning. Refactor Your Wetware” A. Hunta.

Nowicjusz (ang. novice) – radzenie sobie z negatywnymi emocjami

Niezależnie od motywacji, która kieruje Tobą, aby zostać programistą, domyślnie zaczynasz karierę od tego stopnia. Nie umiesz jeszcze programować (albo robisz to źle). Poznajesz platformę, dostajesz się na staż albo od razu lądujesz w pierwszej pracy jako junior developer. W pracy dostajesz “coś do zrobienia” np. user story z jednym zdaniem opisu i… czujesz, że zbliża się twój koniec. Nie rozumiesz terminologii biznesowej, nawet jeżeli opis przypadku jest szczegółowy, nie masz bladego pojęcia jak wziąć się za implementację. Potrzebujesz struktury lub sprawdzonej recepty od starszego (stażem) kolegi lub architekta.

Ten etap z jednej strony jest frustrujący z drugiej zaś ekscytujący ze względu na ogrom nowości, które oferuje ciągle technologia. Najczęściej jednak będziesz przeżywać frustrację.

Zawsze znajdą się problemy, które będą wyzwaniem.

Będąc nowicjuszem rozbudź w sobie pasję rozwiązywania problemów i naucz się radzić sobie z niepewnością. Tak już będzie do końca twojej kariery w branży IT, niezależnie od poziomu. Jednym z często obserwowanych problemów wśród niektórych developerów jest również perfekcjonizm. Polega on na tworzeniu niekończących się abstrakcji, frameworków, bibliotek do trywialnych problemów.

Spotykam się czasem ze sfrustrowanymi developerami, którym nie udało się od razu napisać “idealnego kodu”. Kod powstaje ewolucyjnie po kilku iteracjach. Może przemówi do ciebie eksperyment opisany w książce “Art & Fear”. Podczas kursu ceramiki nauczyciel podzielił uczniów na dwie grupy. Pierwsza miała wykonywać tak dużo garnków jak to możliwe, druga grupa miała zaś tworzyć garnki jak najdoskonalsze. W pierwszej grupie podstawą do najlepiej oceny była ilość, w drugiej jakość. Wydaje się to nieintuicyjne, ale to grupa pierwsza wyprodukowała finalnie garnki najlepszej jakości. Jak to możliwe?

Okazało się, że to grupa pierwsza poprzez produkcję dużej ilości garnków eksperymentowała z materiałem, przez co stopniowo zyskiwała wiedzę i zdolności. Grupa druga… była sparaliżowana “ciężarem gatunkowym” zadania. Wniosek może być tylko jeden – próbuj, psuj, eksperymentuj. W trakcie pracy pojawią się nowe pomysły, kiedy dotkniesz materii problemu. Jeśli nie wiesz jak zacząć, napisz najgorszy kod jaki potrafisz, spróbuj najbardziej naiwnego rozwiązania. Może słyszałeś o Test Driven Development? Ta technika może pomóc ci w ewolucyjnej pracy nad kodem.

Jest jeszcze jedna rzecz. Jeżeli czułeś, że utknąłeś, być może receptą dla ciebie będzie pair programming. Nie najnowsza już technika stosowana jeszcze w czasach Extreme Programmingu. Jak się okazuje (istnieją badania na ten temat) widoczny efekt synergii obserwowany jest nawet, kiedy nad kodem pracuje jednocześnie dwóch początkujących. Więcej na ten temat przeczytasz w zwięzłym opracowaniu “The Costs and Benefits of Pair Programming” A.Cockburn, L.Williams.

Jak najszybciej znajdź mentora

Obyś trafił na zespół, w którym senior developer poświęci ci czas na code review. Im więcej błędów popełnisz na początku kariery, tym lepiej… o ile wyciągniesz z tego wnioski. Potrzebujesz informacji zwrotnej. Osobiście jestem zwolennikiem “instytucji mentora”, która doskonale sprawdza się w firmie, dla której pracuję. Jeżeli twój przełożony nie przydzieli ci mentora (a tak najczęściej to wygląda), poszukaj go samodzielnie i naucz się z nim właściwie komunikować (np. nie przerywaj mu pracy, kiedy jest skupiony). Czasem jedna rada eksperta (np. nie rób tego synchronicznie, bo…) zaoszczędzi ci wiele godzin błądzenia.

Oczywiście jeżeli zauważysz, że nikt nie podchodzi krytycznie do twojego kodu (i nie tylko) – jak najszybciej zmień pracę. Niczego tam się nie nauczysz, albo zajmie ci to znacznie więcej lat. Relacja nauczyciel (albo mentor) – uczeń występuje w wielu dyscyplinach życia i nie jest to przypadkowe. Jest to pragmatyczna praktyka, która po prostu, sprawdza się. Naucz się słuchać, bo twoim mentorem może być cały zespół. Nawet jeżeli na początku to o czym rozmawiają jest dla ciebie niezrozumiałe, w przyszłości kiedy wypełnisz braki w wiedzy, te rozmowy na open space nabiorą sensu i przyniosą ci wiele korzyści.

Nie ignoruj fundamentów

Bycie początkującym to dobry moment na naukę fundamentów programowania. Zrozumienie paradygmatów, metodyk, algorytmów i struktur danych. Dowiedz się co dzieje się “pod maską” kompilatora lub interpretera. Zrozum jak działa baza danych, jak oszacować złożoność algorytmów i jakie np. konsekwencje ma obecność garbage collectora w konkretnej implementacji JavaScript.

Poznanie tych tematów choćby pobieżnie przyniesie ci wiele korzyści w niedalekiej przyszłości, szczególnie kiedy trafisz na trudny problem np. związany z wydajnością platformy. Nie musisz czytać opasłych książek pisanych przez “klasyków gatunku”. Może to polegać na obejrzeniu zaledwie dziesięciominutowego filmu na Youtube objaśniającego zwięźle temat.

Technika uczenia się “po kawałku” objaśniona została w książce “Slighty Edge”. Autor podkreśla rolę robienia nawet małych rzeczy przez dłuższy czas, co w konsekwencji prowadzi do większej zmiany, którą jako początkujący być może nie dostrzegasz.

Jako anegdotę przytoczę pytanie, które często zadaję kandydatom z “zaawansowanym JavaScript w CV” – czym jest hoisting?

Trudno w to uwierzyć, ale większość nie wie. Jakim cudem będziesz w stanie przewidzieć jakie konsekwencje będzie niósł twój kod nie wiedząc tak podstawowych rzeczy?

Patchworkowa wiedza z tutoriali i Stack Overflow

Kolejna historyjka z rekrutacji – na pytanie jaką książkę na temat programowania czytałeś ostatnio, jeden z kandydatów odpowiedział “przecież wszystko jest w Internecie, szkoda czasu na czytanie książek”. Co do pierwszej części odpowiedzi – zgadzam się. Książki traktujące o programowaniu mają jednak pewną przewagę – są z reguły spójnym i ustrukturyzowanym wykładem. Problem z blogami bywa taki, że początkującym trudno ocenić czy proponowane rozwiązanie jest dobre (pomimo, że działa, wcale nie musi być dobre).

Oczywiście jest mnóstwo autorytetów piszących wartościowe blogi (np. Martin Fowler). Z drugiej strony, zalecam krytycznie patrzeć na to co znajdziesz na przypadkowo znalezionym blogu. Listę interesujących lektur znajdziesz poniżej. Wybór jest co prawda subiektywny, jednak poparty wywiadem wśród wyjątkowych programistów. Przeczytanie wszystkiego może zająć ci dłużej niż dwa, trzy lata, ale jest to inwestycja, która z pewnością zwróci się z nawiązką. Do części z tych książek będziesz jeszcze wracać przez lata. Z obserwacji widzę, że osoby, które przeczytały np. “Czysty Kod” lub “Kod Doskonały”, tworzą rozwiązania znacznie lepszej jakości niż developerzy, którzy np. nie mają pojęcia czym są zasady S.O.L.I.D:

1. “Pragmatyczny programista. Od czeladnika do mistrza”, Andrew Hunt, David Thomas.

2. “Pragmatic Thinking and Learning. Refactor Your Wetware” Andy Hunt.

3. “Praktyka czyni mistrza. Wzorce, inspiracje i praktyki rzemieślników programowania” , Dave Hoover, Adewale Oshineye.

4. “Czysty kod. Podręcznik dobrego programisty”, Robert C. Martin.

5. ”Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja”, Sandro Mancuso.

6. “Kod doskonały. Jak tworzyć oprogramowanie pozbawione błędów.” Wydanie II, Steve McConnell.

7. “Legendarny osobomiesiąc. Opowieści o inżynierii oprogramowania.” Wydanie II. Frederick P. Brooks Jr.

8. “Perełki programowania.” Wydanie II, Jon Bentley.

9. “Nawyk osiągania”, Bernard Roth.

Szukaj wzorców

Tak, to prawda – większość problemów, które spotkasz została już przez kogoś rozwiązana. Duża część z nich trafiła do różnego rodzaju repozytoriów wzorców: wzorów projektowych, wzorców implementacyjnych, wzorców architektonicznych, istnieje też pojęcie idiomów językowych np. w Javie. Często spotykam się ze stwierdzeniem “używam wzorców, ale nie potrafię ich nazywać”. Nic bardziej mylnego. Stosując wzorzec ważne jest zachowywanie odpowiedniej konwencji, bo pozwala to komunikować intencje dla innych członków zespołu.

Jeżeli klasę Singleton nazwiesz Locker prawdopodobnie nie zakomunikujesz, że chodziło ci o utrzymywanie pojedynczej instancji obiektu. Na początek nie łap się za klasykę napisaną przez Gang of Four tj. “Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku”, to nie jest książka dobra na początek. Zacznij np. od “Head First Design Patterns” oraz “Wzorce implementacyjne” Kenta Becka.

Jeżeli zabierasz się za naukę nieznanego ci języka programowania, koniecznie zapoznaj się z najczęściej używanymi idiomami.

Brak podstawowej wiedzy w tym zakresie kończy się nierzadko koszmarnym kodem JavaScript pisanym przez programistę C#. Ze wzorcami związana jest pewna pułapka. Przedwczesne wciskanie ich na siłę w każdy kawałek kodu, albo fiksacja na używanie wzorów za wszelką cenę, zanim dokładnie przyjrzysz się problemowi może skutkować tym, że pominiesz ważny etap odkrywania istoty problemu. Nie zaczynaj pisania kodu od pytania, jaki by tu wzorzec…? Skup się najpierw na problemie biznesowym, stosuj właściwą warstwę abstrakcji. Być może nie znasz wzorca, który pasowałby do rozwiązania.

Wtedy użycie “siłowe” jednego z tych, które znasz będzie mniej więcej zgodne z cytatem Abrahama Maslowa “Gdy twoim jedynym narzędziem jest młotek, wszystko zaczyna ci przypominać gwoździe. (…)”. Innymi słowy – wzorce projektowe, które znasz nie muszą dotykać dziedziny problemu, który rozwiązujesz.

Na koniec anti pattern – początkujący ekspert i złudzenie ponadprzeciętności

Jednym z grzechów głównych sprawiających, że programiści przestają się rozwijać jest zjawisko zwane efektem Dunninga-Krugera. Paskudny błąd poznawczy, który może sprawić, że utkniesz z rozwojem niewiele dalej niż tam, gdzie zacząłeś. Posługując się skalą braci Dreyfus – zaczynasz jako nowicjusz (ang. novice).

W dość krótkim czasie stajesz się zaawansowanym początkującym (ang. advanced beginner). Mówi się o “zrywaniu nisko rosnących owoców” podczas procesu uczenia się, które mogą dać poczucie sprawczości i wiedzy. Być może w międzyczasie twoje poczucie dumy pogłębi się dzięki kilku certyfikatom, które zdobyłeś w trzy miesiące.

Dreyfus piszą o kolejnym etapie – kompetentny (ang. competent), w którym przechodzisz z pracy “sterowanej regułami” jako początkujący do koncepcji bardziej holistycznej. Wielu developerów, mimo formalnego tytułu senior-developera, ląduje na lata w zawieszeniu pomiędzy tymi stopniami rozwoju. Jak rozpoznać taką osobę? Podczas rekrutacji stosuję pewien trik. Pytam kandydata, co jako seniora odróżnia cię od mniej doświadczonych kolegów? Senior developera można łatwo poznać po tym, że w pewnym momencie zacznie bez obaw opowiadać o tym, czego jeszcze nie potrafi. Świadomość swoich ograniczeń i tego czego się nie wie jest sygnałem, że rozmawiam z kimś kto jest co najmniej kompetentny.

Wracając do osoby “zawieszonej w rozwoju”, Erik Dietrich na swoim blogu posługuje się pojęciem początkującego eksperta (ang. expert beginner). Kolejne certyfikaty i staranna selekcja projektów, w których nie ma za wiele wyzwań za to osiągalne są całkiem wysokie stawki (pozwala na to obecnie rynek) nie konfrontuje umiejętności takiej osoby z faktycznymi seniorami, czy ekspertami. Duma i brak informacji zwrotnej, ciągłe przebywanie w strefie komfortu, są gwarantowanymi składnikami na pozostanie w tym stanie.

Jeżeli czujesz podświadomie, że jesteś taką osobą, cóż, jednym z rozwiązań jest zostanie najgorszym muzykiem w orkiestrze. To znaczy zostaje Tobie dołączenie do takiego zespołu, w którym będziesz konfrontował się z lepszymi od siebie. Jeżeli nie jesteś gotów na taki radykalny skok, spróbuj ocenić co powoduje u ciebie niechęć. Być może jako backend developer czujesz niesmak myśląc o programowaniu Front Endu lub refaktoryzowania paskudnego kodu. Możliwe jest to dobra okazja do skonfrontowania się z samym sobą.

Aha i jeszcze raz: koniecznie przeczytaj “Pragmatycznego Programistę”.

Zapraszamy do uczestnictwa w meetupie technicznym skierowanym do społeczności Salesforce oraz osób zainteresowanych technologią. Wydarzenie odbędzie się 24 września (wtorek) o godzinie 18:30 w krakowskim centrum biznesowym Cluster Cowork na ulicy Józefitów 8. Udział w wydarzeniu jest bezpłatny.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z