Przez ostatnie lata miałem okazję spotkać wielu różnych programistów. Wielu tytułowało się “starszymi programistami” (senior programmer), ale w rzeczywistości nie byli na takim poziomie. W tym tekście spróbuję wyjaśnić, jak można rozpoznać prawdziwego “starszego programistę”. Jest to moja osobista opinia, aczkolwiek nie jestem jedyny który taką wyraża.

Po pierwsze – jaki jest powszechny błąd w określeniu osoby jako „seniora”?

Przeważnie skupianie się na latach doświadczenia zawodowego. Często widzę, że ludzie z 3-5-letnim doświadczeniem są nazywani seniorami tylko z tego powodu. To ogromne nieporozumienie !! Spotkałem ludzi z ponad 3-letnim doświadczeniem, którzy nawet nie osiągnęli poziomu „średniego” (regulara).

Oczywiście lata doświadczenia w pracy są ważne – ale tylko wtedy, gdy pracujesz jako członek zespołów, w których zmuszony jesteś wyjść ze swojej strefy komfortu i stale uczyć się nowych rzeczy, poszerzając horyzonty. Lata pracy są również potrzebne, aby śledzić zmiany technologii i wiedzieć jak sobie z nimi radzić. Takie doświadczenia zmienią punkt widzenia na wiele rzeczy związanych z technologią. Frameworki, język kodu oraz jak zorganizować swoją pracę – wiedza na ich temat jest niezbędna.

Kiedy słyszę „senior”, myślę o kimś, kto jest w stanie poprowadzić innych mniej doświadczonych programistów, ocenić kod innych osób i dać cenne uwagi dotyczące możliwych poprawek. Seniorzy są biegli w zarządzaniu ryzykiem czasu wykonania systemu. Co najważniejsze – potrafią przekazywać wyżej wspomniane umiejętności współpracownikom. Jest to osoba, która może zaplanować i wykonać każdą część cyklu rozwojowego – począwszy od zbierania informacji, projektowania (ze szczegółową specyfikacją techniczną, zdefiniowanymi przypadkami testowymi, diagramami UML itp.), po kodowanie i tworzenie testów systemu. Rozumieją i wykorzystują wzorce projektowe !!! W większości przypadków opanowali biegle programowanie obiektowe i projektowanie. Wiedzą, czym jest prawdziwa abstrakcja, która ma ogromny wpływ na separację poszczególnych części kodu od siebie. Są również w stanie oszacować swoją pracę (głównie w oparciu o przygotowaną specyfikację, dlatego jest ona tak ważna).

GIT – obecnie jest wiodącym systemem do pracy jako repozytorium kodu, więc “senior” musi być zaznajomiony z przepływami i sposobami łączeń w git i technikami wdrażania takimi jak CI i CD (Continuous Delivery zawierające Continous Integration i Continous Deployment).
Jest to osoba, która nie boi się pracować z słabszej jakości kodem odziedziczonym po innych programistach (Legacy Code), ponieważ wie, jak sobie z tym poradzić. Seniorzy mogą rozmawiać o architekturze systemu lub projektowaniu komponentów. Mogą skupić się na prawdziwej architekturze i nie być zależni od frameworka. Oznacza to, że kiedy zapytasz go, dlaczego wybiera jakieś rozwiązanie, będzie mógł szczegółowo objaśnić swój wybór, jego wady i zalety.

Oczywiście obecnie istnieje tak wiele technologii, że jedna osoba nie jest w stanie znać je wszystkie. Jednak oprócz technologii, istnieją pewne zasady programowania, które są powszechnie znane i uniwersalne do zastosowania w każdym języku programowania.

Dlatego następnym razem gdy ktoś ci powie, że jest “seniorem” sprawdź, czy dana osoba jest przynajmniej na poziomie „średnim” (regular). W celu określenia tego, poproś o dowód pracy, gdzie wykorzystuje wzorce projektowe, pisze testy automatyczne (integracyjne, jednostkowe itp.). Poproś o próbkę specyfikacji technicznej i sprawdź czy zawiera takie elementy jak diagramy przepływów, sekwencji, bazy danych, klas i interfejsów. Spytaj czy przygotowała projekt architektury zanim jeszcze napisała pojedynczy wiersz kodu. Wielu z tych „seniorów” nie osiąga nawet tego, więc taki prawdziwy „regular”. Będzie on dużo lepszy niż jakikolwiek samozwańczy Senior, tytułujący się tak dlatego, że pracuje jako programista przez ostatnie 4 lata.