Wysokie zarobki w językach i technologiach legacy - COBOL i RPG

Narosło wiele mitów i legend w których nawet były smoki odnośnie utrzymania starych systemów legacy w archaicznych technologiach, mitycznych legacy systemach których kiedyś ktoś napisał, nie maja dokumentacji i firmy nie mając wyjścia muszą zapłacić za ich utrzymanie. Przepisanie systemu jest zazwyczaj nieopłacalne lub niemożliwe

Główne języki o których się mówi to COBOL oraz RPG.

Czy spotkaliście się z takimi bardzo archaicznymi systemami napisanym w językach wymarłych w których już nikt nie pisze nowych systemów?
Czy zarobki w tych technologiach względem mianstreamu java / c# / c++ etc. były faktycznie znacząco wyższe? Jeżeli tak to o ile? 10% czy 50%?
Czy można wyrazić liczbami o ile procentowo zarobki w takich technologiach są wyższe / niższe względem pozostałych mainstreamowych i na jakie dane się powołać?
Czy praca z takimi systemami jest faktycznie udręką i jest bardzo nieprzyjemna?
Czy w momencie zamknięcia systemu lub upadku firmy jest duży problem z znalezieniem pracy a możliwości jakiegokolwiek rozwoju są niemożliwe?
Czy zajmowanie się legacy nie pod kątem refactoringu ale utrzymania jest strzałem w stopę?

Rozwijać się możesz pracując nawet w Januszsofcie. Bo rozwój nie jest uzależniony od pracy. Po prostu jeśli jest częścia pracy to masz wtedy więcej czasu na inne rzeczy po pracy. Możesz wymiatać na poziomie guru algorytmiki i projektowania mikroczipów będąc plantatorem bananów jeśli poświęcisz na to tyle czasu co na pracę lub więcej.

Co do częstotliwości występowania to pisano w tym systemy w póżnych latach 50 do 80tych i uchowały się głównie tam gdzie nie musiały się jakoś szybko i często zmieniać pod względem logiki. Ubezpieczenia, bankowość. Więcej będzie zachodniego kodu chociaż i za komuny trochę klepano w Rzeczpospolitej Ludowej.

Czy są wyższe wynagrodzenia to zależy od majętności pracodawcy i jego perspektyw na rynku. Poczytaj o upadłościach banków czy firm ubezpieczeniowych.

Czy praca z takimi systemami jest faktycznie udręką i jest bardzo nieprzyjemna? Czy seks grupowy w lateksie na pełnym słońcu w lecie jest faktycznie udręką i bardzo nieprzyjemny? Czy bycie oblewanym roztopionym woskiem w trakcie zabaw BDSM jest udręką czy przyjemnością? Czy rurki z kremem są lepsze od ciastek z galaretką?

Czy zajmowanie się legacy nie pod kątem refactoringu ale utrzymania jest strzałem w stopę? Zależy od twego wyznania reliijnego. Jeśli jesteś kultystą refactorinu i doktryna twego zgromadzenia potępia utrzymaniówkę to odpowiedź prawdopodonie brzmi "tak". Jeśli pytanie ma charakter pozareligijny to jest ono (jak i kilka poprzednich) trochę w stylu pytania nas publicznie czy więcej frajdy da ci seks z mężczyzną czy z kobietą.

Marcin Marcin napisał(a):

Czy spotkaliście się z takimi bardzo archaicznymi systemami napisanym w językach wymarłych w których już nikt nie pisze nowych systemów?

Tak z PowerBuilderem.

Czy zarobki w tych technologiach względem mianstreamu java / c# / c++ etc. były faktycznie znacząco wyższe? Jeżeli tak to o ile? 10% czy 50%?

Nie, Ostatnio duża firma (korporacja światowa z miliardowymi obrotami ) szuka człowieka do utrzymania ich systemu napisanego w PB i stawki są na poziomie C#.

Czy można wyrazić liczbami o ile procentowo zarobki w takich technologiach są wyższe / niższe względem pozostałych mainstreamowych i na jakie dane się powołać?

Jak to nie jest jakaś mega niszowa technologia, specjalizowana to nie dobiegają znacząco.

Czy praca z takimi systemami jest faktycznie udręką i jest bardzo nieprzyjemna?

Z reguły te narzędzie są nie rozwijane od lat, przez to są toporne, brakuje dużo ułatwień jakie są w innych językach. No i jest mała społeczność to rozwiązania problemów ciężko znaleźć na SO.

Czy w momencie zamknięcia systemu lub upadku firmy jest duży problem z znalezieniem pracy a możliwości jakiegokolwiek rozwoju są niemożliwe?

Problemy są spore bo takich ofert nie ma dużo, oczywiście przekwalifikowanie się to nie jest jakiś wielki problem, dla kogoś z kilku/kilkunastym letnim doświadczeniem, ale patrzą trochę nie ufnie na człowieka (nawet jak masz wcześniejsze doświadczenie w innych technologiach)

Czy zajmowanie się legacy nie pod kątem refactoringu ale utrzymania jest strzałem w stopę?

Co kto lubi, ja lubię pracować w utrzymaniu, meczy mnie pisanie kolejnych funkcji API, takich samych do znudzenia podobnych. W utrzymaniu nigdy nie wiesz co się trafi. Najgorsze jest stres jak napierają na ciebie że przez niedziałający system towar nie może wyjechać z magazynu.

"Karierę" programisty zaczynałem jako SAP ABAP dev (taki mix COBOLa z SQLem w środowisku ERP), więc spotkałem się z archaicznym kodem sprzed kilkunastu albo i nawet kilkudziesięciu lat. Pliki z tysiącami liniami kodu, ifowiska, miliony pętli, komentarze i nazwy zmiennych po niemiecku, łamanie wszystkich zasad czystego kodu, wszystko tam można było znaleźć. Robota ta była strasznie nieprzyjemna, wszystko było robione na odwal się, wstawić ifa byle działało i fajrant. Dodatkowo mój pracodawca to była korpo-kontraktownia (najgorsze połączenie), więc zdarzała się presja ze strony klientów, których nie obchodziło to, że jestem juniorem ze stażem poniżej roku. Jakiegoś wsparcia ze strony seniorów też nie było (może to kwestia firmy), code review też nie istniał (nie korzystaliśmy z systemów kontroli wersji, jakie są obecnie znane).

Czy są wyższe zarobki pracując z SAPem? Tak i nie. Można znaleźć bardzo dobre kontrakty, ale można też trafiać na korpo-kontraktownie jak ja, gdzie zarobki są niskie, nieprzekraczające zarobków w nowszych technologiach i niewarte tego typu roboty. No i o ile się nic nie zmieniło w ciągu tych kilku lat, to robota w ABAPie jeszcze długo będzie, bo SAP ERP to korporacyjny moloch, który potrafi wszystko, więc jeszcze długo będzie używany i wspierany. Ofert pracy jest mniej niż jakichś Javach, ale nie jest to aż tak niszowe znowu.

Nie wiem, czy jest to strzał w stopę, ale ja nie potrafiłem wytrzymać w tego typu środowisku. Teraz pracuję jako fullstack node.js i skok jakościowy jest ogromny. Dużo przyjemniej mi się pracuje z TSem, czystym kodem, Reactem, nowoczesnymi bazami, gdzie zespół dba o jakość kodu i jest chętny, żeby pomóc. Więcej w tego typu legacy bym się nie pchał, ale kto co woli. Znam ludzi, którzy się w tym dobrze odnajdują i archaiczność im nie przeszkadza.

Ja bym nie szedł tą drogą, w sensie w jakieś nisze. Jak się skończy utrzymanie, bo przepiszą projekt na nowy język, to potem po kilku latach zostaniesz z ręką w nocniku, bo ciekawe gdzie pracę znajdziesz, jak wymrą do reszty przez ten czas te niedobitki, które gdzieś tam jeszcze funkcjonują. I co potem w CV napisać że się przez ostatni czas robiło?

Programowało. Myślisz, że klepanie dla januszexu jest jakoś bardziej prestiżowe?

Prestiżowe czy nie - obcujesz z żyjącą technologią, a nie jakaś nekrofilia :-D

A co jest w COBOL takiego martwego? COBOL 2014 był zbyt dawno temu?

Satanistyczny Awatar napisał(a):

A co jest w COBOL takiego martwego? COBOL 2014 był zbyt dawno temu?

Dla mnie język jest martwy jak przestają powstawać w nim nowe projekty. Wyobrażasz sobie, że ktoś będzie pisał nowego Facebooka w COBOLU?

Podsumowując:
-w technologiach legacy nie ma pieniędzy względem mainstreamu (zarobki nie są wyższe)
-języki typu COBOL i RPG są wymarłe gdyż nie są w nich tworzone nowe systemy
-rozwijanie lub utrzymywanie aplikacji w technologiach legacy jest nieopłacalne względem rozwoju
-pracując w nowej technologii rozwijasz się także w pracy i jest to na duży plus
-narzędzia i techniki są przestarzałe przez co mało efektywne względem obecnie używanych technologii
-mniejsza społeczność rozwijająca i tworząca daną technologię (trudniej spotkać programistę cobola niż java / c# / c++ / javascript)
-w przypadku chęci zmiany pracodawcy lub przepisaniu systemu na nowy może doprowadzić do trudności w znalezieniu nowej pracy

Podsumowując: warto przepisać na coś nowego, nie warto utrzymywać

Marcin Marcin napisał(a):

Podsumowując:
-w technologiach legacy nie ma pieniędzy względem mainstreamu (zarobki nie są wyższe)

Zależy od projektów.

-języki typu COBOL i RPG są wymarłe gdyż nie są w nich tworzone nowe systemy

Pół prawda pół nieprawda.

-rozwijanie lub utrzymywanie aplikacji w technologiach legacy jest nieopłacalne względem rozwoju

Zależy od projektu

-pracując w nowej technologii rozwijasz się także w pracy i jest to na duży plus

Fałszywy wniosek z fałszywych przesłanek.

-narzędzia i techniki są przestarzałe przez co mało efektywne względem obecnie używanych technologii

Założenia wyssane z palca i udowadniane machaniem rękami.

-mniejsza społeczność rozwijająca i tworząca daną technologię (trudniej spotkać programistę cobola niż java / c# / c++ / javascript)

Prawda.

-w przypadku chęci zmiany pracodawcy lub przepisaniu systemu na nowy może doprowadzić do trudności w znalezieniu nowej pracy

Gdyż?

Podsumowując: warto przepisać na coś nowego, nie warto utrzymywać

W wielu wypadkach jest to nieopłacalne i ryzykowne.

Satanistyczny Awatar napisał(a):

Marcin Marcin napisał(a):

Podsumowując:
-w technologiach legacy nie ma pieniędzy względem mainstreamu (zarobki nie są wyższe)

Zależy od projektów.

Pokazałbyś liczby i dane na których się opierasz?

-języki typu COBOL i RPG są wymarłe gdyż nie są w nich tworzone nowe systemy

Pół prawda pół nieprawda.

Jaki nowy system tworzony jest w COBOLu lub RPG ?

-rozwijanie lub utrzymywanie aplikacji w technologiach legacy jest nieopłacalne względem rozwoju

Zależy od projektu

Jak rozwiniesz się utrzymując legacy w technologii legacy?

-pracując w nowej technologii rozwijasz się także w pracy i jest to na duży plus

Fałszywy wniosek z fałszywych przesłanek.

Jeżeli w ciągu dnia pracujesz 8h z technologią mainstreamową a nie z legacy jest to lepsze dla własnego rozwoju, chyba że czegoś nie rozumiem

-narzędzia i techniki są przestarzałe przez co mało efektywne względem obecnie używanych technologii

Założenia wyssane z palca i udowadniane machaniem rękami.

Czy COBOL oraz RPG mają nowe funkcje języka?

-mniejsza społeczność rozwijająca i tworząca daną technologię (trudniej spotkać programistę cobola niż java / c# / c++ / javascript)

Prawda.

-w przypadku chęci zmiany pracodawcy lub przepisaniu systemu na nowy może doprowadzić do trudności w znalezieniu nowej pracy

Gdyż?

Nie przybywa nowy projektów więc liczba ofert będzie się tylko zmniejszać

Podsumowując: warto przepisać na coś nowego, nie warto utrzymywać

W wielu wypadkach jest to nieopłacalne i ryzykowne.

a czy ryzykownym jest posiadanie systemu którego przepisanie jest kosztowane a jednocześnie specjalistów na rynku jest bardzo mało względem javy / c# / javascript ?

Marcin Marcin napisał(a):

Satanistyczny Awatar napisał(a):

Marcin Marcin napisał(a):

Podsumowując:
-w technologiach legacy nie ma pieniędzy względem mainstreamu (zarobki nie są wyższe)

Zależy od projektów.

Pokazałbyś liczby i dane na których się opierasz?

Musiałbyś mi wyjaśnić na jakich danych się niby opieram bym ci mół je pokazać. Bo nic mi nie wiadomo bym się opierał na jakichś konkretnych liczbach. Na pewno opieram się na tym co widywalem na przestrzeni lat i tak widywałem oferty które miażdżyły mainsteamową konkurencję wynagrodzeniem mając za wymagania wstępne prawie tyle co nic.

-języki typu COBOL i RPG są wymarłe gdyż nie są w nich tworzone nowe systemy

Pół prawda pół nieprawda.

Jaki nowy system tworzony jest w COBOLu lub RPG ?

Współpracujacy z istniejącymi celem zachowania spójności środowiska.

-rozwijanie lub utrzymywanie aplikacji w technologiach legacy jest nieopłacalne względem rozwoju

Zależy od projektu

Jak rozwiniesz się utrzymując legacy w technologii legacy?

Zależy od projektu.

-pracując w nowej technologii rozwijasz się także w pracy i jest to na duży plus

Fałszywy wniosek z fałszywych przesłanek.

Jeżeli w ciągu dnia pracujesz 8h z technologią mainstreamową a nie z legacy jest to lepsze dla własnego rozwoju, chyba że czegoś nie rozumiem

Zależy od projektu.

Technologia sama w sobie nie decyduje o rozwoju czy jego braku.

Możesz się rozwijać jako programista nawet nie pisząc ani jednej linii kodu przez lata.

To, że coś wydano wczoraj nie oznacza też że praca z tym będzie bardziej rozwijająca niż wydanym rok temu czy 100 lat temu.

Odkąd zacząłem się interesować starszym oprogramowaniem i hardware wiele mi się w głowie poukładało bo są to systemy o mniejszym stopniu skomplikowania (nie mylić z trywialnymi) przez co łatwiej się wielu zagadnień na nich uczyć (po co są dane elementy i czemu stopniowo wproadzono kolejne) dodatkowo często implementują bardzo optymalne algorytmy których w nowych projektach nie uśwadczysz bo tam się często notorycznie wali bruteforce zamiast przejrzeć chociaż jakąś podstawową literaturę czy nowsze publikacje naukowe.

-narzędzia i techniki są przestarzałe przez co mało efektywne względem obecnie używanych technologii

Założenia wyssane z palca i udowadniane machaniem rękami.

Czy COBOL oraz RPG mają nowe funkcje języka?

Jeśli masz na myśli czy są nowe stadardy, które wrowadzają nowe rzeczy to tak. Była ich masa.

-mniejsza społeczność rozwijająca i tworząca daną technologię (trudniej spotkać programistę cobola niż java / c# / c++ / javascript)

Prawda.

-w przypadku chęci zmiany pracodawcy lub przepisaniu systemu na nowy może doprowadzić do trudności w znalezieniu nowej pracy

Gdyż?

Nie przybywa nowy projektów więc liczba ofert będzie się tylko zmniejszać

A ktoś zmusza się ograniczać do jednego języka? Jesteś jednym z tych, którzy pracują w jednym języku od kołyski aż po grób i nie tykasz niczego w innych? Zanim skończyłem studia to miałem już styczność z kilkunastoma, potem w pracy zawodowej też trzeba się było posługiwać kilkoma w tym takimi, które pierwszy raz na oczy widzisz co najmniej na poziomie rozumienia co kod robi. Widywałem też osoby skaczące zawodowo z dość odległych działek do innych przykładowo JAVA->embeded C, PHP->embeded C. Potem też niektórzy z nich szli w jeszcze inne klimaty.

Podsumowując: warto przepisać na coś nowego, nie warto utrzymywać

W wielu wypadkach jest to nieopłacalne i ryzykowne.

a czy ryzykownym jest posiadanie systemu którego przepisanie jest kosztowane a jednocześnie specjalistów na rynku jest bardzo mało względem javy / c# / javascript ?

Zależy od projektu. Raczej istnieją dość racjonalne powody czemu np. stare i poważane firmy ubezpieczeniowe do dziś trzymają kod w COBOL i raczej nie są to powody typu "bo firma kocha życie na krawędzi".

Żeby pisać trzeba pisać

Wydrukowałem sobie i powiesiłem nad biurkiem wiele lat temu gdy @Matttt powiedział o tym na swoim blogu

Moim zdaniem niezależnie czy junior, mid czy senior jak uczy się programowania a nie ma kodu który może pokazać to coś z tą nauką jest nie tak

Można rozwiązać problem bez pisania kodu ale są to raczej wyjątki

Marcin Marcin napisał(a):

Żeby pisać trzeba pisać

Motto każdego grafomana.

@Satanistyczny Awatar: jak według Ciebie jak można sję rozwijać bez pisania kodu?

Nauka programowania bez pisania kodu To trochę jak czytanie książek o pływaniu bez wchodzenia do wody

Marcin Marcin napisał(a):

@Satanistyczny Awatar: jak według Ciebie jak można sję rozwijać bez pisania kodu?

Prawidłowo, szybko i zdrowo.

Nauka programowania bez pisania kodu To trochę jak czytanie książek o pływaniu bez wchodzenia do wody

Nikt tutaj nie postuluje nauki programowania bez pisania kodu. Po prostu programowanie (i jego nauka też) to dużo więcej niż samo pisanie.

Pisać można zawsze i wszędzie.

Nie zawsze i wszędzie jest to potrzebne. Nie zawsze i wszędzie pisanie wystarczy.

Samo pisanie kodu nie nauczy cię gdzie co i jak pisać. Do tego trzeba jeszcze czegoś więcej. Samo pisanie kodu nie sprawi, że zaczniesz pisać silniki renderujące grafikę 3D. Tutaj jeszcze trzeba matematyki a najlepiej jeszcze do tego rozumienia hardware. Samo pisanie kodu nie nauczy cię dzielić kodu na moduły - tutaj trzeba rozumienie dziedziny którą kod ma modelować - ona często daje wskazówki co do zależności między czynnościami jakie kod ma wykonywać. Samo pisanie kodu nie nauczy cię optymalizacji metod numerycznych korzystając z faktu, że przykładowo aplikacja w praktyce w pewnych miejscach działać będzie tylko na macierzach trójkątnych o stałym rozmiarze i nie ma sensu korzystać w tym miejscu z implementacji bardziej uniwersalnej bo szkoda pamięci i czasu pracy procesora. Samo pisanie kodu nie nauczy cię, że właśnie opublikowano jakiś nowy algorytm szybszego mnożenia dużych liczb, który może przyspieszyć działanie systemu algebry komputerowej nad której rozwojem pracujesz. Już tutaj pominę, że trzeba cokolwiek jednak wiedzieć o algebrze by pracować szybko i efektywnie nad rozwojem takiego systemu i każdy znający tematyke okołoalgebraiczną programista będzie miał w oczach potencjalnego pracodawcy przewagę nad tym który nie ma w tym temacie nic do powiedzenia. Samo pisanie kodu nie nauczy cię że kod który piszesz można potencjalnie przyspieszyć przeksztłcając go tak by był łatwiejszy do przetrawienia dla mechanizmów procesora takich jak cache czy branch prediction.

Programowanie to też czytanie masy kodu często pisanego przez innych. Tak ludzi z zespołu jak też kodu projektów z którymi nie jesteś zawodowo związany. Czytasz i oceniasz czytelność. Jasność impementacji dla czytelnika. Łatwość nawigacji w kodzie i projekcie. Podłapujesz ciekawe modele organnizacji kodu, projektu, popularne idiomy. Czy poznajesz przy okazji nowe ciekawe biblioteki które możesz wykorzystać w swoich projektach.

Programowanie to też wywalanie do kosza całych plików po zorientowaniu się że ten kod nie ma racji bytu bo jest za wolny, żre za dużo energochłonnych zasobów urządzenia które ma działać jak najdłużej na baterii i jeszcze steki jak nie tysiące innych powodów.

Samo pisanie też nie nauczy cię czy to co piszesz nie było już zaimplementowane przez kogoś i to w sposób wystarczająco efektywny/wydajny by uczynić niekoniecznie wartosciowym twój wysiłek jaki byś musiał ponieść by zaimplementować taką samą lub gorszą wersję samodzielnie.

Mogę jeszcze podawać więcej przykładów czego "pisanie aby pisać" nie wniesie do rozwoju jako programista.

Większość z tych rzeczy nie wymaga ślęczenia nad edytorem kodu do posunięcia twego rozwoju do przodu. Ogrom wiedzy która może programistę wspomóc jest wręcz na tyle duży że nawet najwieksi piwnicznicy nie wyrobią fizycznie i czasowo by wszystko implementować.

W końcu przychodzi czas że trzeba napisać kod i aby zrobić to dobrze trzeba ćwiczyć

Marcin Marcin napisał(a):

Żeby pisać trzeba pisać

Wydrukowałem sobie i powiesiłem nad biurkiem wiele lat temu gdy @Matttt powiedział o tym na swoim blogu

Jesteś pewien, że projektant gier planszowych to dobry idol w tej branży?

Marcin Marcin napisał(a):

W końcu przychodzi czas że trzeba napisać kod i aby zrobić to dobrze trzeba ćwiczyć

Tak, tylko o ile zrozumiałe jest, że mając 3 lata doświadczenia piszesz lepiej niż mając 1 rok, to jeśli z 10 i więcej latami doświadczenia nadal odczuwasz wzrost umiejętności pisania, to coś jest bardzo nie tak.

W legacy masz połowę wynagrodzenia co w mainstream. Praca z legacy jest przyjemniejsza, bo nie masz frameworków, kod jest czytelniejszy. Jak stracisz pracę to drugiej raczej nie znajdziesz w legacy, bo praca w legacy się po prostu trafia i tyle. Nie przepiszesz legacy na coś nowego, już wielu próbowało.

Pracowałem w Legacy i w projekcie "nowym" gdzie wszystko budowaliśmy na AWS - Lambdy.

Popracuj w Legacy 3 lata gdzie masz Jave EE + Tomcata i popracuj 3 lata w ekosystemie AWS pisząc kod na tą platformę np. wykorzystując AWS Lambda, DynamoDB.

Potem wyślij CV i zobaczysz jaki będziesz mieć odzew na rekrutacjach i jak ludzie będą na Ciebie patrzeć. Wnioski chyba same się nasuwają.