Zbliżone stawki - z czego to wynika?

2

Nie potrafię odpowiedzieć sobie na jedno pytanie.

Czemu stawki frontendowca / backendowca / czy nawet QA w tak wielu ogłoszeniach są do siebie zbliżone?

Gdy myślę o tym to mam przekonanie, że zmiany backendowca są trudniejsze, bo ten musi znać szerszy kontekst (by lepiej projektować), często musi znać więcej informacji (aws, bazy, rzeczy dotyczące współbieżności)? Tutaj więcej rzeczy można skopać, i straty mogą być odczuwalne dla firmy. Taki dev nawet w B2B moim zdaniem ma na sobie większą odpowiedzialność.

Np. kwestie dotyczące wyglądu łatwiej wyoutsourcować, co znaczy, że ogrywają znacznie mniejszą rolę z perpektywy biznesu. Czemu więc stawki są zbliżone? Czemu QA również ma zbliżoną stawkę skoro jego techniczna świadomość jest znacząco mniejsza względem backendowca?

Mam 2 wnioski:

  1. że to jest trochę jak z gamedev, więcej się pcha tam gdzie jest ciekawie i z tego powodu stawki są jakie są
  2. że stawki jakie dostajemy są równoznaczne z pensjami jakie dostałby wyrobnik za granicą i że z perspektywy zachodnich firm to żaden z tych kierunków o jakich piszę nie jest ani lepszy, ani gorszy, a po prostu inny

EDIT:

Jeszcze JS rozumialem, że kasa jest większa względem wymagań, bo większy syf idzie spotkać (dynamiczne typowanie) + frameworki za często się zmieniają, ale w sumie teraz to ciężko jest na to tak narzekać. Jest typescript, i ogólnie dwa główne podejścia angular/react, które ciągle utrzymują. Programowanie na froncie jest coraz bardziej lajtowe.

1

Nie tylko za czystą wiedzę techniczną się płaci jak coś.

0

W moim korpo, gdy był dopływ pieniędzy rekrutowało się kogo bądź, bo była kasa - wpadły 2 bardzo słabe osoby za kasę większą, niż ja - nic nie zrobili, 0 wartości dodanej - więc myślę, że jest kasa, to się rekrutuje, a że teraz wszędzie KLAŁD MIGRACJA, to się bierze co popadnie, byle bylyby dupogodziny.

4
pan_krewetek napisał(a):

Czemu stawki frontendowca / backendowca / czy nawet QA w tak wielu ogłoszeniach są do siebie zbliżone?

Bo stawka robotnika od front-end, back-end, quality itd. jest w kalkulacji zagranicznego klienta taka sama bo to samo stanowisko.

W sumie, to nie wiem, skąd to pytanie, bo cieśla czy murarz, choć to człowiek prosty, to nie trzeba mu tłumaczyć, że na budowie zarobi na miesiąc 12 tysięcy zł (w przeliczeniu na złotówki) + darmowe zamieszkanie i nie główkuje czy cieśla ma łatwiej czy ciężej.
Co najwyżej zastanawia się jak zostać majstrem i zgarniać 18 tys zł jak się poduczy trochę norweskiego.

0

Znaleźć dobrego automata nie jest łatwo, u nas na specyficznych pozycjach (no leadzi zespołów) płaci się im więcej niż frontendowcom i backendowcom. Tak samo devopsi/SRE mają rutynowo więcej niż backend, frontend albo QA na wszystkich poziomach, bo jest duże ssanie i znalezienie kogoś faktycznie kompetentnego kosztuje - ale mniej niż wyjebana produkcja.

8

Polecam lekturę sprzed 20 lat, w tej kwestii nic się nie zmieniło:
https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/

If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think that the program is 90% worse.

W większości projektów front to 10%, a backend 90% pracy. Ale dla managementu zazwyczaj najważniejsze są pixele.

PS. Ja sam zresztą jak zmieniają się wersje Ubuntu to dostrzegam głównie zmienione zwierzątka na tapecie :)

4

Ciezko stwierdzic bez znajomości projektu. Zeby zatrzymać nasilajacy sie circlejerk backendowcow w topicu, są bardzo latwe backendy, gdzie dosłownie sie przerzuca jsony miedzy mikroserwisami, zmieniajac po drodze pare nazw pol i skomplikowane fronty z np. wizualizacjami 3D, lub gdzie sie walczy o kazdy kB bundla i 0.1 sekunde czasu ladowania/rendera :D .

Ogolnie wspolczesny front tez ma w sobie sporo biznes logiki, kod której powiniem byc, jak każdy inny, dobrej jakosci rozszerzalny, modyfikowalny, czylelny i otestowany. Brak powyzszego wiaze sie z drastycznym spadkiem jakosci i/lub spowolnieniem developmentu, co sie przeklada na koszty, jak pieniężne, tak i "opportunity cost".

10

Bo tester ma przewalone. Zazwyczaj jest ich za mało.
Nie mówię o klikaczach, którzy byli zatrudnieni jak automatyzujący (ale nakłamali w CV, że potrafią (bo przeczytali 2 artykuły)), którzy marnują zarówno swój czas jak i firmy, bo sprawdzają regresję pół tygodnia zamiast 20 minut.

Dobry tester dobrze zarobi, bo wnosi sporą wartość.

Bo frotnendowiec ma przewalone.
UX, skrypty i milion rzeczy do klienta plus ciągle jakieś poprawki, to jest naprawdę męczące.

Najwięcej takich słabych programistów jakich spotkałem, to tacy stricte backendowcy starszego pokolenia, którym udało się gdzieś przeleżeć pod kamieniem w firmie i tak zleciało 10 lat na dodawaniu kolumn do bazy i pisaniu crudów.
A przyjdzie coś nowego robić, to nie ma z kim pracować, bo nagle wychodzą tragiczne braki wiedzy jak i rozeznania.

I tak uważam że spora część backendowców i ogólnie programistów zarabia więcej niż powinna, bo zazwyczaj nie zasługują.
Często swoją pracą powodują jedynie to, że inni ciągle muszą poprawiać/trzeba 2 programistów zamiast jednego żeby coś sensownie ogarnąć.

1

Z pamięci

W Apollo 13 jest scena, w której zaangażowani w swoją misję astronauci na orbicie odpowiadają na pytania.
Nie pamiętam już dokładnie.

Ktoś na ziemi przełącza w TV kanały, talk show, muzyka, astronautów nikt nie transmituje.
Trudno, tylko nie mówcie im o tym - komentuje jeden z szefów w Houston.

*Na pewno OT? *

7

Dlaczego uważasz, że praca backendowca jest trudniejsza? Przecież jest bardzo dużo iście małpiej roboty na backendzie, gdzie ani nic skomplikowanego się nie dzieje, ani nie ma szczególnie dużego ruchu, ani nie trzeba walczyć o żadne kilobajty, ani o żadne RPS, no po prostu o nic - i tak się żyje na tej wsi :(

0

@superdurszlak: Wiesz co, to jest bardzo dobre pytanie!

Większe projekty są przede wszystkim większe (nie mówię tu o prostych crudach, bo na tym to też za bardzo nie zarobisz jako dev). Jest większa logika, często złożony przepływ sterowania (np. wątki, locki na bazie), a wraz z tym dużo rzeczy charakterystycznych dla wybranej domeny. Trzeba o tym więcej rozmawiać, rozumieć co robić, co propopnujesz. Jest też więcej programistów na backendzie, także to też pewien koszt (w moim odczuciu) jeśli chodzi o złapanie wspólnej częstotliwości.

EDIT:

W zasadzie wiem jak to lepiej oddać:

  1. Dostajesz projekt, masz coś tam zrobić.

  2. Napotykasz problem #1 (gdzie, co, jak?)

  3. Napotykazs problem #2 (dlaczego?)

  4. Napotykasz problem #3 (jak im powiedzieć, że właśnie walimy głową o ścianę)

Uważam, że taki dev 90% czasu nie pisze kodu albo nie pisze tego co powinien. Tu warto zdobyć jasne zrozumienie sytuacji i sformułowanie rozwiązania tego tak, by nie zostać spalonym jak czarownica na stosie). Z mojej perspektywy taki dev bierze wtedy na siebie odpowiedzialność, musi wziąć jesli chce robić swoją pracę dobrze. Natomiast tak jak wcześniej pisałem z perspektywy B2B też jest to powalone, umowy z jakimi się spotkałem są niedorzeczne.

Co musi widzieć js dev? albo qa? Wiadomo ich perspektywa pracy nie uważam, żeby była jakoś super lżejsza, jest to nudna powtarzalna robota, ale ma mniejszy zakres dotyczący komunikacji czy całego wkładu.

2

Gdyby taki spec od frontu/qa/backend zarabiał zauważalnie mniej od kogoś z pozostałych dwóch, to nikt nie chciałby pisać frontu/backendu/testować i by był problem xD

4
pan_krewetek napisał(a):

@superdurszlak: Wiesz co, to jest bardzo dobre pytanie!

Większe projekty są przede wszystkim większe

Ale to będzie prawdą wszędzie. Jeśli projekt jest duży i obsługuje złożone procesy, to QA też nie będzie polegać na kliknięciu jednego guzika, tylko przejścia przez proces, pod-procesy, przypadki szczególne których będzie milion, coś-tam jeszcze. Jeśli już porównujemy, to róbmy fair porównanie, a nie tak że w jednym narożniku mamy backendowca z Amazona a drugim frontendowca - ale robiącego stronki-wizytówki przy taśmie...

(nie mówię tu o prostych crudach, bo na tym to też za bardzo nie zarobisz jako dev).

Niedługo będę miał trzecią rocznicę zostania klepaczem CRUDów i przez znaczną większość tego czasu zarabiałem więcej, niż gdy robiłem nie-CRUDy :)

Jest większa logika, często złożony przepływ sterowania (np. wątki, locki na bazie), a wraz z tym dużo rzeczy charakterystycznych dla wybranej domeny. Trzeba o tym więcej rozmawiać, rozumieć co robić, co propopnujesz. Jest też więcej programistów na backendzie, także to też pewien koszt (w moim odczuciu) jeśli chodzi o złapanie wspólnej częstotliwości.

Ale rozmawiać muszą wszyscy ze wszystkimi, jak backendowcy kiszą się we własnym towarzystwie, frontendowcy we własnym, QA we własnym, architekci piją szampana w swojej wieży a devopsów zamknięto w bunkrze to strzelam w ciemno, że powstaje z tego potworek :D

W zasadzie wiem jak to lepiej oddać:

  1. Dostajesz projekt, masz coś tam zrobić.

  2. Napotykasz problem #1 (gdzie, co, jak?)

  3. Napotykazs problem #2 (dlaczego?)

  4. Napotykasz problem #3 (jak im powiedzieć, że właśnie walimy głową o ścianę)

Takie problemy są tylko w backendzie? Ja do dziś pamiętam frustrację ludzi walczących z CSSami, żeby coś działało w Operze, Chrome, Firefoxie, plus w archaicznym Internet Explorerze...

Co musi widzieć js dev? albo qa? Wiadomo ich perspektywa pracy nie uważam, żeby była jakoś super lżejsza, jest to nudna powtarzalna robota, ale ma mniejszy zakres dotyczący komunikacji czy całego wkładu.

No jak już mówiłem jeśli komunikacja wygląda tak jak opisujesz, to znaczy że nie wygląda.

5

Patrząc po tym jak wyglądają zadania web na CTFach to nie wiem czy ten front jest taki znowu prosty ;) Kiedyś faktycznie tak może było, za czasów kiedy frontend to był html+css+trochę js/jquery. Ale dzisiaj to jakieś service workery, WebGL, css3 i inne cuda i wcale nie jestem przekonany ;)

Jeśli chodzi o QA to mało kto zatrudnia dziś klikaczy i ludzie od QA to zwykle programiści którzy piszą infrastrukture do testowania aplikacji i ich praca jakoś strasznie nie różni się od pracy "zwykłego" programisty.

1
pan_krewetek napisał(a):

Nie potrafię odpowiedzieć sobie na jedno pytanie.

Czemu stawki frontendowca / backendowca / czy nawet QA w tak wielu ogłoszeniach są do siebie zbliżone?

Bo stawki są ustalane przez ludzi którzy nie zajmują się developmentem. Np. junior dev zarobi np. 3-5k zł na rękę, regular 5-10k, senior 10-15k. Koszt jednego seniora to 3 juniorów. Czy 6 juniorów pracuje tak samo szybko jak 2 seniorów? Z praktyki doświadczony senior pracuje nawet 10x szybciej niż regular (diagnoza i naprawa błędu zajmuje mu np. 30 minut zamiast 5h), natomiast porównywanie go do juniora jest już zupełnie bez sensu bo junior developer będzie mieć nieskończony czas wykonywania większości trudniejszych zadań (nigdy ich nie skończy z sukcesem). Czyli realnie senior jest znacznie tańszy od regulara i nieskończenie tańszy od juniora (przeliczając to np. na story pointy w projekcie wyjdzie że 1 SP seniora kosztuje powiedzmy 500 zł a regulara 2000 zł).
Więc czemu seniorzy nie zarabiają proporcjonalnie do wydajności? Bo jak wyżej napisałem, stawki nie są ustalane przez developerów tylko managerów na średnim i wyższym poziomie, którzy często nie odróżniają bazy danych od serwera www i traktują te stanowiska jak inną odmianę IT supportu.

Jedynie stawki konsultantów są "rynkowe" tzn. faktycznie zależą od wydajności i wartości wykonywanej pracy, więc backendowiec może zażądać np. 30-40k zł na rękę a frontendowiec owszem też, ale jeśli jest to jakieś topowe cudo typu kompletna aplikacja w przeglądarce. To są "realne" pensje które wynikają z nagłej potrzeby zrobienia czegoś. W normalnej pracy niestety walec wszystko wyrównuje.

10

Widzę, że w kąkuter poklika i bierze pieniądze wiecznie żywe, tylko tutaj w formie użyje API i pokaże na ekranie albo poklika po aplikacji i sprawdzi czy ok. Są projekty mniej i bardziej ambitne, są projekty mniej i bardziej złożone. Backend nie jest jakimś specjalnym rodzynkiem, jeśli o to chodzi.

0

@Michał Sikora: Myśle że jest wiele aplikacji gdzie backend to generic crud a frontend stanowi prawdziwe wyzwanie :) Żeby daleko nie szukać, choćby https://archive.eso.org/scienceportal/home gdzie w zasadzie nie mamy backendu, ot nakładka na elasticsearcha i nic więcej (przynajmniej w głównym widoku tej aplikacji).

3

A co w tym dziwnego, że pensje są zbliżone?
Do wytworzenia jakiegoś sensownego produktu potrzebne są osoby o różnych specjalizacjach.
Czy backend jest trudniejszy od frontu? Pewnie dla jednego tak dla innego nie, to jest pojęcie względne i też zależne od projektu.
QA? Myślisz, że tak byś sobie siadł i poklikał w kilka minut i zrobił taką samą robotę jak doświadczona osoba na tym stanowisku jeszcze z wiedzą domenową? No nie. QA to też nie samo klikanie.
Programista ma większą wiedzę techniczną od QA w projekcie to fakt, ale za to QA ma większą wiedzę biznesową i działania ogólnego aplikacji a przynajmniej powinien co często jest równie istotne, bo finalnie za to płaci klient. Czasami programista zna fragment w którym sobie grzebie, a może nie wiedzieć, że niektóre rzeczy istnieją. A jak ktoś jest "klikaczem" co nie ogarnia nic więcej to pensję też ma dużo niższą.
Czemu mamy managerów którzy zarabiają jeszcze więcej a czasem też nie mają wiedzy technicznej?
To tak jakby nauczyciel fizyki mówił, że on robi trudniejsze rzeczy i czemu nie zarabia dużo więcej od nie wiem nauczyciela angielskiego w tej samej szkole.
Ludzie w IT zarabiają duże pieniądze dlatego, że jest duże zapotrzebowanie na specjalistów których brakuje i firmy płacą bardziej zagraniczne stawki(no mniejsze) porównując do innych branż, ale przeliczając na PLN to daje duże pieniądze. I płacą tyle, bo dzięki temu dalej mają zysk, nie płacą dlatego, że programiści to jakieś wyjątkowe płatki śniegu i robią jakieś mega wyjątkowe rzeczy, szczególnie taki "przeciętny" pracownik it.
Brzmisz jakbyś czuł się taki trochę lepszy i ważniejszy od innych. Zgaduję, że jesteś takim trochę "pasjonatem" i czujesz się sfrustrowany, że inni ludzie dla których nie wiem to jest tylko praca, nie żyją tym od lat i potrafią mniej z "Twojej" dziedziny mogą zarabiać podobnie, a według Ciebie inne rzeczy są łatwiejsze.

1

Dev nie pisze tego co powinien, bo kiedyś był waterfall i wszystko było wiadome na początku, wszystko w kodzie dało się zaprojektować bo była jedna spójna specyfikacja. W trakcie zmieniało się niewiele rzeczy.

Teraz są skramy-edżajle i 10 razy się cała aplikacja zmieni zanim klient dostanie to co "niby" chce.

W tej chwili praca programisty to taka przechowalnia, żeby dać młodym kasę, a niewiele wymagać, bo sam biznes jest nieogarnięty. Młodzi muszą za coś żyć, a nie po to się uczyli żeby zarabiać grosze.

0

Ja zauważyłem inna jeszcze regule. Na mieście mówi się, ze Ci zdolniejsi ida do infry, a tym ktorym sie nie udalo klepia kod produkcyjny.

8

@pan_krewetek Jak coś takie czytam to mam wrażenie, że nie masz zielonego pojęcia o procesie developmentu i wytwarzania produktów.

  1. Dla mnie osobiście front jest bardziej skomplikowany bo:
  • pod względem logicznym nie ma roznicy czy to backend czy frontend
  • pod względem wzorców tak samo są tu i tu.
  • frontend poza warstwą wizualną posiada także warstwe nie wizualną o której też trzeba pamiętać.
  • frontend jest stanowy. Wydaję się pierdołą ? Napisz sobie backend tak, że przy każdym zatrzymaniu servera i jego uruchomeniu ponownie żeby odtworzył się stan procesów.
  • różnica w przeglądarkach
  • na backendzie rozwiązanie ma działać, na frontendzie działać, wyglądać.
  1. QA. W Polsce często jest rozróżnienie QA, od testera. O ile ten drugi to mniej więcej tak jak opisałeś. To ten 1 zazwyczaj jako jedyny musi przeczytać wszystkie dokumentacje ze zrozumieniem. We wszystkich projektach to QA był dla mnie źródłem wiedzy biznesowej i to jego się pytałem jak np taki proces ma wyglądać. Czemu nie PO ? Bo QA poza wiedzą domenową zna także stan faktyczny projektu.
    Jeżeli QA nie zna produktu to znaczy ze zaden z niego QA.

, często musi znać więcej informacji (aws, bazy, rzeczy dotyczące współbieżności)?

Takie z d**y argumenty. Front to nie tylko htmla. W dużych projektach frontendowych gdzie masz nasrane mikrofrontendów. Samo serwowanie strony, która może byc składana przez serwer lub dopiero w przeglądarce. deployment i ich komunikacj to całkiem duży kawałek wiedzy.

1

Jak już się programiści zabiorą za dyskusję, nawet na temat biznesu, racy, zarobków, to i tak szybko przejdą na tematy: jaki framework jest trudniejszy a jaki język programowania lepszy. :D

Ps
Tyko stawki ustalane przez biznes nie chcą się wpasować w różnice między i są zbliżone. Niegrzeczne stawki

9

Dla ludzi odpowiedzialnych za projekt kazda z tych rol jest tak samo wazna do jego realizacji. Nie chca potem miec w zespole takich wlasnie dyskusji jak tutaj - "No ale jak to, przeciez java > js. Jak on moze zarabiac wiecej" albo "Front jest prosty. Ja backendowiec powinienem zarabiac 10x tyle" albo "Ten pyton to jezyk dla dzieci. Dlaczego on tyle dostal?". Oni chca miec zgrany zespol skupiony na projekcie, a nie takich bezsensownych gadkach. Po drugie ich nie interesuje co jest trudniejsze i co o tym mysli typ piszacy dla nich kod. Oni dostali jakies wytyczne i maja dowiezc projekt do konca na czas. Poza tym co jest trudniejsze/latwiejsze jest czesto mocno subiektywne i ciezko byloby to wyrazic w pieniadzach zeby nikogo nie urazic.

2

Stawka w ogłoszeniu nie znaczy absolutnie nic. Nie wierz w to co tam jest. Zawsze możesz negocjować, stawkę, warunki, benefity, godziny.

Jeśli firma nie chce negocjować to pewnie nie chcesz tam pracować, potem będzie tylko gorzej.

Ostatnio miałem rozmowę gdzie w ogłoszeniu na popularnym portalu-dla-ludzi-którzy-wierzą-w-widełki-w-ogłoszeniach było 14k-18k.

Bez osłon powiedziałem na otwarcie że biedę 21k i oni się bez zająknięcia zgodzili.

Kto pierwszy poda stawkę w negocjacjach, przegrywa.

Dlatego stawka w ogłoszeniu o pracę musi być zaniżona.

A praca backendowca, frontendowca czy kogokolwiek innego nie jest porównywalna ze sobą. Każdy wycenia jak mu się podoba. Kupujesz albo spływasz.

Często nawet praca backendowca z innym backendowcem w tej samej firmie albo nawet tym samym projekcie nie jest porównywalna.

Gdyby była to by nie było w firmach tylu różnych managerów i tego typu zarządców niewolników, którzy muszą to wyceniać, oceniać, pospieszać albo trzymać w firmie za wszelką cenę.

0
MisiekNaLuzie napisał(a):

ich nie interesuje co jest trudniejsze i co o tym mysli typ piszacy dla nich kod. Oni dostali jakies wytyczne i maja dowiezc projekt do konca na czas.

Dlatego ONI mają HRy, a hry zadają "głupie, bezsensowne soft skillowe" pytania.
Programista to zawód społeczny, praca zespołowa. Sorry, taki mamy biznesowy klimat.

1

@Patryk Mieleszko: Swojej stawki nie ma co się wstydzić. Jeżeli oni nie mówią widełek to strzelać własną kwotę jest lepiej niż być odrzuconym za nie podanie oczekiwanego wynagrodzenia.

2

Pracowałem jako backend developer w java, android developer i teraz pracuje full stack na android i backend spring. Osobiście uważam że development androdia jest znacznie gorszy ze względu na kilka problemów:

  • każdy android działa trochę inaczej (pomimo tej samej wersji), chociaż nie wiem jak dobrze napiszesz aplikacje zawsze jakiś device się wywali i zwykle nie da się tego w prosty sposób odtworzyć.
  • Co chwile coś się zmienia na frontendach. Każdy nowy system androida wywala wszystko do górny nogami. np zmiana obsługi uprawnień w androidzie 6.0, ubijanie serwisów w tle (chyba android 8.0).
  • Musisz wspierać wiele wersji androida wiec masz dużo checkow na wersje systemu co wolno i w jaki sposób, musisz sie orientować co wolno na każdej wersji androida a co nie.
  • Ciągły rozwój bibliotek googlowych (jetpack itp)
  • Obsługa płatności mobilnych(google store), niedawno odcinali stara metode obsługi płatności, nie zrobiłeś ugrade w terminie no to masz problem.
  • rozwój języka kotlin na ktorym bazuje backend, corroutines które wypierają RxJava
  • zabezpieczenia platformowe(szyfrowania, certyfikaty, obsługa hardware key store), jedno wielkie pole minowe. Wystarczy poczytać o spongycastle vs bouncycastle biblioteka vs bouncycastle androidowe...
  • ciągłe zmiany w trendach np MVC -> MVP -> MVVM
  • problem z testami, owszem wytestujesz bazową logike unit testami, tylko problem jest w tym że na telefonie dochodzi ci interakcja z użytkownikiem w czasie rzeczywistym i ciągłe zmiany stanu aplikacji z zewnątrz(rozładowanie telefonu, rozmowa telefoniczna, aplikacja zrzucona w tło itp) po prostu kombinacji jest za dużo żeby dało się wszystko sprawdzić
  • W punkcie 2 pomaga trochę testowanie UI (np espresso) tylko pisanie tych testow jest bardzo kosztowne wiec nie pokryjesz wszystkiego no i zawsze na jakimś device sie moze i tak wywalić (dlatego wszędzie dostępne są różne farmy testowe)
  • problemy z różnymi rozmiarami ekranów, elementy sie rozwalaja, nie da sie w nie klikać itp)

W przypadku backendu jest o tyle lepiej że są dość mocno zbudowane standardy, które aż tak dynamicznie się nie zmieniają. Dochodzą tylko nowe elementy ale nie tak szybko jak na frontendach.

  • dość standardowa struktura CRUD, CQRS itp przy czym większość systemów to CRUD
  • większość systemów ma trójwarstwową strukturę
  • jest trochę gotowych frameworkow, ktore sporo kodu systematyzują i ogarniają za nas np obsługę bazy (np spring)
  • Większość kodu da się pokryć testami nie ma aż takich zależności jak na frontendzie, więc ciężko coś mocno zepsuć (no chyba że nie ma testów - YOLO;) )
  • Skalowanie robi się dość standardowo, albo zwiększamy moc maszyny, albo replikujemy i dodajemy LB ( jak korzystamy np z AWS to praktycznie dzieje się to automatycznie)
  • są gotowe rozwiązania w chmurze do trzymania plików np S3, i ich cachowania.
  • Zarządzanie sesją w systemach rozproszonych też jest już jest dość standardowe np JWT
  • Sporo narzędzi ułatwiających pracę np Kubernate, docker
  • wolniejszy development
  • komunikacja rozproszona? kafka
  • szybszy dostęp do danych? redis
  • zarządzanie transakcjami w systemach rozproszonych - saga
  • najtrudniejsza część to replikowanie danych miedzy serwisami tak żeby ze sobą za dużo nie gadały i były w miarę świeże. Tutaj są różne techniki np DDD. Generalnie jest to najtrudniejsza część no ale tym głównie zajmuje się tech lead/architekt systemu.
1

@pan_krewetek:

Gdy myślę o tym to mam przekonanie, że zmiany backendowca są trudniejsze, bo ten musi znać szerszy kontekst (by lepiej projektować), często musi znać więcej informacji (aws, bazy, rzeczy dotyczące współbieżności)?

Na frontendzie chyba jest jednak więcej buzzwordów, które trzeba znać. :P

Tutaj więcej rzeczy można skopać, i straty mogą być odczuwalne dla firmy.

Dlaczego więcej rzeczy można skopać na backendzie? Jeśli frontendowiec skopie swoją działkę i źle podepnie przyciski/prześle albo wyświetli jakieś dane, to też spowoduje odczuwalne straty. Tym bardziej QA jeśli tego wszystkiego nie wykryje.
A ponieważ jak widać co najmniej trzy rodzaje osób są zaangażowane w proces tworzenia oprogramowania, zaś powstanie odczuwalnych strat jest wynikiem błędów popełnionych przez co najmniej kilku z nich, to bez sensu byłoby różnicowanie zarobków w zależności od możliwości popełnienia błędu przez tylko jednego.

Taki dev nawet w B2B moim zdaniem ma na sobie większą odpowiedzialność.

Zależy jakie B2B. Jeśli mowa jest o dostarczeniu działającego produktu i się to kontrahentowi gwarantuje, to faktycznie jest odpowiedzialność. Jeśli zaś dostarcza się usługę pisania kodu albo jakieś moduły, które kontrahent sobie integruje w ramach swoich procesów, to odpowiedzialności nie ma żadnej.

2

@The Pontiff dotknął tematu i powodów, ale wnioski ma jakieś od drugiej strony... :)

The Pontiff napisał(a):
pan_krewetek napisał(a):

Nie potrafię odpowiedzieć sobie na jedno pytanie.

Czemu stawki frontendowca / backendowca / czy nawet QA w tak wielu ogłoszeniach są do siebie zbliżone?

[...] Jedynie stawki konsultantów są "rynkowe" tzn. faktycznie zależą od wydajności i wartości wykonywanej pracy [...]

No właśnie odpowiedź na pytanie @pan_krewetek jest taka, że stawki takie jakie są -- są rynkowe! Gdyby nie były rynkowe, ludzie (pracownicy) by grawitowali w stronę tych stanowisk, które mają lepszą stawkę (proporcjonalnie) -- ale widzimy, że tak nie jest: nasycenie backendu, frontendu i QA jest całkiem równe, więc wydaje się, że właśnie rynek podyktował takie stawki...

PS. A "rynkowe" stawki nie zależą od wydajności i wartości tylko od popytu i podaży na daną rzecz (tutaj: usługę).

3

Mi się podoba, że są równe, wszystkie wymagają podobnej pracy umysłowej jak nie identycznej.

Chodź jeśli jakiś kozak da radę zmniejszyć koszty chmurowe czy to lepszym algorytmem, to może dostać więcej od innych.
W końcu źle działająca chmura i skalująca się w nieskończoność może całą firmę do bankructwa doprowadzić albo po prostu zbędne koszty generować, które dało by się zminimalizować jakby ktoś znał się na algorytmach i nie marnowaniu cykli procesora gdy to nie jest konieczne.

Trochę jak w starym jak świat przykładzie gdzie z hamburgera usunięto jeden plasterek ogórka i to spowodowało bardzo duże oszczędności w skali roku i skali przedsiębiorstw franczyznianych, które wykonywały tą usługę.

1 użytkowników online, w tym zalogowanych: 0, gości: 1