Przerażający scope w pracy software dewelopera

Zakres wszystkich działek, w których musi się poruszać programista (backend developer w moim przypadku) to jest jakiś dramat. Mówię tu o małej firmie z własnym produktem, nie mówię z perspektywy korpo.

Kiedy się tego wszystkiego nauczyć? Jak Wy to robicie? Nie śpicie?
Cóż, nie jestem tytanem intelektu, ale podejrzewam, że w jakiejś średniej się mieszczę biorąc pod uwagę możliwości umysłowe programistów w Polsce.

1. Naucz się programować
2. Naucz się myślenia, mam tu na myśli algorytmikę i całą otoczkę
3. Naucz się tworzyć kod w praktyce
4. Ucz się masy narzędzi. Od tego może się coś w mózgu odkleić.. Jak to ogarnąć rozumiem to ja nie mam pojęcia. Muszę używać w pracy bazy danych, kolejek, konteneryzacja, CD/CI - Jenkins, AWS, Kubernetes, kontrola wersji, ogarniać infrastrukturę, żeby wiedzieć co i jak, analiza logów i debugowanie, znać w miarę OS, wiedza z zakresu sieci. Potem optymalizacja SQL, JVM, monitorowanie aplikacji, tutaj wchodzi ten ELK, Prometheus, Graphana. Żeby korzystać z tych narzędzi to trzeba znać inne narzędzia! Edytory tekstu, pluginy do edytorów różne etc.
5. Żeby tego nie było za mało... naucz się kurcze domeny produktu, w którym pracujesz - i tu w moim wypadku kolejny hardkor - codziennie muszę się uczyć, zmagać, próbować zrozumieć ten pierdyliard integracji, pierdyliard endpointów i kolejek.
6. To nie wszystko. Testy. Ciągle jest zbyt mało testów i trzeba to wszystko odpalać i testować wykonując requesty.
7. Dobre praktyki, wzorce projektowe etc...

A te wszystkie umiejętności i tak trzeba ciągle podtrzymywać i szlifować...

Ogólnie wpadłem w konsternację i nie mam pojęcia jak to ugryźć, w czym się specjalizować, a co odpuścić.

Podzielicie się może Waszym sposobem na zapanowanie nad tym? Dodam, że wpadłem na dodatek w błędne koło i chciałbym nauczyć się wszystkiego, a się nie da. Mam na półce ogrom kolorowych książek, pięknych i pachnących, ale jak mam się z nich uczyć, kiedy w wolnych chwilach próbuję rozgryźć jak działa jakaś mikrousługa, w której muszę jutro robić task, a nawet nie wiem co ona dobrze robi i jak działa.

Ba, do tego wszystkiego dochodzi jeszcze podnoszenie poziomu z j. angielskiego i umiejętności miękkich jak jakieś scrumy etc.

jak nie zarabiasz 20k do ręki to szukaj innej pracy

Ja robię mniej więcej tak:

• sporo czytam, słucham np. podcastów itp aby wiedzieć co w trawie piszczy
• od czasu do czasu ogarnę jakiś kurs na Udemy w temacie, który mnie zainteresuje
• w projektach, które prowadzę od czasu do czasu wciskam jakąś nowinkę
• pogodziłem się, że nic nie umiem - wystarczy mi, że orientuje się w mocnych/słabych stronach danej technologi i mam (często zresztą błędne) pojęcie kiedy daną rzecz warto zastosować
• jak już przychodzi ten wielki dzień, że coś trzeb zastosować to czytam dokumentację

Mam wrażenie, że podstawa dzisiaj to umiejętność szybkiego uczenia się i ogólny przegląd pola. Reszta to już kwestia zbierania doświadczenia.
Bardzo lubię się uczyć nowych rzeczy, więc dla mnie akurat to jest powód ciągłej radości, że jeszcze tyle jest do nauczenia ;-)

Gorzej jakbym dzisiaj miał zaczynać z zerowym poziomem wiedzy bo patrząc ile tematów trzeba ogarniać w dzisiejszym backendzie aby sobie nie strzelić w kolano można się lekko przytłoczyć.

Ogólnie pierwsza rada to wrzuć na luz, nie jest aż tak źle ;)

NeutrinoSpinZero napisał(a):

4. Ucz się masy narzędzi. Od tego może się coś w mózgu odkleić.. Jak to ogarnąć rozumiem to ja nie mam pojęcia. Muszę używać w pracy bazy danych, kolejek, konteneryzacja, CD/CI - Jenkins, AWS, Kubernetes, kontrola wersji, ogarniać infrastrukturę, żeby wiedzieć co i jak, analiza logów i debugowanie, znać w miarę OS, wiedza z zakresu sieci. Potem optymalizacja SQL, JVM, monitorowanie aplikacji, tutaj wchodzi ten ELK, Prometheus, Graphana. Żeby korzystać z tych narzędzi to trzeba znać inne narzędzia! Edytory tekstu, pluginy do edytorów różne etc.

To co opisałeś to z reguły nazywa się doświadczenie - z takiej np javy to zarówno junior i jak expert mogą wiedzieć co to equals/hashCode, ale właśnie tej całej otoczki się człowiek uczy po prostu pracując.

5. Żeby tego nie było za mało... naucz się kurcze domeny produktu, w którym pracujesz

Normalka, kwestia czasu - ja, patrząc po sobie, to zaczynam być dopiero produktywny i samodzielny jakoś po 3 miesiącach od wejścia w nową pracę. Rozmawiać sensownie z "biznesem" myślę że umiem po około pół roku.

6. To nie wszystko. Testy. Ciągle jest zbyt mało testów i trzeba to wszystko odpalać i testować wykonując requesty.

Żeby nie musieć testować ręcznie, właśnie po to są testy automatyczne :P

7. Dobre praktyki, wzorce projektowe etc...

Tutaj akurat 99% programistów narzeka, że ich projekt jest kupą g**na, więc na luzie

Ogólnie wpadłem w konsternację i nie mam pojęcia jak to ugryźć, w czym się specjalizować, a co odpuścić.

Najważniejszy jest rdzeń, czyli język programowania (Java / C# / JavaScript etc). Potem, na podobnym priorytecie dałbym główne frameworki które używasz (w Javie może to być np. Spring czy Hibernate). Potem kwestia infrastruktury - Jenkinsy, CI/CD, Cloudy itp. Potem takie pierdółki jak IDE, edytory tekstów, GITy, jak również wąskie specjalizacje takie jak optymalizacja JVM czy SQL.

Ba, do tego wszystkiego dochodzi jeszcze podnoszenie poziomu z j. angielskiego i umiejętności miękkich jak jakieś scrumy etc.

Co do Scruma to 2h teorii i 2 sprinty wystarczą, żeby się w nim odnajdywać. Podnoszenie j. angielskiego zawsze na propsie.

Podsumowując - Nie ma co się bać, będzie dobrze :D tylko najlepiej jakbyś sobie wyznaczył konkretnie np 3 cele do osiągnięcia w najbliższych kilku tygodniach / miesiącach. Mogę się podzielić jak ja to robię - do końca maja chcę zdać CKAD z Kubernetesa, a do końca roku egzamin z AWSa i GCP. Wmiędzyczasie mam 1,5h tygodniowo angielskiego, a do tego jeszcze dochodzi siłka 3x w tygodniu. Także powodzenia! :)

Zapisz sie na bootcamp to Cie w 3 miesiace naucza...

A na serio: jak zjesc slonia? Po kawalku. Rozpisz sobie drzewko technologii cos jak drzewko wynalazkow w grze Cywilizacja. I ucz sie po kolei krok po kroku, zrrozumienie przyjdzie z czasem. Albo nie. Zacznij od malych rzeczy i idz w strone wiekszych. I ucz sie, czytaj, probuj, eksperymentuj. NIE MA DROGI NA SKROTY.

NeutrinoSpinZero napisał(a):

Podzielicie się może Waszym sposobem na zapanowanie nad tym?

Pracuje się dla pieniędzy a nie z pasji i dla pasji.
Jak pracujesz dla pieniędzy to się nie wypalasz bo pracować trzeba. A z pasją bywa różnie.

Wypalisz się, to cię wymienią jak przepalony obwód.

@NeutrinoSpinZero: bez urazy - ale mam wrażenie że się trochę odklejasz od rzeczywistości :)

Dokładnie w tym samym stylu można opisać każdy zawód nie będący najprostszą pracą.
Bo taki Miecio budowlaniec:

1 Naucz się murować
2 Naucz się tynkować
3 Naucz się obu robić dobrze
4 ucz się obsługi masy narzędzi: wiertarki, pilarki, gilotyny, kątówki etc.
5 Naucz się stawiać domy, kible i warsztaty
6 zrób to tak żeby się nie zawaliło po deszczu.
7 Ma być ładnie

Czy Miecio siedzi po nocach i marudzi że za dużo?
Nie, zrobi swoje i śpi nawalony w kanciapie :)

Płacą nam za pracę intelektualną, nie za to żeby wiedzieć wszystko.
Ułóż priorytety, ucz się czego potrzebujesz i jedź do przod.
Najważniejsze to pamiętać że ten burdel nie jest Twój, Ty tu tylko sprzątasz ;)

Ucz się masy narzędzi. Od tego może się coś w mózgu odkleić.. Jak to ogarnąć rozumiem to ja nie mam pojęcia. Muszę używać w pracy bazy danych, kolejek, konteneryzacja, CD/CI - Jenkins, AWS, Kubernetes, kontrola wersji, ogarniać infrastrukturę, żeby wiedzieć co i jak, analiza logów i debugowanie, znać w miarę OS, wiedza z zakresu sieci. Potem optymalizacja SQL, JVM, monitorowanie aplikacji, tutaj wchodzi ten ELK, Prometheus, Graphana. Żeby korzystać z tych narzędzi to trzeba znać inne narzędzia! Edytory tekstu, pluginy do edytorów różne etc.

A ile z nich faktycznie musisz bardzo dobrze ogarniać, a ile po łebkach, a jak coś nie idzie to do dokumentacji i stacka?

Przejdź do korpo - zakres obowiązków /5, płaca x2

Jesteśmy - ja jestem - zwykłymi wyrobnikami którzy niczego nie wymyślili i nie wymyślą, nic nie stworzą, nie będzie po nas śladu w historii, dzieciom przekażemy tylko spłacone mieszkanie albo końcówkę kredytu hipotecznego.
Nie wymaga się od nas nic ponad wiedzę ze "szkół" i głowy na karku żeby poszukać gotowca na StackOverflow

Niewielki procent społeczeństw tworzy nowe rzeczy, naukę, rozwija biznesy.
Oni nie mogą skorzystać z możliwości wybrania najwyżej punktowanych odpowiedzi na StackOverflow.
Ta Elita rzeczywiście Tworzy.

Wyrobnicy tylko pracują. Każdy z nas, wyrobników, na takim stanowisku i poziomie na jakim da radę.

Nie daje rady? Wypalił się po 3 latach? Jego miejsce zastąpią inni wyrobnicy.

Demonizujesz.

Jednak za coś dostaje się naście czy dzieści a może i dziesiąt tysięcy. Nikt nie powiedział, że programowanie jest proste. No może poza ludźmi co sprzedają bootcampy. Jedno mnie martwi

kiedy w wolnych chwilach próbuję rozgryźć jak działa jakaś mikrousługa, w której muszę jutro robić task, a nawet nie wiem co ona dobrze robi i jak działa

Mam nadzieję, że to są wolne chwile w ramach godzin pracy, lub jest to Twój własny biznes przynoszący wymierne korzyści. Inaczej po prostu tak nie rób. Nigdy nie wychodzi to na dobre, nawet jak Tobie się tak wydaje.

Doleję trochę oliwy do ognia i dodam, że programowanie bywa naprawdę męczące. Konieczność ciągłego doszkalania się może w końcu zdołować.

Uczysz się, powili się rozwijasz, przerzucają Cię do innego projektu gdzie przychodzi sobie studenciak i naparza coś w technologii, o której nie masz zielonego pojęcia. I co teraz? Znów trzeba się uczyć czegoś nowego od zera i gonić tego studenciaka, który przychodzi ze świeżą głową, naładowaną pomysłami, z których jesteś oczywiście "niesamowicie wręcz zadowolony".

A Ty? Ty masz rodzinę, dzieci, mało czasu i coraz więcej rzeczy w nosie, a tu trzeba uczyć się kolejnych bzdur, by choć trochę dogonić tego studenciaka. A przecież kiedyś to była dla Ciebie pasja, hobby czy nawet w jakimś stopniu sens życia.

Ktoś napisze, że to normalny zawód, jak każdy inny, Moim zdaniem to nieprawda. Ilość czasu jaki trzeba poświęcić by się utrzymać dla wielu osób może być barierą nie do przebicia. A tu trzeba jeszcze zrozumieć biznes, który należy zaprogramować. Stolarz jest stolarzem, mechanik mechanikiem, hydraulik hydraulikiem, a programista? Programista wielokroć jest osobą, którą w ogóle nie ma ochoty być. Jest księgowym, kolejarzem, biurwą... Musi być kimś, komu należy w danym momencie zaimplementować jakąś funkcjonalność.

Ktoś mnie tutaj niedawno zapytał dlaczego nie nadaję się do tego zawodu. Odpowiem na to pytanie: wielokroć nie potrafiłem zrozumieć biznesu, który musiałem zaprogramować. Nie potrafiłem być finansistą czy właścicielem sklepu internetowego albo analitykiem w takiej czy owakiej dziedzinie. To jest podstawowa różnica w stosunku do zawodów, tak hucznie tutaj uważanych za "zwykłe".

Nie każdy może zostać programistą. Jeśli ktoś twierdzi inaczej to nie wie co mowi.

1. Nie musisz się uczyć się tego w domu. Nikt nie powinien wymagać tego od Ciebie.

2. Jeśli pracodawca Cię zatrudnił i przydziela Ci zadania z różnych obszarów w których czujesz się słabo to klarownie mów, że nie wszystko jest Ci znane i że potrzebujesz więcej czasu. Nie rób z siebie na siłę bohatera ani męczęnnika tylko mów jasno i konkretnie o ograniczeniach. Natomiast jak masz jakiś techniczny problem, który stresuje to doczytuj, czas jaki jesteś w pracy bez obaw wykorzystuj na rozwój. W ten sposób nie okradasz pracodawcy, a rozwiązujesz w jego interesie konkretny problem.

3. Doceń chociaż o 1% tą sytuację i rozłóż ją w czasie. Zobacz, jak będziesz bardzo dobry w programowaniu, testach i całej reszcie to znudzi Ci się klepanie w pracy, bo 80-90% będzie nudne i powtarzalne i często słabo zrobione, nie tak wiele wtedy trzeba, aby się wypalić.

w czym się specjalizować

4. Pracując w firmie specjalizuj się rozwiązywaniu problemów, jedna technologia odejdzie, druga przyjdzie - to nie jest ważne. Lepiej jest się skupić na problemach jakie uderzają w zespół, produkt, firmę w ten sposób łatwiej zrozumiesz branżę, łatwiej dogadasz się z ludźmi i praktycznie wszystko co robisz w pracy nabierze większego sensu.

@Na zawsze nikt: Dlatego kluczowym jest, żeby uczyć się jak się szybko uczyć, oraz jak poruszać się w nieznanej technologii i z marszu rozwijać produkt, czy szukać błędów. Uczyć się rzeczy niezależnych od technologii. Technologii jakich używałem, lub używam jest kilkadziesiąt. Żadnej nie znam w 100%, i nie jestem otrzaskany w każdej implementacji i kruczku. Owszem, jak jest problem z wydajnością, wyciekami w aplikacji, błędami - wtedy zgłębia się pewien wycinek technologii i zdobywa się wiedze ekspercką - ale w wąskim wycinku. Z doświadczeniem, zdobywasz coraz więcej takich eksperckich wycinków w różnych technologiach. Nowych technologii uczę się tylko w dwóch przypadkach - potrzebuję jej do projektu - który akurat rozwijam, będę rozwijał lub chcę zacząć rozwijać, drugi przypadek - bo daje mi to rozrywkę. Nigdy nie uczę się czegoś na zapas, bo być może będę chciał w tym coś rozwinąć i wtedy wypadnę z obiegu bo nie będę potrafił. Moi współpracownicy już nie pytają, czy potrafię jakąś technologię, tylko rzucają problem i pytają kiedy możemy usiąść do rozwiązania, wycen lub spodziewać się realizacji. Nie chcę tutaj kreować się na jakiegoś Eugeniusza - większość specjalistów z dużym stażem ma takie podejście. Co do tego, że programowanie jest męczące - zgadzam się w 100%.

NeutrinoSpinZero napisał(a):

Zakres wszystkich działek, w których musi się poruszać programista (backend developer w moim przypadku) to jest jakiś dramat. Mówię tu o małej firmie z własnym produktem, nie mówię z perspektywy korpo.

Jeśli chodzi o manie vs niemanie własnego produktu, korpo też mają swoje produkty, a mniejsze czasami nie mają żadnego, tylko "robią rzeczy" na zlecenie, outsourcing itp. Czasami jedno korpo ma nawet więcej, niż jeden produkt. To tak gwoli ścisłości :P

Kiedy się tego wszystkiego nauczyć? Jak Wy to robicie? Nie śpicie?

Uczę się w godzinach pracy, często kilka godzin czy dni żywcem siedzę, czytam dokumentację, przekopuję się przez kod źródłowy i robię notatki. Często na tym wręcz polega zadanie / spike, żeby wziąć, przeorać internety, dokumentacje, źródła, poczytać, pokombinować, zrobić PoC i wyciągnąć z tego wnioski dla zespołu do ponownego wykorzystania w następnych zadaniach. W sumie w zeszłym roku chyba większość czasu pracy spędziłem na czymś takim - doszkalaniu się w godzinach pracy (jak nie było za bardzo nic do roboty) i robieniu spajków (jak już było coś do roboty). Zostałem nawet okrzyknięty Confluence Developerem...

Cóż, nie jestem tytanem intelektu, ale podejrzewam, że w jakiejś średniej się mieszczę biorąc pod uwagę możliwości umysłowe programistów w Polsce.

Właśnie nie wprost napisałeś, że programiści w Polsce nie należą do tytanów intelektu - uważaj, wg. ankiet StackOverflow chyba ok. 70% programistów na świecie uważało się za ponadprzeciętnych ;)

1. Naucz się programować

Chyba nie ma sensu uwzględniać tego w wyliczance ;)

2. Naucz się myślenia, mam tu na myśli algorytmikę i całą otoczkę

Ile bym dał, żeby w pracy mieć do czynienia z algorytmiką a nie zwykłym klepaniem...

3. Naucz się tworzyć kod w praktyce

Nauczysz się zawsze, pytanie JAK się nauczysz. W pierwszej firmie, w której pracowałem komentowało się kod na zapas mimo używania gita - tak ludzie byli nauczeni.

4. Ucz się masy narzędzi. Od tego może się coś w mózgu odkleić.. Jak to ogarnąć rozumiem to ja nie mam pojęcia. Muszę używać w pracy bazy danych, kolejek, konteneryzacja, CD/CI - Jenkins, AWS, Kubernetes, kontrola wersji, ogarniać infrastrukturę, żeby wiedzieć co i jak, analiza logów i debugowanie, znać w miarę OS, wiedza z zakresu sieci. Potem optymalizacja SQL, JVM, monitorowanie aplikacji, tutaj wchodzi ten ELK, Prometheus, Graphana Grafana. Żeby korzystać z tych narzędzi to trzeba znać inne narzędzia! Edytory tekstu, pluginy do edytorów różne etc.

To przychodzi z czasem. Sporo z tych narzędzi tak naprawdę da się używać "na czuja" (choć znam takich, którzy nie klikną sami Run build żeby odpalić build dopóki im nie powiesz, że Run build uruchamia build...) i dopiero z czasem poznawać je lepiej. Choć oczywiście zaraz przyleci taki, wg. którego jak nie znasz na pamięć skrótów klawiszowych z jego ulubionego IDE, albo wolisz oglądać sobie zasoby przez dashboard k8s / Octant zamiast tłuc z pamięci CLI k8s to powinieneś dostać dyscyplinarkę.

5. Żeby tego nie było za mało... naucz się kurcze domeny produktu, w którym pracujesz - i tu w moim wypadku kolejny hardkor - codziennie muszę się uczyć, zmagać, próbować zrozumieć ten pierdyliard integracji, pierdyliard endpointów i kolejek.

Jak produkt jest duży, domena złożona itd. to bardzo pomagają wstępne szkolenia z produktu i wdrażające w domenę. Niektóre firmy produktowe to robią.

Jak nie ma albo jak szkolenia nie wystarczą, to męcz o dokumentację i/lub notuj sobie.

6. To nie wszystko. Testy. Ciągle jest zbyt mało testów i trzeba to wszystko odpalać i testować wykonując requesty.

Testów zawsze jest zbyt mało i są niewystarczająco dobre :(

7. Dobre praktyki, wzorce projektowe etc...

Wszystko przychodzi z czasem, a niektórzy żyją i bez tego (patrz moja odpowiedź na p.3)

A te wszystkie umiejętności i tak trzeba ciągle podtrzymywać i szlifować...

Są rzeczy, których się nie zapomina, chyba że metodą uczenia jest kucie na blachę API biblioteki, serwisu etc. - ale wtedy problem nie leży w samym zapominaniu :P

Wiem, że szczegółów nie spamiętam, a jak spamiętam to zapomnę lub się zdezaktualizują. Jeśli je zapamiętuję i pamiętam nawet po latach, to czystym przypadkiem. Dopóki mniej-więcej pamiętam, do czego służyło X, lub jaki problem rozwiązywało Y to jest dobrze - będę wiedział, czego szukać w dokumentacji i będę miał aktualne szczegóły na wyciągnięcie ręki.

Ogólnie wpadłem w konsternację i nie mam pojęcia jak to ugryźć, w czym się specjalizować, a co odpuścić.

Podzielicie się może Waszym sposobem na zapanowanie nad tym? Dodam, że wpadłem na dodatek w błędne koło i chciałbym nauczyć się wszystkiego, a się nie da. Mam na półce ogrom kolorowych książek, pięknych i pachnących, ale jak mam się z nich uczyć, kiedy w wolnych chwilach próbuję rozgryźć jak działa jakaś mikrousługa, w której muszę jutro robić task, a nawet nie wiem co ona dobrze robi i jak działa.

Ba, do tego wszystkiego dochodzi jeszcze podnoszenie poziomu z j. angielskiego i umiejętności miękkich jak jakieś scrumy etc.

Zostanę zjedzony, że nie jestem tró programistą pasjonatem (ok, nie jestem - zasadniczo nie wiem, czym tu się pasjonować będąc code monkey) - sposób na zapanowanie nad tym jest taki, że praca jest w pracy, a po pracy nie ma pracy tylko czas wolny. W pracy jest czas na robienie zadań do pracy, doszkalanie się do pracy. Po pracy jest czas na wszystko inne, w tym naukę - ale tego, czego mam ochotę się uczyć. Jeśli ktoś ma mnie zwolnić za to, że po godzinach gram w gry albo wolę się bawić nie wiem, sieciami neuronowymi, niż doszkalać z Cassandry bo akurat architekt pryncypał ma pomysła - cóż...

A najgorsze jest to, że im więcej wiesz tym czujesz, że więcej nie wiesz.

Programuję dla pieniędzy
Pracuję - w pracy programuję. Lubię tę robotę. Poprzedni projekt też lubiłem.
Kilka dni wolnego czasu? Poza komputerem oczywiście! Świat jest piękny, we dwoje jeszcze piękniejszy.

Programuję dla pasji
W pracy to szósty mój projekt i w każdym to samo guano, mam już dość! Myślę tylko o tym żeby w końcu cały wieczór przesiedzieć w domu przed komputerem i programować do późnej nocy to co sam chcę.
Kilka dni wolnego czasu? Z komputerem oczywiście! Będę pisać swój nowy prywatny projekt.

Trzeba odróżnić niektóre stanowiska, bo tu chyba niektórzy mylą pojęcia:

1. programista - zajmuje się tworzeniem kodu (100% czasu między kawami i toaletą)
2. software developer - rozwija produkt - tworzy oprogramowanie, zbiera wymagania, testuje, projektuje, dokumentuje
3. software engineer - człowiek orkiestra, coś tam skrobnie, tu załata, tam przeklika tickety, puści upgrejd i zrobi backup

Do tego są jeszcze działki poboczne, które wielu Januszów Biznesu chciało by zintegrować z powyższymi:

1. tester
2. projektant UX
3. administrator systemu
4. administrator chmury systemów
5. administrator bazy danych
6. performance engineer
7. meeting facilitator
8. scrum master
9. tech lead
10. sales representative
11. analityk wymagań
12. grafik

I teraz pytanie: ile z tych stanowisk z drugiej sekcji potrafisz zastąpić? Na ile jesteś zajebisty? I kiedy nastąpi załamanie nerwowe?

1, 2, 3 i 7 to jest jeden punkt.

Co do narzędzi, to nie ma sensu. Zawsze znajdzie się jakiś junior, który je umie i jeszcze jest szczęśliwy z tego powodu. Za 3 lata i tak będą inne, więc nieuczenie się czegoś, co przemija jest lepszą inwestycją. A te inne narzędzia mogą obsługiwać nowi juniorzy.

Domena - no czasem trzeba, czasem nie trzeba, generalnie chłonie się podczas pracy. A jeśli ktoś tego bardzo wymaga, to powinien zapewnić szkolenia.

Wygląda jak typowy scope na backendzie :)

Tak mnie zastanowila w sumie jedna rzecz, czego wy się potrzebujecie uczyc o scrum/agile? Ja nie widzę absolutnie żadnej potrzeby by się uczycyna ten temat a to jak funkcjonuja sprinty itp ogarnąłem po pierwszym 30min spotkaniu w pracy xd wgl uważam że Ci cali Scrum Masterzy to takie nie potrzebne piąte koło u wozu które jakby zniknęlo to nikt by tego nie zauważył

Myślę że to zależy dużo od profesji jaką posiadasz, bo to co robi Java Developer w jednej firmie często nie jest 1:1 co robi w drugiej firmie. Chodzi tutaj o umiejętności, zasób wiedzy o technologiach. Jak ktoś wspomniał w jednej firmie możesz być wymiataczem bo znasz Springa a w innej będziesz dupa wołowa bo używają całkiem innego ekosystemu. To są właśnie te bolączki o których mówisz. Jeżeli chcesz by doświadczenie w jednej pracy często pokrywało się 1:1 z tym co będziesz robić w kolejnej firmie to musisz wejść w niszę, czyli zostać specjalista np. z Tibco, SAP, Dell Boomi czy specjalista AWS, GCP... jest tego pelno. Software Developer jak mi to mówił manager to słowo wytrych aby taki gość musiał robić wszystko, co w poprzednim przypadku już byłoby nadużyciem, gdyby kogoś zatrudnili jako specjalistę SAP a kazali mu pisać XML'e, czy jak to pisałeś konfigurować pipeline na Jenkins. Myślę że wiesz o co mi chodzi.

To wymaga pracy i czasu. Praca software developera nie jest latwa. Czesto zadania nie sa powtarzalne. Czasem sa bugi, ktore probujesz rozwiazac, ale nie da sie ich rozwiazac. Nie jest to praca, tak jak niektorzy tutaj pisza w umiejetnosciach - po kilku latach programowania, ze znaja jezyk np. na 3/3. Ostatnio spadlo na mnie zadanie goscia, ktory programuje 18 lat i go nie rozwiazal. Mysle, ze po 20 latach pracy mozna powiedziec, ze sie duzo umie. A ci co sie zniechecaja na poczatku, to niech nie mysla, ze umiejetnosci przychodza latwo do zostania dobrym developerem. Na poczatku, duzo czasu niestety trzeba poswiecac nawet poza praca na nauke.

To ogólny problem dotyczący programistów.
Ja projektuję elektronikę z uwzględnieniem EMC/EMI sprzęt w klasie "safety", projektuję PCB też z uwzględnieniem EMC/EMI, piszę do tego soft C,C++,asm
również z uwzględnieniem "safety" I mało która firma chce zapłacić odpowiednio a jeszcze prócz standardowych SVN/GIT/Mantis/Linuxa i paru pomniejszych duperel dodatkowo chcą znajomości Pythona, programowania Interfejsów graficznych i cholera wie czego jeszcze. Muszę znać od cholery i ciut różnych protokołów, RTOS-y, potrafić skomunikować mikrokontroler z softem na Linux-ie pobieranie/ładowanie danych do DB klecenie czegoś w HTML aby się urządzenie potrafiło zgłosić w przeglądarce, znać różne śmiecia związane z wykrywaniem uszkodzeń np silników etc. it. ....................... Na dzień dobry wołają perfect angielski w mowie i piśmie Jira i insze takie nalazki. W sumie to jak w dowcipie "członkini koła gospodyń wiejskich" i potrafią czasem napisać w ogłoszeniu 10k brutto (o tych niższych nie wspominam gdyż są po prostu niepoważne). Po prostu śmieszne. Dlatego zakładam swoją firmę.

Aha...

Zapominałęm. Ostatni pomysł to napisać apkę na Androida do sterowania tymi urządzeniami.
Więc dochodzi Java..........

Takie rzeczy jak piszesz przychodzą z doświadczeniem + wrodzoną cechą bycia w miarę ogarniętym. Oczywiscie jezeli na developerze wszystkie te aspekty spoczywaja o ktorych piszesz to jest cos nie tak, natomiast jesli jako zespół kilku osób to ogarniacie razem i sie tym dzielicie to moze byc to bardzo ciekawy projekt.

Są to ciekawe projekty ale głowa nie śmietnik. Ile można znać "na blachę". Jednak niezależnie od wiedzy nie idą za tym zarobki. Osobiście żałuję, iż więcej nie położyłem nacisku na angielski. Ci co znali go na blachę to przestała ich trzymać w Polsce "grawitacja" i wybyli a teraz pracują za pieniądze i nie robią za "człowieka orkiestrę" jak pracowałem w "Diehl control" to zajmowałem się tylko programowaniem a od hardware byli inni. w "Scheidt und Bachmann" również.... a teraz kierownikuję i jeszcze muszę wszystko znać i wszystko pisać. W GB bym rocznie zarabiał pewnie z 60..80k na takim stanowisku i z taką wiedzą.

Te podpunkty brzmią jakby pisała je osoba, którą boli.
Boli, ale to dobrze, bo znaczy, ze cos rośnie.

W programowaniu nie zmieniło się nic od lat 80.
Jak nauczysz się dobrze paradygmatów to już idzie z górki. Prawda jest taka, ze metodologii się pojawia bardzo mało, nowe narzędzie to nie jest nowa metodologia.

Frameworki to narzędzia. Nie można zachorować na chorobę frameworkowa, bo ma się poważne dolegliwości. Co więcej, jeżeli masz architekturę zależną od frameworka to źle. No chyba, ze to zwykły transacion script.

Duzo rzeczy, które napisałeś wynikają z podejścia do tworzenia systemów rozproszonych - tu jest faktycznie inna i nowa mechanika. Np. zwykła transakcja nie starcza, trzeba ratować się sagami, cały czas rozmawiać z biznesem by programowac poprawne workflow itd.. Mikroserwisy nadały nowy kierunek i często są powodem tych wszystkich nowych narzędzi.

W większych firmach od CI/CD jest devOps. Rzadko kiedy trzeba być specem w tym. Mniej więcej masz wiedzieć jak to działa mechanicznie. Stawiać dockery, ogarniać workflow git-jenkins itd.. Pracujesz w małej firmie i masz te rzeczy na sobie? Wykorzystaj je.

Co do ciągłej nauki. Babcia mojej dziewczyny ma 98 lat, jest profesorem, codziennie czegoś się uczy, rozmawia się z nią jakby była w podobnego pokolenia do twojego. Za to moja babcia 80 lat, nigdy nie skupiała sie na nauce, ciężko się z nią dogadać, obecnego świata nie rozumie, żyje swoim własnym.

Wiem, ze jak ktos ma dzieci, rodzine itd to ciezko go zachęcić do nauki, ale fakt jest taki, ze mózg dzięki nauce ciagle się rozwija. Stymulujesz go. Wiec jest to plus dla ciebie bo idziesz ze swiatem.

Odkryłeś ocean. Teraz płyń tam gdzie chcesz być.

Zastanów co cię interesuje najbardziej i tego się ucz. Ewentualnie jeśli widzisz duże braki w czymś co Ci przeszkadza na co dzień albo w znalezieniu nowej pracy - to poucz się tego. I wróć do nauki i skupiania się na tych rzeczach które Cię interesują.
Np ja zawsze byłem bardziej zainteresowany backendem niż frontem, i mimo, że stawia mnie to w sytuacji że o froncie mniej wiem, to nie próbuję na siłę się tego uczyć jeśli nie muszę. Wolałem się pouczyć o testach, architekturze takiej czy siakiej niż uczyć Vue czy Reacta. Jak trzeba by było do pracy albo do zmiany, to wziął bym się za to, ale jeśli nie to wolę się skupiać na innych rzeczach.

W mojej działce ciągle się coś nowego pojawia gdyż wynika z badań fizycznych. np wykrywanie zwarć zwojowych maszyn energetycznych w trakcie pracy. etc itp. samo kodowanie to mało. Przykładowo idiotoodporna klawiatura odbiciowa której nie oślepia światło słoneczne do zastosowań w przestrzeni publicznej(moje prywatne opracowanie). Ostatnio zrobiłem taki "dyskotekowy kolorofon z użyciem jednego mikrokontrolera i trzech tranzystorów. oczywiście DSP bo bez tego się już elektronika nie obchodzi. a działa na małym Atmelku. To nie jest w każdym razie tylko kodzenie. Trzeba badać jak się zachowuje fizyczny ukłąd w środowisu i dostosowywać odpowiednio oprogramowanie i modyfikować sprzęt. w klawiaturze odbiciowej zastosowałem techniki używane w radarach wojskowych.