Poczucie braku rozwoju

Witam,
Na wstępie wspomnę, że miałem spory problem z wymyśleniem tytułu dla tego wątku. Borykam się z wieloma problemami związanymi z moją obecną pracą. Myślę jednak, że wszystkie w jakiś bardziej lub mniej bezpośredni sposób skutkują jednym - mam wrażenie, że zatrzymałem się w rozwoju.

Mam również świadomość, że problem nie wydaje się być szczególnie unikalny, lecz chciałbym opisać go dość szczegółowo, aby móc poznać wasze pełne zdanie. Nie mam dużego doświadczenia w branży. Być może wiele rzeczy, które wydają mi się nienormalne są w pewnym stopniu specyfiką tej pracy.

Od 1.5 roku pracuję na stanowisku Junior Java Developer. Jest to moja pierwsza praca programisty, która pozwoliła mi w dość młodym wieku usamodzielnić się oraz dość znacznie podnieść moje umiejętności w programowaniu. Pierwsze pół-3/4 roku pracy oceniam mega-pozytywnie. Nie zajmowałem się rzeczami szczególnie pasjonującymi, jak np. dłubanie w jakichś prehistorycznych jQuery czy różne drobne poprawki w innych projektach u schyłku życia będących jednym wielkim spaghetti bez testów i dokumentacji, pisanych na przestrzeni dekady przez programistów wszystkich możliwych narodowości. Mimo to, czułem się bardzo usatysfakcjonowany, że w końcu mogę poświęcać 8+ godzin dziennie na naukę pod okiem osób z doświadczeniem, które zawsze służyły mi radą. Sytuacja zaczęła się zmieniać wkrótce po wysłaniu nas na home office w marcu zeszłego roku. Zacząłem zauważać, że spływa do mnie coraz mniej zadań lub były one bardzo mało specyficzne. Wyłania się tu moim zdaniem pierwszy problem, czyli słabe zarządzanie zespołem. Tyczy się to zarówno roli, jaką pełni Scrum Master w organizacji pracy zespołu, Product Ownera, który niejednokrotnie pokazywał, że nie umie odpowiednio wyważyć potrzeb ludzi biznesu i zespołu, wynikających z aktualnego obłożenia tuzinem innych tematów oraz managera, który ten tuzin innych tematów fundował. Na przestrzeni ostatniego roku pracowałem nad kilkoma projektami, które powstawały od zera (w przeciwieństwie do "utrzymaniowych", gdzie pisaliśmy nowe feature'y i bugfixy) i żaden z nich po dziś dzień nie otrzymał pierwszej wersji.

W okresie urlopowym dochodziło do takich sytuacji, gdzie musiałem niemalże siłą wymuszać na planningach, aby zostało mi przydzielone jakieś zadanie. Czasami odnosiłem wrażenie, że jestem karany za chęć pracowania nad jakimś zagadnieniem. Przykładowo, pytam "Czy mógłbym dostać jakieś zadanie w Javie? Nie pisałem nic w tym języku od prawie 2 miesięcy. Po co mam 'Java Developer' w nazwie stanowiska?" i otrzymuję odpowiedź "A, chcesz Javy? To masz [10-letnie legacy spaghetti, którego nikt nie chce nawet kijem tykać], trzeba zrobić to i to". Gładko przechodzimy więc do kolejnego problemu, czyli ścieżka rozwoju niezgodna z pierwotnymi oczekiwaniami.

Rozumiem, że priorytety nie są stałe i potrzeby w świecie biznesu szybko się zmieniają. Jako osoba wiążąca swoją przyszłość z branżą IT powinienem być tego faktu szczególnie świadom. Jednakże nic nie pozwoliło mi oczekiwać, że przez 1.5 roku pracy na stanowisku Junior Java Developer będę miał okazję współtworzyć 2 (słownie: DWOMA) projekty Java/Spring. Co zamiast tego? Sporo Pythona, różnych libów i frameworków JavaScript. Od niedawna trochę poważniejsze podejście do tematów z serverless i ogólnie cloud. Myślę, że pod względem atrakcyjności stacku tragedii nie ma, ale dojście do tego wniosku zajęło mi bardzo dużo czasu, podczas którego ze smutkiem spoglądałem na wszystkie materiały o Javie, na których przerobienie poświęcałem sporo prywatnego czasu, a która już raczej mi się w tej pracy w ogóle nie przyda.

Kolejny problem - brak mentoringu. Moje oczekiwanie pod tym względem było tak naprawdę jedno - opinia na temat kodu, który piszę. Tymczasem, code review w tym zespole praktycznie nie istnieje. Jeżeli już zdarzy się, że członkowie są proszeni o przejrzenie jakichś zmian, to raczej odbywa się to na zasadzie "sprawdź, czy nie zrobiłem jakiegoś błędu" niż "sprawdź, czy nie zrobiłem jakiegoś błędu i zasugeruj, jak można byłoby to zrobić lepiej, jeśli masz jakiś pomysł". Osobiście, zawsze preferowałem tę drugą opcję i taki review otrzymywałem też od jednej programistki, która zdawała się podzielać moje zdanie. Zauważyłem natomiast, że inny programiści w zespole podchodzą do tego bardzo defetystycznie. Przykładowa sytuacja - moja sugestia, że daną instrukcję można napisać w bardziej czytelny i zwięzły sposób spotkała się z odpowiedzią, że "tak, ale to legacy szajs, więc nie musimy aż tak się nad nim starać a w ogóle to blokujesz mi PR daj w końcu tego approve'a skoro działa i nie męcz".

Taka, można powiedzieć bylejakość widoczna jest też w wielu innych aspektach pracy. Blisko współpracuję z seniorem, który z ogromnym oburzeniem reaguje na moje uwagi o to, by:

• stosować gałęzie i pull requesty, a nie pisać (głównie nowe) projekty "jak leci", a co za tym idzie robić to nieszczęsne code review
• formatować kod używając linterów, lub chociażby nie robiąc 10 pustych linii na końcu pliku albo niekonsekwentnie używając spacji wokół operatorów
• pisać testy jednostkowe(!!!)
• pisać rozbudowane, dobrze zanalizowane user stories w taki sposób, aby zająć mogła się nimi dowolna osoba bez konieczności łapania innych osób na czacie i dopytywania ich o szczegóły

Z tym pisaniem US związana jest jeszcze sprawa absolutnego braku etapu analizy. Mamy ogromny zespół developerów, devopsów, adminów. Pomimo pandemii, firmie wiedzie się dobrze i chętne rzuca dodatkowe pieniądze na zatrudnianie nowych osób. Czasem wydaje mi się, że ktoś sądzi, że wyłącznie sam fakt, że w zespole znajdzie się nowa osoba spowoduje, że będzie on pracował sprawniej. Tymczasem, implementowanie nowych rozwiązań przypomina tu drogę przez mękę. Nie ma nikogo, kto tworzyłby jakąś analizę wymagań i na jej podstawie projektował wysokopoziomowe rozwiązania. Zamiast tego biznes rzuca jakiś pomysł na feature, a zespół trochę "na czuja" próbuje go zaimplementować. Praktycznie nie jest możliwe dokonywanie jakichkolwiek estymacji na tym poziomie abstrakcji. Dodatkowo, mając jedynie tak ogólny zarys tego, co chce się osiągnąć często okazuje się, że jedyna osoba zdolna to wykonać w jakimś przyzwoitym czasie to jeden z programistów o stażu pracy w firmie ponad 5 lat, który ma wystarczająco dużą wiedzę domenową, by nie potrzebować przelewać specyfikacji na papier. W końcu, kto poza nim samym mógłby tego potrzebować?

W efekcie taka praca wygląda wysoce niesatysfakcjonująco z mojej perspektywy. Kod rozwijany jest bez jakiegokolwiek planu, implementowane są całe duże funkcjonalności zamiast pojedynczych elementów, które wspólnie dadzą pożądany efekt. Dostaję codziennie po kilka próśb o review (w końcu sam chciałem mieć code review, prawda?) gdzie jedno PR liczy sobie kilka tysięcy linii, nie ma żadnego opisu, który informowałby, jak dana rzecz została zaimplementowana i jakie są konsekwencje. Jedynie odnośnik do ticketu w Jira, a w samym tickecie jedno zdanie - trzeba zrobić to i to. Od pewnego czasu pracuję w małym zespole bez backlogu. Po prostu ktoś uznał, że wiedza dotycząca systemu i domeny jest u nas na tyle duża, że możemy "jechać jak leci". Problem w tym, że takie podejście realizują jedynie osoby, które tę wiedzę posiadają. Nie delegują zadań do innych członków zespołu ani nie informują o kluczowych zmianach w projekcie (wspomniałem o słabych opisach zmian i nieustalonych procesach włączania ich do repo?).

Całą sytuację opisuję tutaj w celu zasięgnięcia rady, co należy zrobić dalej. Czy są tu mankamenty na tyle poważne, by szybko szykować się do przejścia gdzieś indziej? To, co wydaje się dla mnie oczywiste to fakt, że piszę za mało kodu. A nawet jak już coś zdarzy mi się napisać, to nie ma nikogo, kto chciałby poświęcić temu chwilę uwagi. Domyślam się, że problemy organizacyjne trawią większość zespołów na całym świecie. Nigdy jeszcze nie pracowałem w miejscu (czy to związanym czy niezwiązanym z IT), w którym nie panowałby, mówiąc oględnie, "burdel". Wydaje mi się jednak, że jako programiści jesteśmy zmuszeni poświęcać tutaj zbyt wiele czasu na analizy i wymyślanie, jak coś zrobić, niż na rzeczywiste tego robienie. Nie wiem, na ile jest to poważny problem tej konkretnej organizacji i czy w innych firmach nie wygląda to podobnie. Marzy mi się, żeby móc rano włączyć służbowy komputer, spojrzeć na swoją listę tasków i móc powiedzieć "Wiem, co dzisiaj będę robić".

Odpowiadając na pytanie "skoro tak mi się nie podoba, to czemu jeszcze stamtąd nie odszedłem?" - dobrze płacą :) Jak na kogoś, kto zaczynał bez doświadczenia jako programista, nawet bardzo dobrze. Niestety, jest też nieco ciemniejsza strona. Odnoszę wrażenie, że siedząc 1.5 roku w tej firmie nie nabrałem wystarczająco dużo doświadczenia, aby móc startować na jakieś midowe stanowisko gdzie indziej. Nie czuję się jeszcze na tyle komfortowo z technologiami, z którymi pracowałem, by mieć wrażenie, że będę w stanie komuś "sprzedać" swoje umiejętności. Prawdę mówiąc, niejednokrotnie sen z powiek spędzały mi listy pytań z rozmów rekrutacyjnych dotyczące znanych mi technologii. Czytając je czuję się naprawdę źle, bo pomimo, iż ze wszystkimi tymi zagadnieniami zetknąłem się przynajmniej raz, to nie zostały one u mnie wystarczająco utrwalone.

Podsumowując, chciałbym rozszerzyć swoją perspektywę i dowiedzieć się, na ile powyższe lamenty są tylko moim narzekaniem i pobożnym życzeniem co do tego, jak praca programisty powinna wyglądać a na ile smutną rzeczywistością, z jaką przyjdzie mi mierzyć się w tym zawodzie. Z góry dziękuję za odpowiedzi i przepraszam za małą chaotyczność. Pisałem ten post 2 godziny nie mając żadnego konspektu czy listy punktów, które chciałbym omówić (a jakże ;)). Jeżeli coś wydaje się niejasne, chętnie doprecyzuję. Postaram się również dopisać, jeżeli coś jeszcze mi się przypomni.

Podejrzanie dobrze napisane jak na juniora, czyżby to ten mityczny przekwalifikowany humanista się pojawił?

Zmień pracę.
Siedząc dłużej w tej firmie nie nabierzesz doświadczenia, które chcesz nabrać. Za pół roku/rok, bedziesz niemal w tym samym miejscu.

voidfall napisał(a):

Odpowiadając na pytanie "skoro tak mi się nie podoba, to czemu jeszcze stamtąd nie odszedłem?" - dobrze płacą :) Jak na kogoś, kto zaczynał bez doświadczenia jako programista, nawet bardzo dobrze.

Czasami lepiej obniżyć sobie stawkę na pół roku, żeby potem ją podnieść niż cały czas tkwić w dobrej, ale "ostatecznej".

Odnoszę wrażenie, że siedząc 1.5 roku w tej firmie nie nabrałem wystarczająco dużo doświadczenia, aby móc startować na jakieś midowe stanowisko gdzie indziej.

Całkiem słusznie, po 1,5 roku nadal jest się juniorem.

W 2 godziny spłodziłeś tekst jakiego większość programistów w tygodnie nie napisze.
Nie marudź, że programowanie ci nie idzie, że nie dają ci żadnych nowych albo odpowiedzialnych tasków, bo do innych rzeczy masz wrodzony talent.

Rozwijaj się zgodnie z wrodzonymi predyspozycjami.

PS
Stanowisko
Według kryteriów/wymagań np. z ogłoszeń na 4Programmers, na bycie seniorem musisz mieć 2 lata doświadczenia. Standardowo 3.
Decyduje o tym kasa jaką dostaje programista i za jaką kasę praca programisty zostanie sprzedana klientowi.

Znam ludzi co 8~10 lat siedzą w jednej firmie i fixują rzeczy z commitami typu:
"Fixed bug for the improved list, HOTFIX v3. Poprawione razem z bugiem XYZ, ale nie aplikujcie hotfix v4 do taska ABC, bo wybuchnie" Może przesadzone troszkę, ale nie odbiega od rzeczywistości. Bo tak to jest gdy w kodzie mającym 1000 if'ów, gdzieś pojawi się jakiś problem, a wodospad nie wybacza wiele i fixując jeden bug robi się kolejny, który wyjdze np za miesiac.

Sam tak pracowałem przez długi czas i uciekłem stamtąd w końcu. Mimo, ze nie ma mnie w tej firmie od 6 lat, to proces tworzenia wiele sie nie zmienił. Ludzie chodzą tak samo zblazowani, tak samo wkurzeni na te same procesy. Ale nic nie robią, bo hajs się zgadza, a to że szef pomarudzi czemu coś wybuchło 5 razy w ciągu 6 miesięcy to się idzie przeżyć - buga się jakoś "zateguje ten tegesem".

Tak jak mamy powiedzenie

"Czemuś biedny - boś głupi. Czemuś głupi - boś biedny",

to w wielu firmach spotyka się poniższe, praktycznie tożsame warianty:

Nie piszemy testów, bo nie ma na to czasu. Nie ma czasu, bo trzeba bugi fixować

Nie piszemy lepszego kodu, bo przez lepszy kod nie zarobimy hajsu. Nie zarabiamy hajsu, bo musimy fixować bugi

Niestety ale jest to mentalność januszowo-polska - bo w wiekszosci przypadkow w tym kraju, nie oplaca sie robic dobrze, bo nie ma kasy z poprawek. Pomyśl tak: po co masz pisać dobry kod przez tydzień, skoro możesz napisać w jeden dzień i za tydzień spędzić 2~3 dni na poprawianiu tego (gonwo-task stabilny, roboty masz więcej, kasy więcej...) W zależności od umów i gadki - firma może skosić hajs dwukrotnie. A jak potem się okaże, że klient czegoś nie uwzględnił w wymaganiach (co można było przewiedzieć na analizie zadania) to i trzeci i czwarty raz się doliczy $$ do fakturki.

@BraVolt: Dziękuję za miłe słowa :) W pracy dane mi było usłyszeć, że nieźle jest u mnie z wieloma miękkimi umiejętnościami oraz, że jako zwykły developer, zajmujący się wyłącznie technicznymi sprawami najprawdopodobniej "będę się marnował". Autentyczny cytat, tak samo jak to, że widzą mnie jako jakiegoś kierownika za parę lat. Prawdę mówiąc, to kierownictwo już podejmuje jakieś drobne kroki celem wsadzenia mnie na jakieś kierowniczo-teamleaderskie stanowisko. Niestety, nie traktuję tych zapewnień jako jakiegoś komplementu. Znacznie bardziej interesuje mnie własnie programowanie, nieco odstrasza mnie cała ta otoczka związana prowadzeniem rozmów z biznesem. Razi mnie to również z innego względu. Nie zdążyłem tak naprawdę jeszcze zostać tym developerem. Nie chciałbym na tak wczesnym etapie porzucać tej drogi. Masz rację mówiąc, że należy rozwijać się zgodnie z wrodzonymi predyspozycjami, ale ja chciałbym do tego dodać jeszcze, że miło jest rozwijać się w takich kierunkach, które autentycznie się lubi :)
Niemniej jednak podążam na razie tą drogą, aby zobaczyć, dokąd mnie ona zaprowadzi.

voidfall napisał(a):

Masz rację mówiąc, że należy rozwijać się zgodnie z wrodzonymi predyspozycjami

Nie porzucaj developerki bo ludzi z soft skillem lepszym od ciebie jest wielu. Ale ludzi z dobrym softskill oraz wiedzą i praktyką domenową i jeszcze z programowania nie ma dużo, jeszcze trudniej ich skusić do zmiany pracy.

Za 5 lat będziesz tym "seniorem" do którego nie będą się złośliwie czepiać (3 lata senior to nie senior). Jadnak od innych seniorów 6, 7 lat w programowaniu ciebie być może będzie wyróżniać kasa, tak około 2 x zwykły senior programista zasiedziały przy klawiaturze.

Ja mam w sumie pokrewny problem do OP z tym że trochę w inny deseń.
Też 1wsza praca. Praca zdalnie dla małej firmy przy Wordpressie, jestem tu jedynym developerem i po 3 latach pracy w 1 miejscu wiele rzeczy jest już powtarzalnych/rozkminionych + brakuje pracy z 2gim łepkiem który ogarnia podobne tematy do mnie, poza tym chciałbym robić w jakieś rzeczy w JavaScript, pisać jakieś aplikacje - fajnie byłoby to też robić jako praca zarobkowa, a nie tylko po godzinach bo to ma sens bo w trakcie pracy zarobkowej poprawiać będziesz skilla w czymś co cie interesuje, a nie tylko po godzinach.
I w sumie teraz też co robię na WP ma potencjał tj. PHP, bo można tutaj robić jakieś projekty, ale faktycznie, ja na co dzień to nie programuję w pracy prawie nic :P (robię to właśnie po pracy) Ewentualnie klepie jakieś szablony z projektów graficznych do HTML / CSS / JS
Ale kasa jest, zdarzają się zlecenia gdzie trzeba więcej rozkminiać więc też dlaczego narzekać...nie samą pracą żyje człowiek

Sądząc po ścianie tekstu to już nie rozwój a nowotwór. Nie wiem, może poświęć się dokumentowaniu istniejącego kodu?

Niewiele to zmieni ale przynajmniej poznasz 77(7) sposobów jak nie pisać kodu i zostaniesz mentorem innych albo wydasz książkę. To też jakiś rozwój.

mam wrażenie, że zatrzymałem się w rozwoju

Ty przede wszystkim jesteś odpowiedzialny za swój rozwój i nikt więcej. Jeśli rozwój ma wynikać wyłącznie z samej pracy to zwolnij się, załóż własną firmę i buduj własne produkty.

Jak Ci wyjdzie zrealizujesz swój cel, a jak nie to zaczniesz przynajmniej inaczej patrzeć na warunki jakie miałeś w pracy.

Pomimo pandemii, firmie wiedzie się dobrze i chętne rzuca dodatkowe pieniądze na zatrudnianie nowych osób.

To jakieś korpo?
W sensie - pracowników mają aż za dużo (przynajmniej o jednego za dużo - ty już tam nie powinieneś pracować, skoro nie masz już prawie nic do roboty), a zatrudniają nowych (zamiast zoptymalizować produktywność tych, co już są)? Brzmi jak korpo.

Czy są tu mankamenty na tyle poważne, by szybko szykować się do przejścia gdzieś indziej?

Czy to jest jedna z tych korporacji, która i za 20 lat będzie istnieć i zapewni tobie miłą posadkę? Bo jeśli nie, to bym się rozglądał za kolejną robotą, bo stoisz w stagnacji i obracasz się w patologiach i im dłużej tam pracujesz, tym mniejsze szanse są, że później odnajdziesz się w bardziej normalnych firmach.

pisać rozbudowane, dobrze zanalizowane user stories w taki sposób, aby zająć mogła się nimi dowolna osoba bez konieczności łapania innych osób na czacie i dopytywania ich o szczegóły

+1

to zawsze największy ból jest, że opisy tasków są pisane na kolanie, niczym notatka podawana przez uczniów cichaczem w szkole.

W okresie urlopowym dochodziło do takich sytuacji, gdzie musiałem niemalże siłą wymuszać na planningach, aby zostało mi przydzielone jakieś zadanie. Czasami odnosiłem wrażenie, że jestem karany za chęć pracowania nad jakimś zagadnieniem.

Jak nie masz nic do roboty, to zawsze możesz w tym czasie np. poczytać coś o programowaniu albo włączyć jakiś kurs video na Youtube i też będziesz miał rozwój. I może to być nawet związane z twoją pracą. Czyli jeśli używasz frameworka X, to możesz sobie w czasie pracy poczytać o zaawansowanych ficzerach tego frameworka, żeby wiedzieć więcej. Tym sposobem czegoś się nauczysz nawet w trakcie pracy, w której nic nie ma do roboty.

Zmień pracę na jakąś lepszą. W szczególności: na rozmowie dopytaj o te rzeczy których ci teraz brakuje :) Tylko broń Boże nie pytaj czy piszecie testy? bo wiadomo że powiedzą że tak. Pytaj konkretnie, np. w czym piszecie testy, gdzie i jakie metryki aplikacji trzymacie, jakiego CI używacie, ile osób musi zrobić review przed mergem.

Odpowiadając na pytanie "skoro tak mi się nie podoba, to czemu jeszcze stamtąd nie odszedłem?" - dobrze płacą

To się nazywa złota klatka ;) I to jest częsty problem programistów że na rozmowie pytają tylko o szekle, a potem płaczą że januszex.

PS:

Przykładowa sytuacja - moja sugestia, że daną instrukcję można napisać w bardziej czytelny i zwięzły sposób spotkała się z odpowiedzią, że "tak, ale to legacy szajs, więc nie musimy aż tak się nad nim starać a w ogóle to blokujesz mi PR daj w końcu tego approve'a skoro działa i nie męcz".

Na to bym akurat uważał :D Wiem ze niby zasada skauta, ale z drugiej strony instynkt samozachowawczy. Jak wiesz ze dotykasz kodu w polu minowym, szczególnie słabo otestowanym, to raczej chcesz zmienić jak najmniej zeby zmniejszyć szansę że coś się zacznie spytać. Takie ambitne refaktory mogą potem kogoś wciągnąć w to bagno na długi czas.

@LukeJL:

To jakieś korpo?
Tak. Bardzo trafne, choć mam wrażenie, że nietrudno było się tego domyślić.
Czy to jest jedna z tych korporacji, która i za 20 lat będzie istnieć i zapewni tobie miłą posadkę?
Istnieje już trzycyfrową liczbę lat. Może nie zawsze istniała i nie zawsze istnieć będzie w tej samej formie, ale generalnie to nie wyobrażam sobie, by upadła.

@Shalom: Dziękuję za rady. Mam plan sporządzić listę pytań, które chciałbym zadać potencjalnemu pracodawcy. W tym konkretnym przypadku nie bardzo byłem w pozycji, by wybrzydzać. O pieniądze też jakoś szczególnie nie musiałem się pytać, rzuciłem kwotą i się zgodzili :)
Nie chcę mocno drążyć tego tematu, ale nie był to żaden kod w polu minowym, ani nawet zmiana. Po prostu nowa klasa implementująca nową funkcjonalność. Ta sytuacja pozwoliła mi dowiedzieć się, że najwyraźniej nie każdemu zależy na takim samym rodzaju inputu, jak mi. Od tej pory po prostu klikam zielony przycisk, jeżeli nie wpadnie mi w oko żaden rażący błąd albo niechlujstwo.

Po przeczytaniu wszystkich odpowiedzi i przemyśleniu sprawy decyduję się odświeżyć CV i poszperać trochę w ofertach. Nawet, jeżeli ostatecznie do zmiany nie dojdzie, czy to z powodu porażki na etapie rekrutacji, czy jakiegokolwiek innego, to przynajmniej będę mógł się czegoś o sobie i swojej aktualnej wartości rynkowej dowiedzieć :)

Istnieje już trzycyfrową liczbę lat. Może nie zawsze istniała i nie zawsze istnieć będzie w tej samej formie, ale generalnie to nie wyobrażam sobie, by upadła.

Ale ryzyko pozostaje. Wystarczy, że będą robić kiedyś cięcia etatów albo coś i zostaniesz na lodzie, a inne firmy popatrzą i powiedzą "niby masz dużo lat doświadczenia, ale nie nauczyłeś się wiele w tym korpo, to cię nie zatrudnimy".

Albo po prostu sam nie dasz rady wykonywać pracy w takich toksycznych warunkach, skoro już teraz założyłeś ten wątek, to co dopiero po iluś latach takiej patologii.

Więc lepiej szukać nowej roboty.

To co opisałeś jasno wskazuje na konfikt pieniądze vs rozwój. Mysle, ze wykrzyczałeś co chcesz, szczególnie, ze zaczynasz dopiero i być może przed tobą 50 lat kariery..

Ile książek o Javie czy programowaniu przeczytałeś w te 1.5 roku? Ile prelekcji/tutoriali obejrzałeś? Próbowałeś rozumieć kod głębiej?

Zmień prace, ale przed tym przygotuj się do jej zmiany. Jeżeli się rozwijałes w wolnym czasie to być może, nie ucierpisz finansowo, a zyskasz.

To nie jest tylko poczucie braku rozwoju, ale faktyczny brak rozwoju. Piszesz, że jesteś na początku kariery, zakładam, że również niezbyt zaawansowany wiekiem. To oznacza, że łatwo ci przyswajać nową wiedzę, ciężko zarabiać dużą kasę. Jeżeli patrzysz na swoją karierę jako całość a celem jest ograniczenie frustracji i zarobienie dużo w ciągu całego życia, to obecnie powinieneś skupić się na zdobywaniu doświadczenia i umiejętności a nie na maksymalizacji pensji bo (scenariusz pesymistyczny):

• po kilku miesiącach biedowania dostaniesz tą kasę którą masz teraz
• po następnym roku zaczniesz zarabiać więcej (o ile będzie ci za co płacić)
• za 15 lat (połowa twojej kariery) będziesz chapał szekle jak foczka śledzie i jednocześnie łatwiej ci będzie nadążać, bo chociaż nauka idzie z wiekiem wolniej, to zgromadzone wcześniej doświadczenie mocno w tym pomaga.

Alternatywą jest przyspawanie się do stołka w tej korpo, gdzie teraz pracujesz, wiele robić nie musisz, awanse, jakieś podwyżki też ci dadzą. Za 15 lat będziesz siedział na stołku, całował szefa w d. bo twoja wartość na rynku pracy będzie znikoma:

• hard skillsy - na obecnym poziomie
• doskonała znajomość co wolno, czego nie wolno, jaki formularz wypełnić i do kogo zadzwonić jak chcesz dorzucić bibliotekę do kodu
• doświadczenie deweloperskie i organizacyjne z kilku projektów w ramach jednej organizacji.

Osobiście na początek kariery polecam raczej małe firmy bo:

• Nie mają czasu na pierdoły.
• Jeżeli robią code review, to nie po to, żeby "mieć code review", tylko, żeby to coś wniosło. Podobnie z resztą.
• Masz styczność z całym wachlarzem technologii - frontend, backend, baza danych, devops, wtyczka od czajnika bo nie ma tam kasy na junior, regular i senior specjalist (+ cała hierarchia managerów) od każdej z tych rzeczy.