Rozpoczęcie pracy na stanowisku programistki lub programisty to dziś spore wyzwanie. Czasami jest to droga długa i trudna. Powodów jest sporo - część wynika z obecnej sytuacji rynkowej i dość silnej reprezentacji juniorów aspirujących do tego zawodu, część z nierealnych wymagań każdej ze stron. Prześmiewcze memy na temat zależności pomiędzy wiekiem kandydata, oczekiwanymi latami doświadczenia i czasu istnienia danej technologii stały się już kultowe. Trudno mieć 20 lat na karku i 10 lat doświadczenia w technologii, która istnieje zaledwie od roku.

Tematem dzisiejszego artykułu nie będzie na pewno to jak dostać się do IT, temat został poruszony już wiele razy, również przeze mnie i nie ma jednej dobrej odpowiedzi na to, co należy zrobić. Tematem będzie natomiast: jak długo mogę / dam radę pracować na stanowisku programisty / programistki i co czeka mnie potem?

Wczesna emerytura

Emerytura? Pewnie też, pytanie czy wytrwasz na tym stanowisku tak długo. Zawód, o którym mówimy jest jednym z bardziej stresujących zawodów. Oczywiście trudno porównywać rodzaj stresu pracownika siedzącego przy biurku i piszącego kod, do stresu lekarza czy strażaka, którzy każdego dnia walczą o życie innych. Niemniej, nieustanny nacisk na dostarczanie produktów najwyższej jakości, ciągły rozwój i szybkie rozwiązywanie problemów, w środowisku, które jest bardzo dynamiczne i podatne na powstawanie błędów, nie jest bez znaczenia przy określaniu jak bardzo ta praca potrafi być stresująca. Zgodzić się też trzeba, że wysokie wynagrodzenie, owocowe czwartki i inne benefity częściowo rekompensują te złe strony, ale czy wystarczająco? Pytanie zatem czy ucieczka ze stresującego środowiska pracy do IT to zawsze dobre rozwiązanie.

Według badań prowadzonych wśród polskich programistów około 70% z nich doświadczyło wypalenia zawodowego. Jak to rozumieć? Wypalenie zawodowe to zespół objawów, które pojawiają się w skutek przesilenia fizycznego i emocjonalnego w związku z wykonywaną pracą. Do takich objawów zaliczymy: ciągłe zmęczenie, brak satysfakcji z pracy, niechęć do miejsca pracy czy nawet udania się tam, znudzenie, pesymizm, cynizm, niskie poczucie własnej wartości czy brak zainteresowania rozwojem zawodowym. Według różnych źródeł głównym winowajcą jest stres. Prowadzi to do takich chorób jak depresja.

Po wypaleniu zawodowym trudno się pozbierać. Wydaje się, że odejście z branży będzie czymś zupełnie naturalnym, pomimo to wiele osób postanawia wziąć dłuższy odpoczynek i wrócić - często do nowego środowiska, z nowymi ludźmi, w mniej stresującym projekcie. Powodów jest pewnie kilka: pomimo wszystko dobre zarobki, praca często jest dla tych osób pasją, potrzeba wyzwań i rozwijania siebie jest dla nich ważna.

Kiedy zatem odejść na emeryturę? Branża IT jest jeszcze za młoda, szczególnie w takich krajach jak Polska, żeby mówić o osiągnięciu wieku emerytalnego przez osoby w niej zatrudnione. W skali globalnej jedynie 2,72% developerów ma więcej niż 55 lat. Jak widać emerytura może i tak, ale raczej wymuszona zdrowotnie. Pytanie czy to się opłaca?

Jak zjeść słonia?

Czy programista powinien wiedzieć wszystko? W zasadzie to praktycznie niemożliwe. Krzywa uczenia się w zawodach technicznych, które rozwijają się tak dynamicznie jak programowanie, poznawanie nowych rzeczy powoduje nieustanne odkrywanie nowych ścieżek, które odsłaniają nowe niezbadane obszary. Sprawdza się tutaj idealnie powiedzenie: im dalej w las, tym więcej drzew.

Typową zatem sytuacją jest otrzymywanie zadań w pracy, których nie wiemy jak wykonać. Brak wiedzy w danym zakresie wymaga po pierwsze umiejętności szybkiego uczenia się, po drugie wyjścia z własnej strefy komfortu. Gdy są dostępne źródła typu dokumentacja lub przykłady, taka praca pomimo, że trudna i stresująca może być nadal inspirująca. Gorzej, jeśli przyprawimy to krótkim terminem na wykonanie i dostępną szczątkową wiedzą na dany temat.

Wówczas przydatne jest wykorzystanie odpowiedniej technika "zjedzenia słonia". Nasze zadanie to taki właśnie słoń, którego musimy zjeść. Technika ta polega na tym, że zaczynamy od najprostszych rzeczy do zrobienia i składamy je ze sobą tak długo, aż otrzymamy coś większego, a ostatecznie - naszego „słonia”.

Syndrom oszusta

Drążąc temat trudnych zadań i nieustannego rozwoju, dochodzimy do powszechnego zjawiska psychologicznego - syndromu oszusta. Polega on na tym, że przestajemy wierzyć we własne możliwości, jednoznacznie umniejszając swoim umiejętnościom. Osoby dotknięte syndromem oszusta bardzo często żyją w przekonaniu, że nie zasłużyły na osiągnięty sukces i że oszukują innych. Paradoksem jest fakt, że chociaż raz w życiu dotknął on przynajmniej 70% całej światowej populacji.

Syndrom oszusta bardzo często blokuje nasz dalszy rozwój. Osoby nim dotknięte bardzo często zaprzestają rozwoju, gdyż obawiają się, że zostaną zdemaskowane. Z tym problemem można walczyć. Należy pamiętać, że do każdego sukcesu dochodzimy mały krokami. Istnieją pewne techniki, które pomagają nam zwiększać swoją pewność siebie, takie jak pomoc współpracownikom.

Syndrom oszusta jest o tyle problematyczny, że przyspiesza problem wypalenia zawodowego. Rozwój jest konieczny, ale obawa przed nim skutecznie nas ogranicza i pogłębia stres.

W prawo czy w lewo?

Praca na stanowisku programisty / programistki to nie tylko pisanie kodu. W wielu przypadkach wymaga ona podejmowania ważnych projektowych decyzji, które na kolejnych etapach istnienia projektu, będą nam towarzyszyły. Nie ma ludzi, którzy potrafią wywróżyć co się wydarzy za X czasu. Co de facto powoduje, że nie jesteśmy w stanie jasno określić czy podjęta na początku decyzja była prawidłową - łatwiej założyć, że nie. Idąc tym tropem powinniśmy być przygotowani na jej zmianę i przebudowanie naszego projektu pod te zmiany. Błędne analizy mogą doprowadzić w skrajnym przypadkach do konieczności uśmiercenia projektu i rozpoczęcia od zera.

Na fanpage’u devstyle.pl pojawiła się kilka lat temu zabawna, ale bardzo trafna grafika. Według niej programowanie w czasie pracy zajmuje około 10% czasu, reszta to walka z ludźmi, walka z maszynami i walka ze sobą. Trudno się z tym nie zgodzić. Walka z maszynami to wszelkie sytuacje, kiedy coś nie działa a powinno. Walka z ludźmi to najczęściej próby zbierania wymagań i zrozumienia domeny biznesowej, tak aby stworzyć coś przydatnego. Walka ze sobą to ciągły rozwój i wszędobylska prokrastynacja.

Ścieżka, którą podążają programiści to przede wszystkim ścieżka technologiczna. Przez pierwsze lata jest ona najistotniejsza. Obszary w których się rozwijamy pozwolą nam stać się specjalistami w danym temacie. Dojdziemy w końcu do poziomu seniora lub principala, ale nawet wtedy nie zmieni się wiele, jeśli chodzi o sam zawód. Junior i senior mają bardzo podobne zadania, podobny rozkład aktywności, oczekuje się od nich podobnych efektów. Co zatem różni juniora od seniora? Według mnie jest to zestaw umiejętności nieoczywistych takich jak estymowanie zadań, dostrzeganie z pozoru nieistotnych ryzyk czy bardziej świadome dobieranie technologii do wymagań (bez skupiania się tylko na rzeczach, które się zna) oraz doświadczenie. Doświadczenie doświadczeniu nie równe - inaczej ocenimy je, gdy 10 lat spędzimy w jednym projekcie w korporacji, a inaczej gdy przez okres 10 lat zmienimy projekt 5 razy.

Powyżej seniora nie ma już nic. Dalszy rozwój zależy tylko od tego, w którą stronę będziemy chcieli iść. Musimy wybrać - ścieżka techniczna, ścieżka zarządzania czy powrót do początku.

Ścieżka techniczna

To chyba najbardziej oczywista droga - będąc seniorem zdobyliśmy wiele doświadczenia technicznego. Mamy spore rozeznanie w różnych technologiach, prawdopodobnie pisaliśmy w więcej niż jednym języku. Pewne rzeczy wykonujemy bardzo świadomie, dostrzegamy słabe i mocne strony różnych podejść. Kolejnym krokiem byłoby zatem zostanie architektem. Kim jest architekt?

Architekt oprogramowania najczęściej nie koduje. Jest to osoba, która projektuje całe systemy, tak aby wybrać najbardziej optymalne rozwiązanie pod problem biznesowy. Co ciekawe - ten zawód narodził się wraz z narodzinami całej branży. Początkowo architekt był troszkę bardziej doświadczonym programistą - z czasem jednak systemy zaczęły się do rozrastać do ogromnych rozmiarów. Dziś to właśnie architekt ma całościowy obraz całego projektu, dzięki czemu może poruszać się pomiędzy różnymi zespołami i pomagać rozwijać ich części zgodnie z poczynionymi założeniami.

Co ważne - architekt zawsze musi być na bieżąco. Powinien rozumieć nowości, nie bać się ich, ale też umieć krytycznie na nie spojrzeć.

Ścieżka managerska

Architektów wbrew pozorom nie ma wielu na rynku. W związku z wymaganiami tego stanowiska i ogromną wiedzą, która jest potrzebna - wielu programistów wybiera drugą ścieżkę - ścieżkę zarządzania. Sprawa jest tutaj dużo prostsza - zaczynamy od zostania Team Leaderem lub Project Managerem. Z racji posiadanej wiedzy technicznej łatwiej nam się dogadać z zespołami technicznymi i określić cele zespołu oraz projektu.

Niestety w wielu przypadkach oznacza to rezygnację z pisania kodu, a postawienie na rozwijanie umiejętności miękkich i związanych z prowadzeniem ludzi oraz projektów.

A może powrót do korzeni?

Innym pomysłem może być cofnięcie się do pozycji juniora w zupełnie nowej technologii. Daje to świeże spojrzenie, szansę na zdobycie nowego doświadczenia, ale często oznacza też zredukowanie dotychczasowego wynagrodzenia. Osobiście znam kilka osób, które wykonały ten krok i z perspektywy czasu nie żałują. Dziś rozumieją więcej, bardziej świadomie patrzą zarówno na backend i frontend. Bardziej świadomie idą jeszcze raz tą samą ścieżką - by na jej końcu jeszcze raz stanąć przed kolejnym takim samym wyborem.

Crunch

Jednym z najbardziej stresogennych obszarów IT jest GameDev. Najczęściej wymagana jest tam największa wiedza, terminy są bardzo krótkie, pracy jest masa a oczekiwana jakość powinna być na naprawdę wysokim poziomie - finalnie ich produkty trafiają do dość wymagającej grupy odbiorców. Jeśli dodamy do tego najniższe w całej branży zarobki i zjawiska takie jak crunch - to zniechęcimy chyba każdego zdrowo myślącego do pracy przy produkcji gier. Chyba że to pasja...

Czym jest crunch? To zjawisko, polegające na przymusowej pracy w nadgodzinach podczas produkcji gier. Niejednokrotnie powoduje, że w pracy jest się po 65 - 80 godzin bez przerw, często bez dodatkowego wynagrodzenia za nadliczbowe godziny. Zjawisko jest to tak powszechne, że organizacje takie jak Game Workers Unite walczą z nim na drodze oficjalnej, ale pomimo prób pokonania go - istnieje i ma się dobrze.

I niestety za crunchem nie zawsze stoi sukces - spójrzmy na Cyberpunk 2077, którego pracownicy funkcjonowali w tym trybie, szczęśliwie w Polsce, więc zostali przynajmniej za nadgodziny wynagrodzeni zgodnie z obowiązującym prawem. Wiemy jak Cyberpunk na premierę wyglądał - chyba lepiej pozostawić to bez komentarza.

Expired?

Jeśli przeanalizujemy powyższe to zawód programisty / programistki posiada wiele zalet. Przede wszystkim daje niesamowite szanse rozwoju, dobre zarobki i poznawanie świata z troszkę innej strony - bardzo dobry programista musi zrozumieć domenę zanim napisze pierwszą linijkę kodu. Ok, może troszkę przesadziłem z ostatnim sformułowaniem, ale sens mam nadzieję udało mi się przekazać.

Powyższe plusy zmniejszają stres wynikający z pracy, ale go nie niwelują. Dlatego właśnie coraz więcej osób „ucieka z raju”. Presja czasu i wyników, hermetyczne środowisko, patologie wynikające z pracy w korporacjach to wszystko oddziałuje na ludzi. Moim celem nie jest odstraszenie kogokolwiek od pracy w IT - moim celem jest uświadomienie, że ten świat ma też swoje czarne strony. Zdobycie minimum wiedzy dla osoby z zewnątrz tego świata to najczęściej rezygnacja z czasu z przyjaciółmi, hobby, budowania relacji z bliskimi przez pierwszych kilka miesięcy nauki. Widziałem to nie raz. Sam tego też doświadczyłem, chociaż w moim przypadku zaczynałem dość wcześnie, jako 22-latek, bez bagażu rodzinnego.

Podsumowanie

Odpowiadając na pytanie postawione na początku tego artykułu. Jaka jest data ważności programisty? W większości sytuacji kilka / kilkanaście lat. Osoby, które znajdą rozwinięcie swojej ścieżki zawodowej lub te z wysoką odpornością na stres, prawdopodobnie dłużej. A ile? Nie wiem. Jest to bardzo indywidualne.

Wiem natomiast jedno - pewne „stresory” można wyeliminować lub conajmniej złagodzić ich wpływ na ludzi, a zależy to często od firm i pracujących w nich managerów.