Czy z wiekiem trudniej utrzymać się w branży?

Marcin Marcin napisał(a):

@piotrpo: projektowanie dużych aplikacji i rozwiazywanie w nich problemów wydajnościowych wymaga raczej sporej wiedzy i uważam że osoba niedoświadczona tego nie zrobi.

Oczywiście, tylko wracając do tematu wątku, kto ma większe doświadczenie, raczej ten, który pracuje w tym zawodzie kilkanaście lat dłużej.

somekind napisał(a):

Zmieniła się i to bardzo, m.in. z powodów, które sam wymieniasz, takich jak chmura.
Trochę inaczej budowało się monolity niż buduje mikroserwisy.

Trochę wpadliśmy w pułapkę skrajnych opinii nic się nie zmieniło/wszystko się zmieniło. Owszem IT się zmienia, zarówno w odniesieniu do wzorców architektonicznych, jak i chyba jeszcze bardziej w odniesieniu do sposobu pracy. Tylko mając doświadczenie dość prosto daje się podążać za tymi zmianami. Jeżeli ktoś np. rozumie jak działa baza danych, to event sourcing, czy saga stają się dość banalne do zrozumienia, bo to właściwie rozwiązanie tych samych problemów, w ten sam sposób, tylko na poziomie architektury systemu a nie w bebechach bazy danych.

Marcin Marcin napisał(a):

@The Pontiff:
Nie. Zdecydowanie nie.

Brakuje wiedzy z architektury oprogramowania, pisania testów, zarządzania jakością, wydajności (jak mówimy o C++) oraz zarządzania projektami aby zrobić je w czasie, zakresie i budżecie

Pomijam już mierną znajomość baz danych, zarządzania pamięci czy komunikacje sieciową (mówimy tutaj o napisanie własnej komunikacji socketowej).

To co wymieniasz to elementy doświadczenia, a nie nowe technologie których się trzeba przyuczać co pół roku. Raczej czym więcej lat w zawodzie, tym lepiej pod tym względem.

Zmienia się oczywiście paradygmat (kiedyś był monolit, potem EJB/spring, potem microservisy, teraz chmura), ale to też nie wymaga ciągłego doszkalania się żeby nie zostać z tyłu.

To z czym osobiście mam największy problem to założenie, że nagle developerzy mają być devopsami, umieć sobie postawić od zera środowisko z kafką, elastic search, jakąś bazą NoSQL itd. Staram się omijać takie projekty i taski, bo to nie moja działka.

Same koncepcje Kafki, ES, czy Cassandry są trywialne dla kogoś kto rozumie JMS i normalny SQL. Natomiast dla kogoś kto uczył się od razu z tutoriali do Springboota, przejście na kolejny pomysł na rynku może faktycznie wymagać douczania od zera, bo nie ogarnia całości zagadnienia.

The Pontiff napisał(a):

To z czym osobiście mam największy problem to założenie, że nagle developerzy mają być devopsami, umieć sobie postawić od zera środowisko z kafką, elastic search, jakąś bazą NoSQL itd. Staram się omijać takie projekty i taski, bo to nie moja działka.

Hm, jak zacząłem pracowac jako programista 10 lat temu to pracowałem w projekcie gdzie była tylko Java i PostgreSQL. Jak cos nie działało to logowałem się do serwera i przeglądałem logi w lessie. I to tyle co trzeba było wiedzieć z technologii

W tej chwili mam osobne logi z backedu, osobne logi ze Sparka (i sparka do ogarnainia), osobne logi z AirFlow (i AirFlow do ogarniania) i z frontendu tez powinny być osobne logi. Do tego jest jeszcze jakaś magiczna niszowa chmura, i druga chmura na którą będziemy migrować. Dalej jest PostgreSQL, ale jeszcze są jakieś NoSQLe do BigData z których importujemy i eksportujemy dane. Zrobiło się wiecej technologii, mimo że dalej pisze prawie wyłącznie CRUDy. Że nie opłaca się mieć od każdej technologii specjalist to na wszystkim muszę się znam po trochu (co może być frustrujące). No tylko od frontendu szczęśliwie mamy osobnego człowieka

UPDATE nie żalę się że jest trudniej. Po prostu o wiele więcej rzeczy jest do ogarnięcia niż 10 lat temu, ale często sa do ogarnięcia w podstawowym wymiarze.
Z drugiej strony 10 lat temu miałem sytuację że miałem się jako junior zintegrować z innym systemem po SOAP i pytam się Seniora jak to zrobić, a on na to też nie wiem, wczoraj zacząłem czytać dokumentacje i uruchamiać sample. W rezultacie za dużą pomocą nie był bo wyprzedzał mnie z wiedza tylko o jeden dzień

Ja zauważyłem że w zespołach gdzie Java Developerzy są odpowiedzialni za wszystko czyli DevOps, BA, pisanie kodu, to wtedy soft który tworzą jest niskiej jakości i zabugowany ostro.

Po prostu nie mają czasu na skupienie się na swoim rzemiośle. To tak jakym od chirurga wymagał przygotowania sali operacyjnej, znieczulenia, dokonania operacji, porobienia opatrunków i tak dalej. Wiadomo że sama operacja spadłaby na jakości przez to że nie mógłby się na niej skupić. Tak samo jest i w IT. Jest to po prostu cięcie kosztów przez firmę kosztem jakości. Managerzy nie są głupi i wiedza o tym.

@crx: Już poza tematem - zależy od stopnia skomplikowania domeny i tego co określiłeś jako DevOps. Tworząc serwis społecznościowy, raczej nie potrzebujesz osobnego business analyst, bo domena jest prosta i mało skomplikowana - każdy rozumie co ma być zrobione i po co. Główne ryzyko jakie istnieje, to że produkt będzie tym, co można łatwo zaimplementować, a nie tym czego oczekują użytkownicy. Jeżeli piszesz coś bardziej niszowego (czyli większość aplikacji biznesowych), to brak analiyka jest patologią i nie wynika z oszczędności, tylko z głupoty. Od programisty oczekuje się jakiejś tam znajomości domeny, bo z analitykiem trzeba się jakoś dogadać, w przeciwnym wypadku jeden będzie mówił np o pożyczkach, wnioskach itp. a drugi o tabelkach i endpointach
Co do zajmowania się infrastrukturą - podobnie, nie każdy projekt potrzebuje dedykowanego SRE.

Czy obawiacie się, że trudno będzie pracować w zawodzie do wieku emerytalnego?

to zależy ile chcesz zarabiać ;)

znam ludźmi którzy przechodzili / są blisko retirementu z IT - programiści / wdrożeniowcy

i się da, ale nie było to nawet blisko 20k :P

KamilAdam napisał(a):

U mnie nic się nie zmieniło odnośnie architektury. Jedyne co się zmieniło to to że nad jedną aplikacją pracuje tylko jeden zespół. Wcześniej było tak że całe piętro pracowało nad jednym monolitem i każdy zespół miał swój pakiet (name space) w ramach monolitu.

To ile ludzi pracuje i jak są podzieleni, to nie jest architektura.
Oczywiście można wziąć jakiś kobylasty monolit, wsadzić do dockera i wrzucić w chmurę, tylko nie nazywajmy tego architekturą.

BTW jak masz monolit stateless to też możesz go wsadzić do chmury i skalować. Pytanie filozoficzne : czym taki monolit stateless różni się od pojedynczego mikroserwisu? (oprócz wielkości oczywiście)?

Tym, że nie można skalować funkcji biznesowych niezależnie od siebie.
Tym, że nie można po prostu wymienić jednej części na napisaną w zupełnie innej technologii, bo wszystko jest od siebie zależne.

Poza tym architektura, to nie tylko sposób deploymentu. To też podział na warstwy - w monolitach zazwyczaj wygląda to nieco gorzej, bo albo jest ich za mało, albo za dużo (bo np. trzeba wprowadzać warstwy fizyczne, aby móc skalować).

piotrpo napisał(a):

Trochę wpadliśmy w pułapkę skrajnych opinii nic się nie zmieniło/wszystko się zmieniło. Owszem IT się zmienia, zarówno w odniesieniu do wzorców architektonicznych, jak i chyba jeszcze bardziej w odniesieniu do sposobu pracy. Tylko mając doświadczenie dość prosto daje się podążać za tymi zmianami. Jeżeli ktoś np. rozumie jak działa baza danych, to event sourcing, czy saga stają się dość banalne do zrozumienia, bo to właściwie rozwiązanie tych samych problemów, w ten sam sposób, tylko na poziomie architektury systemu a nie w bebechach bazy danych.

W takim razie 99,5% ludzi w IT nie rozumie jak działa baza danych.

@somekind: No nie wie. Myślę, nawet, że sporo programistów korzystających na co dzień z baz relacyjnych ma jedynie bardo powierzchowne pojęcie o SQL.

A co do waszej (z @KamilAdam) rozkminy, czym się różni monolit od mikroserwisów, to podpowiem hasło: "eventual consistency". I ogólnie przeniesienie odpowiedzialności za spójność danych z silnika baz danych na projektanta systemu. To akurat faktycznie jest spora zmiana.

piotrpo napisał(a):

A co do waszej (z @KamilAdam) rozkminy, czym się różni monolit od mikroserwisów, to podpowiem hasło: "eventual consistency". I ogólnie przeniesienie odpowiedzialności za spójność danych z silnika baz danych na projektanta systemu. To akurat faktycznie jest spora zmiana.

To jakieś problemy świata crudów. Nie każdy serwis potrzebuje bazy czy jakiejkolwiek innej formy utrwalania danych.

@somekind: No nie każdy mikroserwis potrzebuje warstwy danych, ale w zastosowaniach biznesowych już prawie każdy system ma potrzebę posiadania jakiegoś utrwalania danych.

Zależy jak zdefiniujesz system. :)

Ale ok, eksperci z 4p orzekli, że architektura się nie zmienia na przestrzeni lat, a mikroserwisy to właściwie tylko mniejsze monolity i w ogóle wszystko jest tak samo.

I jak tu się mam bać o utrzymanie w branży? :D

Marcin Marcin napisał(a):

49:25
rekruterzy bardzo często tego nie czają. Przykład, na live codingu wsadziłem w konstruktor metodę walidacyjną. Rekruter się tego doczepił jakby dając do zrozumienia, że to jest źle, bo konsturktor ma być głupi, a jak chcesz walidację to zrób metodę fabrykującą.
Taka porada jest chyba nawet w effective java. Ja się z tym generalnie zgadzam, ale jak kiedyś o to zapytałem na jakimś forum to doświadczeni programiści15k powiedzieli właśnie, że "to zależy" i nie ma w tym nic złego z automatu. W mojej pracy też tak się pisze kod.
A nawet jeśli to jest złe to przecież dostosuje się do zespołu i jak zobaczę, że piszą przez metody fabrykujące to będę robił tak samo.

trochę mnie to frustruje, że ci rekrutujący seniorzy to są bardzo często midzi zwykli i pojeżdżają niesłusznie mnie. Chcą bym się wstrzeliwał w klucz odpowiedziami a nie filozofował.

inny przykład: senior rekrutujący mówi mi, że test jednostkowy jest wtedy jak testujesz jedną klasę xD
inny senior rekrutujący powiedział coś w stylu, że test jednostkowy masz jak nie używasz kontekstu springa, a jak używasz o to już jest integracyjny xD
albo: pyta mnie chłop o komunikacje asynchroniczą i synchroniczną, w domyśle oczekiwał opowiedzenia o synchronicznej nieblokującej, a ja mu zaczynam filozować o tym ze moze byc async blokujaca i async nie blokująca
albo: pyta mnie jaki typ dam atrybutowi total (oczekiwał, że powiem BigDecimal), a przecież to nie jest takie oczywiste

@LitwinWileński: jest taka wybitna, wyborna, wypieszczona prezentacja @jarekr000000

Moi koledzy jeszcze bardziej polubili Jave EE po tym jak odziedziczyli te systemy po tych starych programistach (starych a nie seniorach) co się na nim uczyli Javy EE

@LitwinWileński:
Jak czytam te Twoje wszystkie zale (tak zale, bo widze juz nty post na temat "wstrzeliwania sie w klucz") o rekrutacjach to na mysl przychodza mi takie opcje:

1. Rekrutujesz sie do jakichs januszowych firm.
2. Sam przekrecasz celowo to co mowia albo nie sluchasz do konca i np

LitwinWileński napisał(a):

inny senior rekrutujący powiedział coś w stylu, że test jednostkowy masz jak nie używasz kontekstu springa, a jak używasz o to już jest integracyjny xD

Wyrwales ten kawalek z kontekstu, a senior zmierzal do czegos powoli.

Nie wiem, nie mam pojecia jak to sie dzieje. Expa mam kilkukrotnie wiecej niz Ty, rozmow rekrutacyjnych odbylem kilkadziesiat razy wiecej, a te takie zle rodem z Twoich opowiesci moglbym policzyc na palcach jednej reki.