Junior developer to nie stanowisko – to stan umysłu

W wielu firmach junior developer to osoba, od której starsi koledzy opędzają się jak od muchy, bo ciągle zadaje niewygodne pytania. W innych traktowani są jako inwestycja jeszcze nieprzynosząca spodziewanych dochodów (czyt. zarabiają niewiele, ale mimo wszystko więcej, niż zarabia na nich firma). Mam jednak wątpliwości, czy jest to rzeczywiście tylko stanowisko, przysługujące programistom wchodzącym dopiero na rynek pracy, czy raczej może kryje się za nim coś więcej.

Poznajcie Benedykta – świeżo upieczonego absolwenta jednej z wiodących uczelni technicznych w kraju na kierunku informatyka. Benedykt posiada trochę doświadczenia w zakresie tworzenia aplikacji klasy akademickiej w technologii Java. Benedykt właśnie rozpoczyna swoją pierwszą pracę. Wie, że jeżeli poświęci mu się trochę czasu i skontroluje tworzony przez niego kod, będzie wartościowym członkiem zespołu.

Brakuje mu jednak szerszego spojrzenia na oprogramowanie. Jego dylematy programistyczne ograniczają się do wyboru czy w danym przypadku zastosować float czy double. Słyszał o zasadach SOLID, ale nie do końca rozumie żart „ta klasa ma tylko jedną odpowiedzialność – zarządzanie wszystkim”. Architektura aplikacji to dla Benedykta sposób podziału plików z kodem na foldery, a dowolnie skomplikowaną logikę biznesową potrafi opisać zbiorem anemicznych encji i bogatych serwisów. Za najlepsze narzędzie do modelowania domeny aplikacji, uważa schemat tabelek w bazie danych.

Benedykt awansuje!

Mijają dni, miesiące, lata, aż w końcu Benedykt ma na tyle doświadczenia, że jego szef postanowił mu dać awans. W końcu z profilu na LinkedInie może skasować od dawna drażniący go dopisek „junior”, zostawiając samego developera. Od początków swojej kariery Benedykt zebrał już sporo doświadczenia w Javie, a koledzy mówią na niego IntellJ-ninja, ze względu na jego imponującą znajomość skrótów klawiszowych.

Benedykt już wie, że architektura aplikacji to nie tylko hierarchia folderów i jest dumnym praktykiem architektury warstwowej. Każda jego aplikacja ma warstwy, których odpowiedzialności są jasno odseparowane. Dalej brakuje mu trochę finezji w zakresie środków programistycznego wyrazu, ponieważ wciąż głównym jego orężem są anemiczne encje, ale nie widzi w tym nic niepokojącego – skoro pisane przez niego oprogramowanie działa na tyle dobrze, że dostał niezłą podwyżkę, to wszystko gra. Za Benedyktem i jego kolegami z zespołu nie przepada jednak tzw. biznes, ponieważ zawsze jak się z nimi spotykają, nie mają nawet szansy dokończyć wizji, w jaki sposób nowy projekt ma pomóc im w zarabianiu większej ilości pieniędzy. Spotkanie szybko przeradza się w dyskusję, czy między jednym komponentem, a drugim powinni wymieniać JSONa czy XMLa.

Senior Benedykt

Przeleciało kolejnych kilka lat, Benedykt nauczył się już w zasadzie wszystkiego o Javie i ma wieloletnie doświadczenie w tworzeniu oprogramowania biznesowego, w związku z czym, zapada decyzja o awansowaniu Benedykta na stanowisko senior developera. Młodzi, początkujący programiści patrzą na Benedykta jak na wyrocznię. Benedykt poproszony o pomoc przez junior developera potrafi rzutem oka zapoznać się z wyjątkiem, który właśnie rzuciła aplikacja i po minucie zaskoczyć nowicjusza prowokującym pytaniem „ja już wiem gdzie jest błąd, a Ty?”. Biedny junior nie dość, że nie wie, gdzie jest błąd, to jeszcze zastanawia się po co Benedykt go pyta, czy wie co jest nie tak – przecież jakby wiedział, to by go nie wołał. Podczas spotkań z biznesem dyskusje zespołu rozwinęły się jeszcze bardziej – oprócz oczywistego wyboru formatu danych, następuje wybór czy wykorzystać RabbitMQ czy NServiceBus.

Z perspektywy Benedykta wszystko jest super – zarabia duże pieniądze, potrafi kod zajmujący 10 linii zmieścić w jednej, a koledzy z pracy najczęściej uzasadniają swoje wybory programistyczne zdaniem „Benedykt tak powiedział”. Jedna tylko rzecz nie daje mu spokoju. Czasami, gdy popija kawę w firmowej kuchni słyszy podekscytowane głosy młodych programistów, opowiadających sobie z przejęciem o nowościach, które poznali na niedawnej konferencji. CQRS, DDD, mikroserwisy, serverless – wszystko to przewija się w ich dyskusjach bardzo często. Na każdy z tych tematów Benedykt coś wie. Nie ma innego wyjścia – nawet w jego zespole młodsi koledzy coraz śmielej mówią o tym, że warstwy zamieniliby na ports & adapters. Na szczęście autorytet Benedykta jest niepodważalny, wobec czego nowy projekt realizowany jest w dobrze mu znany sposób. Zanim jeszcze ktokolwiek miał szansę napisać choć jedną linijkę kodu, Benedykt sprytnie założył repozytorium i dodał standardową strukturę katalogów. Powrzucał też do nich trochę klasycznych encji i pustych klas z nazwami kończącymi się na Service oraz komentarzem o treści „implementacja logiki przetwarzania” w treści. Uchronił się w ten sposób przed zakusami stosowania innych niż jego koncepcji i sposobów pisania kodu. Projekt się rozwija, a Benedykt coraz boleśniej czuje ciężar dodawania nowych funkcji, ponieważ to na nim, ze względu na największe doświadczenie, spoczywa ciężar implementacji najbardziej skomplikowanych przypadków. Gubi się powoli w ogromnej plątaninie if-ów, ale mimo wszystko udaje mu się spełnić każdą prośbę biznesu. Jest z tego dumny i już zaczyna myśleć o pójściu po podwyżkę i awans na stanowisko architekta.

Czego uczy nas historia Benedykta?

Czy Benedykt junior i Benedykt senior naprawdę się od siebie bardzo różnią? Z jednej strony oczywiście tak – stopień znajomości technologii jest nieporównywalny. Młody Benedykt umie pisać programy, ale starszy Benedykt nie dość, że umie zaimplementować jakiś algorytm, to bierze też pod uwagę zużycie pamięci, wykorzystanie innych wątków czy specyficznych struktur danych. Poziom doświadczenia „obu” Benedyktów jest diametralnie różny. Z drugiej strony, pod pewnym względem są do siebie bliźniaczo podobni. Benedykt z czasów junior developera, jak i Benedykt z czasów senior developera, to programiści, którzy niewiele uwagi przykładają temu co tworzone przez nich oprogramowanie ma robić – liczy się tylko to jak. Benedykt w trakcie swojej kariery nie korzystał z możliwości rozwoju – nie uczestniczył w konferencjach, nie czytał specjalistycznych książek, nie interesował się niczym innym, tylko pisaniem kodu. Mentalnie młody i stary Benedykt to te same osoby! Benedykt w swojej głowie nigdy nie zakończył etapu junior developera – on dalej się na nim znajduje.

Mówi się, że są programiści i klepacze kodu. To, co odróżnia pierwszych od drugich, to umiejętność szerszego spojrzenia na postawiony problem, umiejętność uwolnienia się od szczegółów implementacyjnych związanych z daną technologią, jak również umiejętność rozmowy z klientem, zebrania od niego wymagań i dogłębnego zrozumienia rozwiązywanego przez tworzone oprogramowanie problemu. Niestety bardzo często spotkać można na swojej drodze starego programistę, będącego rzeczywiście mentalnym juniorem. Taka sytuacja ma miejsce, czasem z lęku przed czymś nowym, nieznanym i jeszcze nierozumianym. Czasem wynika ze ślepej pogoni za nowinkami, a czasem ze zwykłego lenistwa i wygodnictwa.

Jeżeli zaczynasz u siebie podejrzewać, że zmieniasz się powoli w Benedykta, jak najszybciej zdiagnozuj przyczynę i zacznij kurację – przeczytaj książkę o nowym podejściu, pojedź na konferencję, zrób prezentację na jakiś temat techniczny dla ludzi z pracy. Zrób cokolwiek, żeby nie stać się Benedyktem.

  • BURAS

    Podoba mi się to przemyślenie. Kto stoi w miejscu, ten się cofa. Pozdrawiam POLPETRUS :)

Post Navigation