Zmiana pracy - ambitny projekt lecz potencjalne legacy

Cześć. Pracuję jako Frontend (backendu też trochę klepie w obecnej pracy) - 4 lata expa, od początku w jednej i tej samej firmie. Jest bardzo spoko, luźno, ludzie 10/10, lecz wydaje mi się że w obecnej firmie już bardziej się nie rozwinę.Dużo siedzę po godzinach, czytam artykuły, uczę się nowych technologii, robie jakieś projekciki do szuflady itd itp.

Przeszedłem rekrutację w jednej firmie polsko-norweskiej i dostałem ofertę pracy w projekcie największego e-commerce w Skandynawii - ponoć w dni jak Black Friday mają po 200k ludzi na platformie w jednym momencie). Ludzie wydają się bardzo spoko, firma raczej też. Obecnie mam 20 dni urlopu, tam jest 26. Obecnie 19k b2b, tam 22k b2b. Z minusów - raz w miesiącu wyjazd na wspólne pracowanie do Poznania (jestem z Wrocławia więc daleko nie jest). Drugi minus (nie wiem w sumie czy to minus - nie musi być to minusem) to to, że ten ecommerce jest trochę legacy (aktualnie ponoć usprawniany). Jest to duża aplikacja podzielona na mikroserwisy/miktofrontendy. Pracowałbym w checkoucie (koszyk, płatność itd.) w którym jeszcze chyba nawet nie ma Typescriptu (ponoć jest wprowadzany), React jest. Ludzie na technicznej tak jak wspomniałem wydawali się bardzo w porządku. Lider wspominał że odszedł z tej firmy 4 lata temu i 2 lata temu wrócił z powrotem - więc chyba pracuje się dobrze. Praca z Norwegami więc to chyba też zaleta? Szukam miejsca do rozwoju bez micromanagementu i toksycznej atmosfery. Wiem, że ryzyko jest zawsze, a wy co myslicie?

To nie jest legacy. To jest działający system, w który ktoś inwestuje i go rozwija. Trzeba mieć dużą wiedzę i skill, żeby go usprawniać i modernizować bez naruszania codziennego biznesu. Jest to ciekawa robota wbrew pozorom. Legacy to coś innego - to stary zapomniany system, który tylko utrzymuje się na chodzie używając minimum zasobów.

Nigdy nie umiałam zrozumieć fascynacji "greenfieldem". Co takiego szlachetnego i rozwijającego jest w tym, że się od zera napisze kolejną przeglądarkę do bazy danych? Dużo ciekawsze jest rozwijanie takiej przeglądarki, gdy ma ona miliony użytkowników. Tu są wyzwania.

Podwyżka marna, ale jeśli faktycznie cenisz rozwój bardziej niż stabilność, to bym brał.

Z minusów - raz w miesiącu wyjazd na wspólne pracowanie do Poznania

Koniecznie wpisz to do umowy, żeby się nie okazało, że z miesiąca nagle zrobi się tydzień. Wiemy jak jest, zwłaszcza na b2b.

tam jest 26

Klasycznie sprawdź, jak ten tzw. "urlop" jest określony w umowie.

Pracowałbym w checkoucie (koszyk, płatność itd.) w którym jeszcze chyba nawet nie ma Typescriptu (ponoć jest wprowadzany)

Hmm, "ponoć"? To dopytaj. Bo z twojej wypowiedzi wynika, że chciałbyś, żeby tak było. Żeby się nie okazało, że trafisz do spaghetti w JS :) choć jeśli mikrofronty, to przynajmniej jest jakaś nadzieja izolacji między aplikacjami.

Ja bym wziął urlop w pierwszej i spróbował tej drugiej. Bo okaże się, że Ci nie odpowiada a podwyżka nie duża jak na takie zmiany. Dodatkowo ten wyjazd do poznania to też dla Ciebie koszta czasu i pieniędzy

kusiok napisał(a):

Cześć. Pracuję jako Frontend (backendu też trochę klepie w obecnej pracy) - 4 lata expa, od początku w jednej i tej samej firmie. Jest bardzo spoko, luźno

Skoro jest luźno to co Cię blokuje rozwijać się w godzinach pracy ?

Z minusów - raz w miesiącu wyjazd na wspólne pracowanie do Poznania (jestem z Wrocławia więc daleko nie jest).

180km to prawie 2h w jedną i drugą stronę czyli łącznie 4 na sam dojazd

Pracowałbym w checkoucie (koszyk, płatność itd.) w którym jeszcze chyba nawet nie ma Typescriptu (ponoć jest wprowadzany), React jest.

Jeśli to jest projekt online to interakcja z użytkownikami szczególnie jeśli chodzi o dokonywanie płatności rodzi problemy typu wyjaśnianie problemów czemu np klientowi się coś nie zapłaciło albo czemu nie dostał dostępu itd itd co może być dosyć drenujące bo oprócz przeklepywania kodu tego typu problemy tym bardziej mogą się rodzić no więc zastanów się czemu akurat tam potrzebują ? - bo może nie ma chętnych, bo może to najbardziej problematyczna część aplikacji o której już wiedzą obecni pracownicy i niezbyt się garną do tego bo wiedzą że trzeba dużo debugować, interakcja z niecierpliwym biznesem i klientem ?

Szukam miejsca do rozwoju bez micromanagementu i toksycznej atmosfery. Wiem, że ryzyko jest zawsze, a wy co myslicie?

Obecnie masz

• elastyczność
• płatny urlop
• lekko mniejsze hajsy
• brak wymogów pojawiania się w biurze i tracenia 4h z życia na dojazdy raz w miesiącu

Chcesz zmienić na

ecommerce

• coś co w zasadzie nie jest rozwojowe tylko upraszcza proces klientom

w którym jeszcze chyba nawet nie ma Typescriptu (ponoć jest wprowadzany),

• być ojcem rozwiązań jak i wskazywany w przypadku jakichkolwiek problemów które nie muszą być związane z checkoutem ale ktoś to musi przeanalizować na linii klient => biznes do rozwiązania na już - więc się zastanów czy będzie CI sie chciało debugować pod presją - tam gdzie są hajsy tam zawsze jest presja

Lider wspominał że odszedł z tej firmy 4 lata temu i 2 lata temu wrócił z powrotem - więc chyba pracuje się dobrze.

• nie znasz sytuacji od kuchni i być może powrót to jest w stylu "tonący brzytwy się chwyta" - ale oczywiście nie musi

Wniosek?
Jeśli chodzi o podwyżkę to raczej kwota pomijalna vs stabilność którą już masz, apki ecommercowe to żadna możliwość rozwoju. Więc jeśli masz super sytuację i w razie w przy obecnym rynku jakby Ci się zbytnio nie spodobało możesz sobie poczekać to w zasadzie why not. Ten kto nie ryzykuje to ponoć nie pije szampana no ale trzeba mieć na uwadze obecny rynek :)

abuwiktor napisał(a):

To nie jest legacy. To jest działający system, w który ktoś inwestuje i go rozwija. Trzeba mieć dużą wiedzę i skill, żeby go usprawniać i modernizować bez naruszania codziennego biznesu. Jest to ciekawa robota wbrew pozorom. Legacy to coś innego - to stary zapomniany system, który tylko utrzymuje się na chodzie używając minimum zasobów.

Nigdy nie umiałam zrozumieć fascynacji "greenfieldem". Co takiego szlachetnego i rozwijającego jest w tym, że się od zera napisze kolejną przeglądarkę do bazy danych? Dużo ciekawsze jest rozwijanie takiej przeglądarki, gdy ma ona miliony użytkowników. Tu są wyzwania.

Greenfield i utrzymanie mają inne wyzwania, inne zalety i inne problemy. Warto mieć doświadczenie w obydwu.

Pytanie zasadnicze, co w tym utrzymaniu się będzie robić. Mogą być ciekawe problemy optymalizacyjne i biznesowe, a mogą być zadania typu "podnieś wersję biblioteki czy zmień walidację maksymalnej wartości z X na Y". Podsumowując: to zależy i nie ma reguły.

BTW, czy ktoś da modyfikowanie core'a systemu z milionami użytkowników kontraktorowi z Polski?

Jak nie chcesz legacy to sam sobie napisz projekt od zera. Tak to niestety wygląda.

Ostatnio mam "zabawną" sytuacje w projektach.
Jakiś czas temu miałem okazję pracować przy projekcie w którym był i backend i front. Jako że jestem javowcem i troche znam Angulara to robiełem obie części i tak nieformalnie przewodziłem kodowaniem (nieformalnie bo bronię się przed tym ręcami i nogami).
Na koniec ten kod był użyty w trzech dość dużych wdrożeniach i klienci są całkiem szczęśliwi. Tylko że ten kod sumarycznie powstawał przez prawie 4 lata, więc na dzień dzisiejszy to już w sumie legacy z Angularem 14, który chyba jest już nawet uznany za przestarzały.
Ale efekt na dzień dzisiejszy jest taki że strasznie zostałem zjechany za kod i jego jakość. No cóż, klient szczęśliwy, nowe ficzery są dodawane w szybko, incydentów nie ma itd. co dla mnie jest szczególnie niemiłe bo dyskusja rozbija się o to że zmienne są nazwane nie tak jak "powinny" i używam jakichś złych praktyk a to i tamto powinno być inaczej.

I teraz dla nowego klienta mamy kod pisany od zera, kompletnie nowe green field. Przez pół roku jest taka dyskusja o standardach, o tym aby robić na modłę współczesnych frameworków i uniknąć błędów z tego wyżej, że...po kilku prezentacjach wewnętrznych ostatnio, następuje cisza, i "ownerzy" zastanawiają się gdzie są ficzery???? coś na zasadzie - "ale co wy robiliście przez pół roku? "

Do sedna - w green fieldzie można kodować super nowe rzeczy, na nowe frameworki, wymyślać nowe światy i przez pewien czas nikt nie ponosi za to odpowiedzialności. Można mieć dobrą gadkę i wymienić 50% kodu i zacząć pisać na modłę nowego frameworka po miesiącu i nikt nie zwolni z pracy bo 90% ficzerów przestało działać.
W projekcie który jest już używany....najdrobniejsza zmiana powoduje ryzyko wywalenia się kodu, nikt nie pozwoli wprowadzić nowego frameworka tylko dlatego że jest cool (głównie komuś się wydaje że jest cool). Trzeba rozumieć CUDZY kod. Ja osobiście dużo bardziej wolę takie środowisko bo tu naprawdę się coś robi co ma działać i są z reguły ludzie którzy potrafią dowozić. No i walidacja tego co się robi następuje szybko (np tydzień po zamknięciu jiry jest wdrożenie).
W green fieldach często można mieć expertów z nazwy. No i czasami jest tak że projekty są zamykane zanim wejdą na produkcję (kiedyś tak często było w bankach inwestycyjnych, teraz może mniej) więc nie można się przekonać czy to faktycznie jest takie super

Więc...to zależy gdzie się trafi

sfan napisał(a):

180km to prawie 2h w jedną i drugą stronę czyli łącznie 4 na sam dojazd

Czyli w skali roku tyle, ile zyskuje dodatkowych dni urlopu.

Jeśli to jest projekt online to interakcja z użytkownikami szczególnie jeśli chodzi o dokonywanie płatności rodzi problemy typu wyjaśnianie problemów czemu np klientowi się coś nie zapłaciło albo czemu nie dostał dostępu itd itd co może być dosyć drenujące bo oprócz przeklepywania kodu tego typu problemy tym bardziej mogą się rodzić no więc zastanów się czemu akurat tam potrzebują ? - bo może nie ma chętnych, bo może to najbardziej problematyczna część aplikacji o której już wiedzą obecni pracownicy i niezbyt się garną do tego bo wiedzą że trzeba dużo debugować, interakcja z niecierpliwym biznesem i klientem ?

Przecież frontendowiec nie będzie analizował czemu płatność klientowi nie przeszła.

• lekko mniejsze hajsy

Nie powiedziałbym, że połowa raty za mieszkanie/rata za leasing samochodu/50 puszek harnasia codziennie to jest lekko mniejszy hajs.

Chcesz zmienić na

ecommerce

• coś co w zasadzie nie jest rozwojowe tylko upraszcza proces klientom

Co masz na myśli twierdząc, że ecommerce jest nierozwojowe?
Wg wszelkich statystyk handel internetowy zyskuje na popularności z roku na rok.

dev123 napisał(a):

Greenfield i utrzymanie mają inne wyzwania, inne zalety i inne problemy. Warto mieć doświadczenie w obydwu.

Tyle, że w greenfieldzie nie ma żadnych realnych wyzwań. Chociażby dlatego nie warto na to tracić czasu.

BTW, czy ktoś da modyfikowanie core'a systemu z milionami użytkowników kontraktorowi z Polski?

A czemu nie?
W normalnych organizacjach pracuje się w zespołach, a kod przechodzi review.

Oba rodzaje pracy mają swoje zalety i wady.
Mam na myśli tworzenie całkowicie nowego systemu i utrzymywanie starego.

Tworząc system od nowa podchodzisz do tematów których nie masz szans dotykać pracując przy istniejącym systemie.
Przykład? Konfiguracja security od początku, zaproponowanie rozwiązania architektonicznego, zaprojektowanie encji w bazie, konfiguracja i spinanie jobów i podobnych mechanizmów. Jak często robi się to w istniejącym systemie już od lat, który się utrzymuje / rozwija? Raczej rzadko. Zazwyczaj doklepuje się coś podobnego, do tego co już istnieje.

Z drugiej strony istniejące od lat systemy mają też swoje interesujące problemy, których nie mają szans mieć nowe projekty. Problemy z wydajnością, locki na bazie danych, analiza wycieków pamięci, thread i heap dumpów. Bardzo ciekawe i rozwijające tematy, zarówno od strony szczegółów technicznych jak i kombinowania żeby taki temat rozwiązać.

Ja osobiście wolę takie legacy, chociaż potem na rozmowy kwalifikacyjne trzeba się uczyć, bo niestety często pytają o znajomość frameworków ;]

potasek napisał(a):

Jak często robi się to w istniejącym systemie już od lat, który się utrzymuje / rozwija? Raczej rzadko.

Bezustannie.
Ciągle zmieniają się wymagania, co skutkuje tym, że zarówno trzeba przemyśleć architekturę, usprawnić security, zoptymalizować bazę, i zrobić tysiące innych rzeczy.
Praca przy istniejącym nietrywialnym systemie w sensownej architekturze, to w zasadzie tworzenie wielu małych greenfieldów. Tylko o tym, czy coś zrobiłeś dobrze, dowiadujesz się w ciągu maks paru tygodni, a nie lat.