Jak zostać Seniorem - odpowiada Software Developer

W dzisiejszych czasach „Senior” to bardzo względna pozycja. W niektórych firmach to konieczne 10 lat doświadczenia, a w niektórych wystarczą tylko 3 lata, przy dobrej znajomości danej technologii. Czwórka Seniorów z firmy Ericsson odpowiedziała na nasze pytania, jak doszli do tego tytułu oraz co to za sobą przyniosło.

Druga osoba, która pojawia się w tym cyklu, to Piotr Lewandowski - Senior Software Developer.

Kim dla Ciebie jest Senior? Jak słyszysz Senior Software Developer, to co przez to rozumiesz?

PL: To osoba, która cechuje się doświadczeniem. Nie tylko znajomością produktu, czy języków, ale właśnie sprawnością w pisaniu oprogramowania, jak i szukaniu oraz naprawianiu błędów. Często posiada intuicję, która pozwala jej szybciej zlokalizować błędy lub ich całkowicie uniknąć.

Czy spotykasz SE z tego opisu, pracując obecnie w Ericsson?

PL: Tak. Na bazie tego, co wcześniej powiedziałem, to zdecydowanie ludzie potrafiący rozwiązywać problemy, czerpiąc z doświadczenia, ale też tak zwanej „intuicji inżynierskiej”.

Czy będąc początkującym Software Developerem, spotkałeś na swojej drodze kogoś, kto wpłynął na kształt Twojej kariery? Czy to kwestia własnego zmierzania w obranym kierunku?

PL: Ani jedno, ani drugie. Wydaje mi się, że powoli w czasie układało się tak, a nie inaczej. Starałem się też ciągle „nastawiać” na programowanie i rozwiązywanie problemów. To było chyba jedyne świadome działanie w tym kierunku.

Postawiłem na robienie tego, do czego moim zdaniem jestem stworzony, a reszta potoczyła się sama. Myślę, że fakt, iż jestem ciekawski, pomógł mi w znalezieniu się tu, gdzie teraz jestem. Dzięki temu zadawałem pytania, poznawałem ludzi i dawałem się poznać, ale bardziej jako inżynier niż karierowicz pnący się po szczeblach.

Czy był w Twojej karierze moment, kiedy wyraźnie musiałeś zdecydować, w którym idziesz kierunku?

PL: Nie mogę takiego dokładnie zlokalizować. Zawsze chciałem pracować jako deweloper. Wiadomo, że obecnie to wiąże się w jakiejś części także z testowaniem, jednak stawiałem głównie na deweloperkę.

Inną ciekawą sprawą jest to, że z perspektywy czasu, wybór pracy w Telco determinuje moje wybory kolejnych pracodawców. Przejście do gamedevu czy embedded byłoby lekko utrudnione, ze względu na doświadczenie w konkretnej branży i sądzę, że w drugą stronę jest tak samo.

Co poza zarządzaniem zespołem może robić doświadczony programista?

PL: Po pierwsze, uważam, że doświadczony programista nie jest od tego, aby zarządzać zespołem. Oczywiście, może pomóc. Łatwiej jest mu estymować złożoność problemów i to on wie, kto ewentualnie najlepiej może sobie poradzić z problemem, ale nie jest on stricte od zarządzania zespołem. Moim zdaniem,  dojrzały zespół niejako powinien zarządzać się sam. Poza tym jest Scrum Master lub osoba w podobnej roli i to ona powinna pomagać w zarządzaniu.

Co do meritum, to doświadczony programista może mieć wpływ na rozwój produktu. Często może działać jako architekt lub osoba, która wpiera go w wyborze rozwiązań, które trafią do finalnego produktu. Może także wspomagać Product Ownera w planowaniu backlogu.

Poza tym doświadczeni programiści mogą pomagać osobom z mniejszym doświadczeniem - różnymi praktykami mentorskimi. Mogą organizować/prowadzić Coding Dojo lub Kata, czy też robić Code Review połączone z wyjaśnieniem, co i dlaczego jest do poprawy oraz jak można to zrobić.

Często te doświadczone osoby mogą mieć też wgląd w dalekosiężne i strategiczne cele firmy, a czasem mogą mieć nawet wpływ na wybory na tym poziomie. Dodatkowo takie osoby często zajmują się poprawianiem jakości kodu - same go poprawiając lub wskazując, co jest do poprawy - z racji pracy w danym fragmencie produktu albo zostając Product Guardianami.

Jak radzić sobie w sytuacji, gdy do zespołu zaczynają trafiać młode osoby, szybsze w uczeniu się i działaniu? Czy zaczynasz zauważać swoje ograniczenia wynikające z wieku?

PL: Mam 34 lata i nie widzę takich problemów. Raczej problemem jest to, że — z racji mojej pozycji — nie mam już tyle czasu na programowanie, bo muszę też skupić się na rozwiązywaniu problemów i ogarnianiu pracy na wyższym poziomie (cały zespół lub feature).

Oczywiście ludzie młodzi potrafią przyjść z większą znajomością języków lub najnowszych standardów (na które niekoniecznie jest miejsce jeszcze w produkcie ze względu na kompilator, środowisko, czy jakieś wymagania legacy). Potem jednak widać brak doświadczenia, zwłaszcza jeśli chodzi o znajomość produktu i pracę z dużymi projektami. Takich rzeczy na studiach na przykład nie uczą, bo po prostu nie mają jak.

Jakie są atuty bycia Seniorem poza wynagrodzeniem?

PL: Wydaje mi się, że większość tego, co jest odpowiedzią na pytanie o obowiązki, tutaj również pasuje. To, że mamy wpływ na to, co się dzieje w firmie, jest zdecydowanie atutem. Można także czasem otrzymać odrobinę szacunku od mniej doświadczonych kolegów - przychodzą z pytaniami, chcą się rozwijać itp.

Jak dzielić się wiedzą, jednocześnie wykonując swoje obowiązki?

PL: Wydaje mi się, że po pierwsze, potrzebny jest upór, aby znaleźć na to czas. Przekonać kierownictwo, ale też współpracowników, że się to opłaca.

Osobiście prowadziłem w jednym z zespołów Dojo/Kata co tydzień, tylko po to, żeby podnieść ogólny poziom programowania, ale też współpracy (pair programming, TDD itp.).

Poza tym warto dbać o jakość feedbacku, czy to z pracy bieżącej na retro, czy też w komentarzach w czasie code review. Można podejść do osoby i wyjaśnić, dlaczego coś nie jest dobrą praktyką oraz jak to powinno wyglądać.

Czasem w firmach prowadzone są też różnej maści Community of Practice. Warto, w miarę możliwości, udzielać się również w nich, a także zachęcać do udziału inne osoby, z którymi się współpracuje.

Czy spotkałeś się ze szklanym sufitem w IT? Szklany sufit to możliwy awans, który w praktyce się nie zdarza. Jeśli tak, to jak myślisz, dlaczego tak się dzieje?

PL: Na szczęście, raczej nie. W moim przypadku rozbijało się to raczej o brak headcountu, czyli problemu systemowego.

Natomiast, niestety, spotkałem się z mniej lub bardziej nieświadomym, niezdrowym traktowaniem koleżanek w pracy. Myślę, że to problem branży IT ogólnie. Nie mówię teraz o Ericsson, bo tu to zjawisko najmniej jest dla mnie widoczne. Te niezdrowe praktyki to traktowanie „z góry”, jako osoby „gorsze”. Na przykład spychanie ich do roli testerów albo pokazywanie (świadome lub nie), że mamy mniejsze zaufanie do ich możliwości, wiedzy czy też kodu, które stworzyły.

Czemu tak się dzieje, nie wiem do końca, ale wydaje mi się, że gdzieś kiedyś tak się „ubzdurało”, że tak jest i już. Co ciekawe, bardziej odczuwam ten problem teraz, niż dziesięć lat temu. Może zabrzmieć to kontrowersyjnie, ale wydaje mi się, że może to być dlatego, że zawód programisty stał się bardziej otwarty (ale też mniej stygmatyzowany, nie jest już traktowany jako mocno „nerdowski”, czy też hermetyczny). To powoduje, że do firm  trafiają osoby, które mają różne poglądy, spojrzenie na świat, a także mające różny background i to wszystko składa się na atmosferę w pracy. Mam nadzieje, że tak, jak odstygmatyzowano zawód programisty jako takiego, tak samo uda się wyplenić takie podejście do kobiet pracujących jako programistki.

O autorze:

Piotr Lewandowski pracuje w Ericsson łącznie ponad 4 lata. Obecnie zajmuje stanowisko Senior Software Developer w dziale Capacity. Po pracy zajmuje się między innymi fotografią.