Subiektywne spojrzenie na doświadczenie

Moją przygodę w IT tak na poważnie zaczynałem dobrych parę lat temu. Miałem okazję, być może przywilej, zobaczyć w akcji całkiem sporo zespołów oraz różnej rangi oficerów kodowania. Moją uwagę szczególnie przykuwali doświadczeni programiści. Te osoby, które już z niejednego gitowego pieca chleb jedli. Nie będę wchodził tutaj w szybkość nabywania kompetencji, czy doświadczony programista to taki co ma trzy lata spędzone na programowaniu, czy może trzynaście, na to przyjdzie jeszcze czas. Dla mnie doświadczeni programiści to osoby, które żadnej pracy się nie boją i w swej buńczuczności dowożą. Mają twarde umiejętności i nie boją się ich użyć. Trzeba zrobić porządki w kodzie tak starym, że już nawet starzy Indianie odpuszczają? Nie ma problemu. Na produkcji poleciał krzykliwy NPE? Senior już tam jest z WD-40 i taśmą klejącą, aby funkcjonalność dalej działała, nim nowa, lepsza wersja ujrzy światło dzienne. Kolejna runda stażystów już przyjęta i wymagają podszkolenia nim zaczną robić swoje, bo ta taśma z WD-40 ciągle tam jeszcze jest? Nasz bohater już kończy projektowanie dev kat i wewnętrznych dojo… bo trzeba. Właśnie, trzeba?

A więc doświadczenie…

Bez wątpienia doświadczenie zdobyte przy pracy jest nie do przecenienia. Znajomość tajników danego języka, te wszystkie wyrażenia regularne, wzorce projektowe itd, zresztą każdy z nas kiedyś usłyszał o 10x programmer i zapragnął nim być. Senior musi znać się na swoim programistycznym fachu… ale nie tylko. Te wszystkie tematy poboczne: trochę sieci, architektury, chmur, devopsów, „pipelinów” nie mogą być mu obce. Zrozumienie systemu i ekosystemu systemu musi być dużo szersze. Warto aspirować do rozwijania się w tych kierunkach.

Nie znaczy to, że taki „programista 10x” nagle będzie programował dziesięć razy szybciej. Nie można być bardziej w błędzie. Doświadczony programista prawdopodobnie będzie trochę szybciej tworzył rozwiązania, zapewne trochę lepszej jakości i bliżej ustalonych terminów, ale te różnice nie będą o rząd wielkości. Jeśli będą kryć się za mnożnikiem dwa, uznałbym, że jest naprawdę nieźle. Co jest największą różnicą to fakt, że są rzeczy, których nowy adept szkoły kodowania nie wymyśli i nie zrobi, kropka. Weteran tej samej szkoły wręcz przeciwnie. Wymyśli, zrobi i to jeszcze na czas. Tutaj tkwi ten hard skill, kompetencja i doświadczenie, które pozwalają przejść z abstrakcyjnego pomysłu do namacalnego rozwiązania uszytego na wymiar dla końcowego użytkownika. Gdy myślę o doświadczonych programistach, z którymi miałem dotychczas do czynienia i których cenię, to zawsze pojawiał się konkretny komponent wiedzy technicznej. Myślę, że nie da się przed tym uciec.

Czy samym tech stackiem senior żyje?

Pewnie również Ty spotkałeś/łaś na swojej drodze takich właśnie doświadczonych programistów. Natomiast czasami te ogromnie kompetentne osoby posiadające pełne zrozumienie danego problemu nie przekazują wiedzy dalej. Nie kształtują nieco mniej doświadczonych kolegów czy też zespołu. Nie oceniam czy powodem jest niechęć, czy też niemożność jej przekazania, efekt jest nadal zgubny, niezależnie od powodów. Bycie osobą, do której wszyscy zwracają się o poradę i pomoc, krótkoterminowo wpływa bardzo fajnie na samopoczucie, ale w dłuższym terminie może się okazać wyjątkowo męczące i stresujące. Nie tylko ograniczamy rozwój projektu / zespołu będąc wąskim gardłem, ale mając tak wiele na głowie, ograniczamy także swój rozwój, tkwiąc w mentalności „ja zrobię to najlepiej”. Przekazując kompetencje dalej stwarzamy sobie miejsce i szansę na podjęcie nowych wyzwań, jednocześnie dbając o to, aby rzeczy, które już stworzyliśmy, działały dalej bez zarzutu.

Projekty, w których warto uczestniczyć najczęściej są robione przez zgrane i kompetentne zespoły.

Jeśli chcesz iść szybko, idź sam. Jeśli chcesz zajść daleko, idź w grupie.

Te naprawde istotne, fajne oraz technicznie skomplikowane projekty są tworzone przez zespoły. Przez to ogromnie ważne jest odnajdywać się w większej grupie, a umiejętność współpracy i wypracowania kompromisu podczas pracy to kamień węgielny każdej zgranej grupy. Nikt nie sugeruje, aby unikać konfrontacji, gdy pewne rozwiązania są po prostu złe. Być może warto poznać powody, którymi się kierują inne osoby w swoich decyzjach? Odpowiedzialność za wyprostowanie tej sytuacji tak czy inaczej leży na barkach doświadczonego programisty. Warto natomiast zrobić to w taki sposób, aby mosty nie były doszczętnie spalone, czasami uznając że własne rozwiązanie może nie do końca być na miejscu. Jeśli się da. Jeśli się nie da, zespół czy też firma ma dużo większe problemy niż fakt, że w projekcie jest np. za dużo duplikacji, a wypuszczanie nowej wersji jest robione ręcznie. Do tego wszystkiego przydają się właśnie miękkie umiejętności, soft skill, który bywa niedoceniany wśród braci programistycznej. Oczywiście, nikt nie ma zbioru tych cech wkomponowanych w osobowość od urodzenia. Te są wyuczone jak każda inna umiejętność, być może niektórym przychodzą bardziej naturalnie i z łatwością. Wg mnie może to udowadniać co najwyżej lepsze metody jakimi je poznawano, w bardziej przyjaznym środowisku, które ułatwiło ten proces. Co za tym idzie, każdy jest w stanie przyswoić wspomniane umiejętności do pewnego stopnia. Ba, powinien być to istotny punkt w rozwoju naszych umiejętności, jeśli dostrzegasz pewne braki w tej materii.

Rozumiem doskonale, że na usta może cisnąć się od razu:

Pracując z innymi osobami, czasami trzeba im pomóc w zrozumieniu pewnych fragmentów kodu lub systemu, bo mogliśmy spędzić tak dużo czasu w jednym miejscu, że zapomnieliśmy jak to jest zaczynać. Trzeba wykazać odrobinę cierpliwości dla niezupełnie przemyślanych pomysłów, aby później wyjaśnić możliwie lepszą drogą. Może nawet się zaskoczymy, bo w trakcie dowiemy się czegoś nowego, patrząc na zadanie z innej perspektywy, która wcześniej nam nie przychodziła do głowy. Trzeba, bo chodzi tutaj o dobro zespołu jako całości, a patrząc szerzej dobro projektu. Rolą doświadczonych programistów jest dbanie o techniczną stronę systemu, a ten nie jest tworzony przez jednomyślną masę specjalistów, przez co tym bardziej potrzebne jest spojrzenie kogoś, kto faktycznie rozumie, co się dzieje. Musi to być ktoś kompetentny, nie tylko aby pilnować, ale aby nadawać techniczny kierunek danemu systemowi. Rozwój nie powinien być przypadkowym zlepkiem niespójnych decyzji, więc roztropnie będzie powierzyć nad tym pieczę doświadczonemu programiście. Natomiast, jeśli uczyni się ów rozwój udziałem wszystkich w zespole, a nie tylko jednego tytana pracy, cała grupa z chęcią podąży w ślad za interesującym wyzwaniem. Bez tego czeka nas ciągła walka z kulkami błota i brudnym kodem. Na końcu warto powiedzieć jedną istotną rzecz: senior kształtując interesujące środowisko również wygrywa, bo to środowisko ciągle będzie ciekawe i szybko się nim nie znudzi :).

Czy zatem i juniorowi worek umiejętności miękkich?

Aktualnie próg wejścia do świata IT jest relatywnie mały. Na pewno dużo mniejszy niż w czasach, gdy sam zaczynałem moją przygodę. Wtedy (czyli okolice roku 2008), będąc początkującym programistą i wykazując chociaż drobne niedociągnięcia w posiadaniej wiedzy, nie było co liczyć na pracę, a głównym celem rekrutującej osoby było udowodnienie swojej wyższości oraz Twojej niekompetencji, coś co wg mnie jest nie do pomyślenia aktualnie, mimo iż ten relikt jeszcze się marginalnie zdarza.

Sposób zdobywania wiedzy był dużo bardziej sformalizowany i bardzo mało ludzi bez studiów parało się klikaniem w komputer za pieniądze. Aktualnie jest zatrzęsienie wszelkiej maści darmowych i płatnych kursów, nie tylko IT (chyba każdy ukończył jakiś kurs na Courserze 😉 ), o dedykowanych szkołach i bootcampach nie wspomnę. Uważam, że jest to fantastyczna sprawa, bo każdy ma szansę stać się tym, kim faktycznie chce. Formalne tytuły, jeśli brak takowego kiedyś zacznie doskwierać, zawsze można dodać do swoich osiągnięć. Chętnych uczelni, które nam to zapewnią, jest zatrzęsienie.

To pokazuje, że mając ten ogrom wiedzy dostępny na wyciągnięcie ręki, głównym zadaniem, a moim skromnym zdaniem jedynym zadaniem, jest stanie się kompetentnym, w tym, co robimy. Kompetencja ta powinna wynikać ze zrozumienia problemu i z umiejętności rozwiązania tego problemu (niezależnie czy samodzielnie czy pod okiem bardziej doświadczonego kolegi lub koleżanki). Jest to bardzo istotne, bo nie chodzi o jakiś magiczny punkt zwrotny, w którym nie umiesz nic, a za chwilę w drodze olśnienia już rozumiesz wszystkie tajniki programowania. Na drodze naszego rozwoju zawsze pojawi się ktoś, kto będzie lepszy, więc nasza kompetencja to nie tylko to co aktualnie wiemy, ale to też wiedza pozwalająca zrozumieć porady i polecenia, jakie otrzymujemy, aby poprawnie wykonać zadanie. Dla mnie to jest kwintesencja bycia kompetentnym. Wraz ze wzrostem doświadczenia granica się przesuwa i coraz mniej jest sytuacji, gdy potrzebujemy instrukcji od kogoś, a więcej gdy samodzielnie wymyślamy i rozwiązujemy problemy. Z czasem sami dajemy instrukcje jak podejść do danego problemu innym. Jest to naturalna ewolucja, nie tylko znamienna dla IT, ale dla każdej profesji. Oczywiście, im więcej jest doświadczonych osób w naszym otoczeniu, tym ten proces zachodzi szybciej i jeśli posiadamy podstawowe cechy jak otwartość na ludzi, umiejętność znalezienia wspólnego języka to jest coś co będzie grało na naszą korzyść, ale samo w sobie nie powinno stanowić priorytetu. Wg mnie konsekwencja w zdobywaniu wiedzy jest kluczowa, bo drogę zawodową wybieramy nie na rok lub dwa, ale nierzadko na dekadę. W byciu kompetentnym drzemie dużo prywatnej satysfakcji i często są to kolejne drzwi otwierające się przed nami wraz z postępami, jakie robimy. Nie próbowałbym więc odwracać tego procesu.

Będąc kompetentnym bardzo szybko stajemy się samodzielni w tym, co robimy, a przez to niezależni. To wprowadza doskonałe sprzężenie zwrotne, bo pewni siebie i swojej wartości podejmujemy coraz śmielsze kroki, z których możemy czerpać coraz więcej wiedzy i dalej poszerzać swoje kompetencje.

Osobiście przedkładam kompetencje ponad umiejętności miękkie, tzn. bardziej zależy mi na tym, aby w pełni wywiązywać się z postawionych mi w pracy zadań technicznych, niż na byciu szeroko lubianą duszą towarzystwa. Wydaje mi się, że sporo osób prezentuje podejście podobne do mojego. Jest to jak najbardziej akceptowalne. Pamiętajmy tylko, że niezależnie które umiejętności stawiamy na pierwszym miejscu, warto jest rozwijać zarówno umiejętności twarde jak i miękkie.

Słowo na koniec

Podsumowując, warto jasno powiedzieć, że powyższe to moje prywatne odczucia, zarówno ogólne jak i dotyczące istoty doświadczenia w IT. Odnoszę wrażenie, że część moich znajomych po fachu podziela tę opinię, ale ponieważ nie cytuję tutaj nikogo, nie chcę generalizować. Ostatnimi czasy zauważam, że nie można zamknąć umiejętności doświadczonego programisty tylko w prostych ramach umiejętności technicznych. Umiejętności miękkie stanowią istotny komponent, bo będąc albo pretendując do miana doświadczonego specjalisty w swoim zespole bądź firmie, właśnie na Tobie spoczywa obowiązek pokazywania tej lepszej, świetlanej drogi, którą projekt bądź firma powinny podążać. To natomiast osiąga się nie poprzez przykaz, a przykład. Nim ta faza jednak nastąpi, musi być poprzedzona prawdziwą kompetencją, czego sobie i wszystkim życzę :).

Jeśli chcesz podzielić się swoim zdaniem, jestem bardzo ciekaw Twojej opinii! Nikt nie jest nieomylny i jeśli tkwię w błędzie, będę wdzięczny za wyciągnięcie mnie z tego przekonania.