Kategorie
general

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ńcze 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ś na swojej drodze takich właśnie doświadczonych programistów. Natomiat 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.

W dzisiejszych realiach projektów nie tworzy się samemu. Ba, śmiem stwierdzić, że projekty w których warto uczestniczyć najczęściej nie są robione przez jedną osobę. Może na początku, ale powtarzając porzekadło:

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 wypracowanie 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. Odpowiedzialność za wyprostowanie tej sytuacji leży na barkach doświadczonego programisty, ale 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 jest to co najwyżej dowód, że metody jakimi je poznawano były lepsze, w bardziej przyjazdnym ś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 kolejny krok w rozwoju naszych umiejętności, jeśli dostrzegasz pewne braki w tej materii.

Rozumiem doskonale, że na usta może ciśniąć się od razu:

Pracując z innymi osobami, czasami trzeba im pomóc w zrozumieniu pewnych fragmentów kodu lub systemu. Trzeba wykazać odrobinę cierpliwości dla niezupełnie przemyślanych pomysłów, aby później wyjaśnić możliwie lepszą drogą. 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ą strone 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 pieczy 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 samemu zaczynałem moją przygodę. Wtedy (czyli okolice roku 2008) jeśli jako zaczynający programista nie znałeś sie „na wszystkim” to nie miałeś co liczyć na pracę, a głównym celem rekrutującej osoby było udowodnienie swojej wyższości oraz mojej 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 popełnił 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ągnieć. Chętnych uczelni, które nam to zapewnią jest zatrzęsienie.

To pokazuje, że mając ten ogrom wiedzy dostępny na skinienie palca, 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 tutaj jest kluczowa, bo drogę zawodową wybieramy nie na rok lub dwa ale nie rzadko na dekadę. W byciu kompetentym drzemie dużo prywatnej satysfakcji i często są to kolejne drzwi otwierajace 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.

Zbliżając się do końca, osobiście wolałbym znać się na swoim fachu i nie być do końca duszą towarzystwa, niż być szeroko lubianym i umieć rozmawiać z każdym, kosztem radzenia sobie z podstawowymi zadaniami, które są moim obowiązkiem. Wydaje mi się, że sporo osób podświadomie przyjmuje to jako domyślny scenariusz. Jest to jak najbardziej akceptowalne, mając na uwadze, aby nie stało się to zarazem zwieńczeniem drogi zawodowej.

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.

W odpowiedzi na “Subiektywne spojrzenie na doświadczenie”

Dobry tekst, daję łapkę w górę, ciężko nie zgodzić się z tezą postawioną w artykule.

Dodam pół grosza od siebie, tylko pół, bo jestem jednak sporo krócej w biznesie od autora ;). Myślę, że senior musi dogadywać się z ludźmi (i oczywiście maszynami) przynajmniej na średnim poziomie, lider techniczny natomiast na przynajmniej dobrym. Mógłbym przychylić się do stwierdzenia, że jako tech-leader, istotniejsza jest komunikacja z ludźmi niż bycie super wymiataczem. W takiej sytuacji będziesz w stanie dobrać do zespołu odpowiednio kompetentnych ludzi (bo jednak masz motzne skillsy techniczne), docelowo nawet lepszych technicznie od ciebie, zgrać ich ze sobą i trzymać w kupie. Natomiast jeśli jesteś tech-leadem, który jest we wszystkim najlepszy, to albo jesteś genetycznym freakiem, albo dobierasz złych ludzi do zespołu. Albo specjalnie nie wybierasz tych najlepszych 😉
Powyższe oczywiście różni się w zależności od otoczenia w jakim pracujemy, jak duży jest to zespół, jak bardzo możemy decydować o tym kto z nami pracuje etc.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *