Zmiana technologii realnie

Jak to jest w praktyce ze zmianą technologii w dalszych etapach kariery, w obrębie tej samej niszy typu backend, fullstack?
Zawodowy przeskok z typowego OOP na czysto funkcyjne języki to pewnie trudna sprawa?
Nie mówiąc już o migracji z web deva na coś związanego z AI.

Z jednej strony opartej na przypadkowych internetowych przypowieściach wynika, że nie ma z tym problemów ponieważ to tylko kosmetyka składni. Programistyczna wiedza za którą się słono płaci pozostaje uniwersalna.
Patrz artykuł: Don't Call Yourself A Programmer

Jednak patrzac na ogłoszenia dla midow oraz seniorow często widzę wymaganie specyficznej liczby lat doświadczenia w danym języku.
I co wtedy? Powiedzmy kodze sobie zawodowo 3-5 lat w pythonie/rubym (software house), potem chce przeskoczyc na poważne bankowe korpo java/c# czy inne go -- lub odwrotnie -- i jak wtedy liczone jest moje doświadczenie?
Wszystko jest możliwe, jednak co z "opportunity cost"?
Zapewne spory krok w tył z obcykanego mida na zaawansowanego juniora?
W pojedynku z kimś kto spędził te same 3-5 lat w naszej nowej technologii docelowej raczej nie mamy szans pomimo podobnej wiedzy ogólnej?
Ponieważ oswojenie sie ze wszystkimi niunasami danego języka, innymi nazwami metod nowej biblioteki standardowej itp na płynnym poziomie zaawansowanym trochę zajmie.

Jakie macie z tym doświadczenia?

W praktyce bywa z tym różnie ale jest to jak najbardziej możliwe. Chyba najlepiej zmieniać technologię w obrębie jednej firmy. Masz ten komfort, że środowisko znane, zawsze możesz podpytać jak to jest w innym zespole i jeśli okaże się, że jednak ta zmiana nie do końca Ci odpowiada - prawdopodobnie będzie możliwość powrotu. Prawdopodobnie bo to zależy od samej firmy w której pracujesz.
Jeśli jednak z jakiegoś powodu to nie wchodzi w grę to w pierwszej kolejności musisz zainwestować swój czas na naukę danej technologii. W sieci jest mnóstwo materiałów i samouczków chyba na każdy temat. Więc to nie będzie problemem ale nie jest to koniec zmagań. W pewnym momencie będziesz myślał, że już wszystko umiesz. To oczywiście nie będzie prawdą i aby to sobie uświadomić trzeba wystartować z jakimś projektem w danej technologii, potem go udostępnić i prosić o przegląd/krytykę. Jeszcze lepszym rozwiązaniem jest dołączenie do jakiegoś projektu opensource. Początki mogą być skromne ale będziesz nabierał doświadczenia. W międzyczasie, jak już będziesz miał solidne podstawy, można co jakiś czas wybierać się na rozmowy rekrutacyjne. Poznasz wtedy wymagania, zobaczysz czego Ci brakuje, dowiesz się jak Twoje obecne doświadczenia są oceniane przez zespół rekrutujący.
W skrócie, w zmianę technologii musisz włożyć wiele wysiłku, wtedy masz bardzo duże szanse na powodzenie.

mysle ze jak najbardziej realne przy odpowiednim doswiadczeniu, ogolnej wiedzy i przygotowaniu do rozmowy mozna z powodzeniem zmienic na inna technologie bo nawet srednio rozgarniety rekruter dobrze wie ze jak ktos umie programowac w javie, rubym i haskellu i tworzy w nich dostatecznej jakosci soft to bez wiekszego problemu ogarnie takiego .neta czy scale i po kilku tygodniach w projekcie najprawdopodobniej wyprzedzi w delivery kolegow zamknietych w swojej technologicznej bance

No oczywiście jak zawsze wszystko wina nieogarnietego HR ;)
Nie mam wątpliwości, że jak się extra popracuje to jest to możliwe.
Chodziło mi bardziej o to że jednak nie jest to takie bezbolesne jak się początkowo wydaje i tu jest problem.

Jeśli lubisz nowe rzeczy i poznawanie tej konkretnej technologii będzie Ci sprawiać przyjemność to na pewno nie będzie to bolesne doświadczenie. Jednak jeśli jedyną motywacją jest np. kasa i sama technologia to drugorzędna sprawa, to już zależy od Twojego charakteru. Jedni szybko się zniechęcą, inni będą konsekwentnie przeć naprzód mimo iż to co robią nie sprawia im przyjemności.

guaro napisał(a):

Jak to jest w praktyce ze zmianą technologii w dalszych etapach kariery, w obrębie tej samej niszy typu backend, fullstack?
Zawodowy przeskok z typowego OOP na czysto funkcyjne języki to pewnie trudna sprawa?

Mam za sobą przejście z Javy na Scalę, co prawda nie jest czysto funkcyjna, ale nadal. Od momentu zaczęcia nauki do dostania pracy w Scali minęło jakieś ~6 miesięcy. W tym samym czasie pracowałem na 4/5, miałem ostatni semestr uczelni i pisałem magisterkę. Samo przejście raczej nie było trudne, po prostu nowe pojęcia, inne spojrzenie na pisany kod, inne możliwości i ograniczenia. Jeśli chodzi o kwestie stanowiska to u mnie zostało takie jakie było (mid), wynagrodzenie poszło znacznie do góry. Od momentu przejścia minął rok i zdecydowanie nie żałuję czasu poświęconego temu - masa nowej wiedzy którą można wykorzystywać wszędzie, czy to w OOP czy w FP

DisQ napisał(a):

guaro napisał(a):

Jak to jest w praktyce ze zmianą technologii w dalszych etapach kariery, w obrębie tej samej niszy typu backend, fullstack?
Zawodowy przeskok z typowego OOP na czysto funkcyjne języki to pewnie trudna sprawa?

Mam za sobą przejście z Javy na Scalę, co prawda nie jest czysto funkcyjna, ale nadal. Od momentu zaczęcia nauki do dostania pracy w Scali minęło jakieś ~6 miesięcy. W tym samym czasie pracowałem na 4/5, miałem ostatni semestr uczelni i pisałem magisterkę. Samo przejście raczej nie było trudne, po prostu nowe pojęcia, inne spojrzenie na pisany kod, inne możliwości i ograniczenia. Jeśli chodzi o kwestie stanowiska to u mnie zostało takie jakie było (mid), wynagrodzenie poszło znacznie do góry. Od momentu przejścia minął rok i zdecydowanie nie żałuję czasu poświęconego temu - masa nowej wiedzy którą można wykorzystywać wszędzie, czy to w OOP czy w FP

Tu chodzi o normalne przejście kogoś kto ma kilka lat prawdziwego doświadczenia a nie kogoś kogo ma pół roku doświadczenia w javie na pół etatu.

W mojej ocenie, osobie, która umie programować w jednej technologii nie będzie ciężko przejść na inną. Dobry programista to nie tylko składnia języka czy konstrukcja frameworka, a masa innych aspektów, które w dużej mierze są wspólne pomiędzy technologiami. Ponadto, jak ktoś zna jeden język to nie będzie mu ciężko nauczyć się kolejnego. Jedyny minus jest taki, że zmieniając technologie zawodowo, przynosisz mniejszą wartość dla pracodawcy i może się to wiązać ze zmniejszeniem zarobków, na co nie każdy może sobie pozwolić. Trzeba również poświęcić trochę prywatnego czasu by osiągnąć biegłość