Przebranżowienie cz.4

21 miesięcy. Tyle było potrzebne abym z gościa, który nie rozumie czym jest programowanie obiektowe stał się typem który pisze aplikacje bankowe i jeszcze na tym zarabia. Jak do tego doszło? Nie wiem.

Tak bym mógł napisać gdybym próbował skomponować szlagier disco polo o IT, ale rzeczywistość jest bardziej prozaiczna, gdyż jak najbardziej wiem jak do tego doszło, a na dodatek zamierzam się z wami tą wiedzą podzielić na wypadek, gdybyście również zapragnęli spróbować szczęścia w programowaniu.

To czwarty i jednocześnie ostatni artykuł z serii „Przebranżowienie”, więc zanim przejdziemy do sedna, przypomnijmy sobie co wydarzyło się wcześniej:

• Przebranżowienie cz.1
• Przebranżowienie cz.2
• Przebranżowienie cz.3

tl;dr;

Najpierw opisałem swój tzw. „background” czyli przelotne przygody z kodem w liceum i na studiach, inne zawody których się imałem oraz powody, które skłoniły mnie do wejścia w IT. Następnie zająłem się początkami w nauce programowania: od czego zacząć i na czym się skupić. W trzeciej notce skupiłem się na przedstawieniu wartościowych źródeł wiedzy w sytuacji kiedy nie mamy mentora i wszystko musimy ogarniać samodzielnie.

A czym zajmiemy się dzisiaj?

Wpis rozpoczniemy od prywaty, czyli jak to się wszystko zaczęło. Potem będzie trochę cyferek, statystyk i podsumowania mojej drogi do świata IT. Następnie przeanalizujemy ją i zastanowimy się czy nie dałoby się szybciej, bardziej wydajnie. Opiszę jak wygląda dzień z pracy inżyniera oprogramowania w stopniu juniora. A na koniec zastanowimy się czy wciąż warto próbować dostać się do IT.

---

Przygoda rozpoczęła się od sfrajerowania. Pracowałem jeszcze wtedy jako nauczyciel angielskiego w jednej z polskich szkół online. Stawki były niezłe, praca z domu, uczniowie ambitni i weseli. Niestety na samozatrudnieniu, ale za to z obietnicą podwyżki już po roku.

No to pracowałem i dawałem z siebie te legendarne 110% polegające na tym, że prywatny czas spędzałem na projektowaniu zajęć tak aby były ciekawsze i bardziej wciągające od suchych ćwiczeń z książki. Efektem była popularność wśród uczniów i jeden z mniejszych wskaźników rezygnacji z kursu. Niestety (albo i „stety” jak widzę z perspektywy czasu), kiedy po roku szkolnym zgłosiłem się po podwyżkę, zostałem odesłany z kwitkiem ze względu na zbyt mały staż w ichniej szkole. Cóż, nie szkodzi, miałem przygotowany plan „B”.

W tym momencie, już dobrze wiedząc gdzie mogę sobie wsadzić obietnice mojej firmy, dałem sobie spokój z nadgodzinami, a zamiast tego skupiłem się na uczeniu samego siebie czym są klasy, konstruktory, wyjątki i cała reszta obiektowej bandy. Minął kolejny rok szkolny po którym znowu zaproponowano mi stawkę jak dla początkującego. Tym razem mogłem jednak z satysfakcją powiedzieć „Nie, dziękuję” i zerwać współpracę. Happy end?

Hola, hola! Nie tak szybko!

Tak się wtedy złożyło, że we wrześniu tamtego roku wyjechałem do Chin z rodziną i przyszło mi przez kolejne 9 miesięcy żyć na garnuszku u teściów. Nie zmarnowałem tego czasu i pilnie szkoliłem się w kolejnych aspektach pracy programisty, pisałem pierwsze projekty i przygotowywałem CV. Żeby nie przedłużać, podrzucę suchy timeline jak to wyglądało aż do momentu zatrudnienia:

1. Sierpień 2022: Pracodawca odmawia obiecanej podwyżki. Decyzja o przebranżowieniu zapadła.
2. Grudzień 2022: Po dość niemrawym początku polegającym głównie na oglądaniu tutoriali z YT, wykupuję kurs na Codegym i zabieram się za temat na poważnie. Czas: start!
3. Wrzesień 2023: Kończę pracę jako nauczyciel i wyjeżdzam do Chin gdzie znajduję dodatkowy czas na naukę.
4. Styczeń 2024: Piszę pierwszy samodzielny projekt.
5. Luty 2024: Uczę się wzorców projektowych.
6. Marzec 2024: Piszę drugi samodzielny projekt, już do CV.
7. Kwiecień 2024: Zaczynam wysyłać pierwsze, nieprofesjonalne CV. Uczę się Spring Boota.
8. Maj 2024: Daję sobie spokój z wysyłką CV, robię kolejne kursy na Udemy.
9. Czerwiec 2024: Zaczynam bardziej dojrzały projekt, wysyłam „profesjonalne CV”
10. Lipiec 2024: Pierwsza rozmowa kwalifikacyjna, nieudana.
11. Sierpień 2024: Druga rozmowa kwalifikacyjna, udana.
12. Wrzesień 2024: Podpisuję umowę na stanowisko młodszego inżyniera oprogramowania. Stop!

---

Licząc czas od pierwszego, nieśmiało napisanego „Hello World!” w Javie do momentu podpisania umowy o pracę, wyszło dokładnie 636 dni, lub inaczej: 1 rok, 8 miesięcy i 27 dni.

– Ok, już wiemy ile to zajmuje, ale chcielibyśmy wiedzieć ile kosztuje takie przebranżowienie?
– W moim przypadku niewiele, 260zł za kurs na Codegym, kilkanaście kursów Udemy max. 50zł za sztukę, a na koniec kilka książek. Ale tu musicie wziąć pod uwagę, że cały cykl nauki opracowywałem sam. Jeśli chcecie czuć się bardziej „zaopiekowani” na waszej drodze, możecie skorzystać z bardziej spersonalizowanych szkoleń lub mentoringu, który kosztuje odpowiednio więcej.

Czy dałoby radę szybciej?

Jak to mówią: mądry Polak po szkodzie. Teraz, będąc juniorem, mogę z bezpiecznej perspektywy oceniać swoją drogę, wiem co było warte wysiłku, a gdzie marnowałem czas na rzeczy z których w pracy nie korzystam i które do jej zdobycia mi się nie przydały. Wtedy jednak nie miałem tego komfortu i starałem się nauczyć jak najwięcej, aby tylko wpasować się w wymagania wszystkich pracodawców.

Największy błąd jaki popełniłem to fakt, że zabrałem się za naukę programowania tak późno. Powinienem był to zrobić jeszcze przed covidem, jak byłem bezdzietnym kawalerem który pracował w Chinach, a po dniówce wracał do jednopokojowego mieszkania i z nudów toczył nierówną walkę z karaluchami. Lepiej by dla wszystkich wyszło gdybym zostawił robactwo w spokoju i już wtedy wziął się za klasy i metody.

A tak w ogóle to najlepiej gdybym nakupił wiadro Bitcoinów kiedy były jeszcze po złotówce za kilo.

Tym niemniej, jeślibym miał się cofnąć w czasie i zacząć uczyć Javy po raz wtóry, wiedząc jak to dalej będzie wyglądać, myślę, że śmiało mógłbym się wyrobić w mniej niż rok:

Faza 0: Fail fast (max 1 miesiąc)

Programowanie jest fajnym zawodem, ale nie dla każdego. Jednemu nie spodoba się nieprzewidywalność tego fachu i ciągły przymus dokształcania się. Drugi woli popracować fizycznie, a trzeci preferuje kontakty z klientami.

Dlatego zanim na poważnie zabierzecie się za przebranżowienie, zróbcie sobie mały test i spróbujcie przeczytać jakąś książkę o nauce języka programowania albo obejrzyjcie kurs na YT, od początku do końca. Jeśli to was nie znudzi to znaczy, że jesteście gotowi na więcej i możecie śmiało inwestować w samorozwój.

Faza 1: Podstawy języka (6 miesięcy)

Wciąż obstaję przy tym, że Codegym był dla mnie świetnym miejscem do nauki Javy i nie wybrałbym innej ścieżki, nawet tańszej i szybszej. Pół roku jest jak najbardziej optymalnym czasem żeby przyswoić sobie składnię i nauczyć się co jest do czego, a na koniec strzelić sobie jeszcze mały projekcik – jeszcze nie do CV, ale dla samego siebie.

Faza 2: Framework (min. 1 miesiąc)

Znając podstawy, czas nauczyć się jak pisze się komercyjnie. Takie rozwiązania jak Spring Boot oszczędzają czas i ograniczają chaos w kodzie, korzysta się z nich łatwo, aczkolwiek pod tą fasadą kryje się masa zależności które warto opanować żeby umiejętnie korzystać z frameworka i… dobrze wypaść na rozmowie kwalifikacyjnej. Teoria powinna zająć około miesiąca, a resztę ogarniecie już w praktyce, pisząc projekt pod CV.

Faza 3: Narzędzia (2 miesiące)

Niektóre narzędzia, np. Maven czy Git powinniście zacząć obsługiwać już w fazie pierwszej, zaś teraz jest świetna pora na naukę całej reszty, zaczynając od SQLa a kończąc na pipeline’ach. Do ogarnięcia przed napisaniem projektu:

• SQL z wybranym DBMS-em (np. Postgres)
• Hibernate
• Docker
• CI/CD (np. Jenkins albo coś od GitHub/GitLab)

Możecie tu dołożyć jeszcze Kubernetesa i jakiegoś dostawcę chmurowego, ale to już bardziej zaawansowane tematy więc można to odłożyć na później.

Faza 4: Projekt do CV (min. 1 miesiąc)

O ile wcześniejszy projekt/-y, robiliście dla siebie: dla własnej satysfakcji i potwierdzenia swoich umiejętności, o tyle w CV chcecie mieć coś możliwie najbardziej profesjonalnego i skrojonego pod przyszłego pracodawcę. A tymi w Javie bardzo często są banki. Hmm, tylko jaki projekt sprawiłby wrażenie na rekruterze w branży bankowej?

Taki:

- Java 21 z użyciem wątków wirtualnych i programowania funkcyjnego (plus Maven i Spring Boot)
- baza danych Oracle obsługiwana przez JDBC
- architektura mikroserwisowa z użyciem Eureki i Gatewaya
- wzorce projektowe: Builder, Fasada, (Abstract) Factory
- mikroserwisy kontaktujące się miedzy sobą za pośrednictwem Kafki (Producer/Consumer)
- testy jednostkowe w JUnit + Mockito
- testy integracyjne w RestAssured + Testcontainers
- przejrzysta historia commitów i branchy w Gicie
- podpięty pipeline który automatycznie testuje projekt po każdym merge'u i robi deployment (np. na AWS)

Do was należy „tylko” wymyślenie pomysłu na appkę która mogłaby korzystać z powyższych technologii. Potem już z górki. Nie wahajcie się korzystać z pomocy AI, ale nie kopiujcie bezmyślnie wszystkiego co wam podpowie, bo na rozmowie o pracę bez wątpienia padną pytania o wasz projekt: dlaczego coś zrobiliście w dany sposób, a nie inaczej?

Chociaż napisanie takiego molocha może się wydawać sporym wyzwaniem dla początkującego, to pamiętajcie, że nie musicie czekać z wysyłką CV do zakończenia prac. Jeśli solidnie zabierzecie się do tematu, to już po kilku tygodniach kod będzie nadawał się do waszego resume (które notabene można śmiało napisać po angielsku, w tej branży to standard). Jest wiele narzędzi do tworzenia CV, ja korzystałem z minimalistycznego GreatResume który oferuje schludne szablony i jest łatwy w obsłudze. A „za darmo” to zawsze uczciwa cena. 😉

Interview

Pierwszą rozmowę o pracę zaoferowała mi duża, międzynarodowa korporacja zajmująca się telekomunikacją. Całość trwała pół godziny i od razu po zakończeniu wiedziałem przed samym sobą, że w najlepszym wypadku wypadłem średnio. Co poszło nie tak?

Najbardziej koncertowo zawaliłem pytanie o algorytmy – rzecz, którą kompletnie zaniedbałem w trakcie nauki. Zatem kiedy otrzymałem pytanie:

„Proszę wytłumaczyć jak działa sortowanie bąbelkowe”

jedyne co mogłem zrobić to próbować zmienić temat jednocześnie z całych sił powstrzymując się przed rzuceniem suchara o madkach i ich bombelkach, który już miałem na końcu języka.

Na odpowiedź przyszło mi czekać ponad tydzień i była, rzecz jasna, odmowna, ale może to i dobrze, bo pół roku później były w tej firmie masowe zwolnienia, więc długo i tak bym tam nie zagościł.

No i druga sprawa: dzięki temu udało mi się dostać moją aktualną pracę o której złego słowa nie powiem, a największą zaletą w porównaniu do poprzedniczki jest robota zdalna z jedynie sporadycznymi wizytami w biurze.

A o co tam pytali?

Zanim przyszło do samego „interview„, dokonał się cały przesiew kandydatów. Chętnych na stanowisko było około 200 osób. Z tego wybrano te CV które miały sens, a ich właścicielom wysłano link do testu online sprawdzającego kompetencje. Spośród tych, którzy go ukończyli 30 najlepszych zaproszono na rozmowę. Ostatecznie zaś zatrudniono dwóch, w tym mnie.

Wywiad rozpoczął się od pytań odnośnie mojego projektu – dlaczego to, a dlaczego tamto? Dalej, pytano się o rzeczy z podstaw Javy (wyjątki, Optional, wątki wirtualne), Springa (sposoby wstrzykiwania zależności), baz danych (różnice pomiędzy JPA i JDBC). Z tym wszystkim już miałem do czynienia więc tu mnie nie zagięli, za to zacząłem się gubić jeśli chodzi o takie rzeczy jak szyfrowanie HTTPS i połączenia SSH, których jeszcze nie przerabiałem. Ostatecznie miałem wrażenie, że poszło mi lepiej niż na poprzedniej rozmowie, ale wcale nie jakoś fantastycznie – stąd moje zaskoczenie, kiedy już 4 dni później zadzwonił do mnie mój przyszły team leader z ofertą angażu.

Onboarding

Umowa podpisana, medycyna pracy zaliczona, benefity wybrane. Co dalej?

Z początku myślałem, że będzie jak na typowym stażu:

„tu sobie młody poprzeglądaj, poklikaj, pobaw się i pod żadnym pozorem nie dotykaj kodu produkcyjnego”

Tym większe zdziwienie kiedy już drugiego dnia dostałem zadanie dodania warunku w jednej metodzie sprawdzającej informacje nt. klienta banku. Niby chodziło tylko o głupiego if-a, ale wpierw trzeba było przejrzeć ten projekt z góry na dół żeby zobaczyć co tam się właściwie dzieje, potem dodać warunek, sprawdzić manualnie czy działa, a na koniec dopisać kilka testów jednostkowych. Robota na cały dzień.

Jeśli zaś chodzi o przykłady innych tasków, które mi się trafiły w ciągu pierwszych miesięcy w firmie, to mogę tu wymienić takie rzeczy jak:

• podniesienie zależności do wyższej wersji w pliku „.pom”
• dodanie pluginu sprawdzającego styl kodu (PMD) a następnie poprawa naruszeń reguł
• standaryzacja ustawień logowania w kilku projektach
• dodanie API do istniejących serwisów
• dodanie testów jednostkowych/integracyjnych tam gdzie ich brakowało
• stworzenie projektu, który wysyła na kafkę otrzymany obiekt JSON
• aktualizacja dokumentacji o niedawno dodane funkcje
• napisanie pliku z pipeline’m do nowego projektu

Dzień z życia programisty

Przytoczona lista jest trochę sucha i brakuje jej szczegółów, dlatego pozwólcie mi dokładniej opisać czym się tak właściwie zajmuję na mojej dniówce, jako przykładu używając aktualnego zadania.

TASK
Dodać obsługę testcontainers do projektu,
odizolować testy integracyjne bazy danych.

W prostych testach integracyjnych po prostu mockujemy sobie odpowiedzi z bazy czy powiązanych serwisów. Jest to wygodne, ale nie spełnia w 100% swojego zadania czyli upewnienia się, że komunikacja pomiędzy częściami systemu przebiega wzorowo. U nas po prostu zwracamy sobie na szybko żądany obiekt z bazy, tymczasem w produkcji może się okazać, że kolumna ma inną nazwę, pakiet innego użytkownika, nie posiadamy grantów, a tak w ogóle to nie możemy czegoś zrobić ze względu na więzy unikatowe.

Testcontainer pomaga obejść ten problem: po prostu stawiamy sobie na szybko dockerowy kontener z bazą i to z nim będziemy się komunikować. Wymaga to jednak znacznie więcej zachodu, bo już podczas uruchamiania takiej testowej bazy musimy załadować ją skryptami skopiowanymi z prawdziwej, aby to nowe, wirtualne środowisko jak najlepiej udawało rzeczywistość.

Z tym, że nie jest to takie proste kopiuj-wklej, bo zależy nam tylko na elementach istotnych dla testu. Próbuję zatem uruchomić owy test i za każdym razem się wykrzacza. Analizuję moment w którym się wywalił, dodaję niezbędny kawałek skryptu, puszczam test jeszcze raz i jeśli o niczym nie zapomniałem to.. znowu się wysypie, ale ciut dalej, na innym problemie. I tak do końca, aż przejdzie przez cały kod programu i zwróci upragnioną dwusetę.

Akurat w tym zadaniu więcej piszę w SQL-u niż w Javie, dlatego zachęcam abyście nie pomijali tego języka w waszym toku nauczania, naiwnie myśląc, że po co wam to skoro chcecie być programistami, a nie bazodanowcami.

Czy było warto?

Blisko 2 lata zakuwania i poświęcania na to większości wolnego czasu: popołudnia na pisanie kodu, na spacerach branżowe podcasty, przed spaniem książka z teorią, po obudzeniu pisanie tutaj czym jest REST i CQRS. I po co to wszystko? Po pensję juniora tylko niewiele przekraczającą stawkę minimalną?

Jak to się wogóle ma do moich poprzednich zawodów gdzie zarabiałem kilkakrotnie więcej poświęcając na to znacznie mniej wysiłku? Na walijskim kempingu wystarczało trochę pokosić trawę (słuchając przy tym ulubionych kawałków), sprawdzić bilety i umyć kible, funty same wpadały do kieszeni. A w czasie wolnym bujałem się na kajaku czytając sobie „Grę Endera” zamiast „Effective Java” czy innego przewodnika po refaktoryzacji.

Cóż, myśląc o przebranżowieniu do IT musicie zdać sobie sprawę z jednej ważnej rzeczy:

Nie zdecydowałem się na tę karierę dla pieniędzy i tobie też odradzam takie podejście. Są szybsze i łatwiejsze ścieżki do wygodnego życia. Bardziej spodobała mi się wolność jaką ta branża oferuje: praca z dowolnego miejsca na świecie i elastyczne godziny to benefity warte dla mnie znacznie więcej niż kolejne zera na koncie.

Ale jeszcze ważniejsze od powyższych jest to uczucie, którego zabrakło mi w poprzednich zawodach:

Że z każdym rokiem będzie coraz lepiej.

Nie miałem tego ani we wspomnianej wcześniej Walii, ani później, zarabiając na chleb jako anglista w Chinach. W obu przypadkach, po obeznaniu się z codziennymi zadaniami, mogłem przejść na automat, zrobić swoje i iść do domu. A jutro to samo. I pojutrze też. Aż do tzw. „usranej śmierci”, no chyba, że wcześniej zamkną kemping, albo zmieni się polityczny klimat i chiński rząd usunie angielski z egzaminu maturalnego. Nie rozwijałem się, byłem uwiązany do swojego „tu i teraz”.

W obecnym zawodzie czuję, że płynę z prądem globalnych zmian i cokolwiek przyniesie przyszłość – będę na to przygotowany. Z roku na rok moja wiedza i umiejętności będą się powiększać, a z nimi konkurencyjność na dynamicznie rozwijającym się rynku pracy. Mam możliwość pracować z niemal każdego miejsca na świecie, a znając angielski i język programowania mogę śmiało starować do dowolnej branży jaka mi się zamarzy, od obecnej: finansowej, przez medyczną, rozrywkową, lotniczą, a może nawet kosmiczną. Sky is the limit?

Czy nie jest już za późno?

W chwili kiedy piszę te słowa mamy początek roku 2025. Sztuczna inteligencja jest już całkiem zaawansowana, a jej możliwości rosną wykładniczo z każdą nową iteracją. Sam codziennie korzystam z rad modeli językowych w swojej pracy i widzę ich potencjał. Świat zmienia się na naszych oczach, kończy się pewna epoka.

Kiedy trzy lata temu myślałem o karierze programisty, już wtedy zastanawiałem się czy przypadkiem nie jest już, jak to mówią: „po ptakach”. Pociąg pandemiczny właśnie odjeżdżał, firmy zamykały projekty i redukowały etaty, kto do tej pory się nie nachapał ten trąba. Dzisiaj jest podobnie, a na domiar złego wszędzie straszą, że AI odbierze ludziom pracę, a zacznie od programistów, którzy ją stworzyli.

Gówno prawda.

Samochody odebrały pracę woźnicom. Email wyparł papierowe listy. Rewolucja przemysłowa miała wywalić rzemieślników na bruk. Jak to wszystko się dalej potoczyło nie ma sensu tłumaczyć, nazwy takie jak: Uber, Ford, Amazon czy Inpost mówią same za siebie. Praktycznie każdy zakład przemysłowy wymaga wykfalifikowanej i dobrze opłacanej kadry inżynierów, którzy nie tyle sami szlifują i spawają, co nadzorują i kalibrują maszyny robiące to za nich. Nie inaczej będzie z modelami językowymi.

Programista w połowie ubiegłego wieku pisał kod wybijając dziurki na kartach, następnie wkładał je do komputera wielkości lokomotywy. I zapewne drwił z pokolenia co przyszło po nim, które zamiast dziurkacza używało Assemblera. Ci z kolei nierozumieli podniety swoich dzieci piszących obiektowo w C++. Potem były języki wyższego poziomu, frameworki, aż po dzisiejsze LLM-y.

Programowanie stawało się z roku na rok łatwiejsze, ale co ciekawe: programistów wcale nie ubywało! Wręcz przeciwnie!

Teoretycznie, Janusz biznesu mógłby pomyśleć:

„Hmm, skoro po wprowadzeniu nowej technologii
mój inżynier robi dziennie dwa razy tyle co wcześniej,
to mogę wywalić połowę zespołu!”

I pewnie niektórzy nawet tak zrobią, redukcja za redukcją, aż nie zostanie nawet ten wierny Areczek i pan prezes sam będzie prosił DeepSeeka czy innego Clauda, żeby napisał mu aplikację, która zarobi dla niego kokosy. Stawiam orzechy przeciwko kokosom, że jeszcze przez dłuuuugi czas nie napisze. A kiedy w końcu się to uda, to może się okazać, że nawet ten pan prezes nie będzie już do niczego potrzebny, a ludzkość będzie miała znacznie poważniejsze problemy.

Ponadto, firma która by tak postąpiła stałaby w miejscu, tymczasem konkurencja zamiast zwolnień robiłaby dwa razy więcej w tym samym czasie. A gdyby podwoiła zespół to nawet cztery razy więcej! A gdyby potroiła… Myślę, że już rozumiecie jak to działa.

Chcemy tego czy nie, era analogu dobiega końca: wszystko musi być na prąd, smart i podłączone do Internetu. Zwykła żarówka już nie ma racji bytu, zwyczajnie nie sprzeda się, jeśli jej ledowy odpowiednik jest tańszy w eksploatacji, a do tego zmienia kolory i synchronizuje się z koleżankami w tej samej sieci. Ale żeby tak to działało, ktoś to wcześniej musi zaprogramować.

Może właśnie ty?