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.