Mam dość legacy korpo kobył i bycia szeregowym devem - plan na wyniesienie swojej kariery na kolejny poziom.

Dobra, słuchajcie. Mam 7+ expa jako Java dev, jednak zdecydowana większość tego expa to wielkie, skomplikowane domenowo, legacy korpokobyły, gdzie był zawsze duży podział obowiązków.
Ja, będąc Java devem, robiłem tylko Java kody. I to z reguły Java 8, nawet nie 11 :P Zero devops, zero architektury, zero projektowania rozwiązań, zero nowy sexy buzzwordów, zero ogarniania DB.
Tylko kod Java, a cała reszta była zawsze oddelegowywana do innych specjalistów. Używałem w tym czasie oczywiście przeróżnych Java frameworków, mniej lub bardziej magicznych, jednak zawsze w gotowych projektach, więc nigdy sam niczego od zera nie stawiałem i tylko dokładałem kolejne klocki, często bez możliwości rozmawiania o rozwiązaniach, czy nawet sugerowania, że można lepiej.
Ciężko było o większą odpowiedzialność i zaufanie, bo zawsze w tych firmach jest grono osób, które bardzo pilnują swojego garnuszka i nie chcą się nim dzielić. Jestem całkiem tym zmęczony i chciałbym zacząć na świeżo, z mniejszą szansą na trafienie do korpokobyły z 60-letnimi (to jest ok) zabetonowanymi (to nie jest ok) Władkami :/

W aktualnym projekcie, który jest baaaaardzo powolny, mam sporo czasu. Postanowiłem się porządnie rozwinąć na własną rękę i zrobiłem sobie małą roadmapę/TODO listę. I w tym miejscu wchodzicie wy, pomagając mi ułożyć plan działania.

Znam TDD, koncepty używane w Javie, jej ekosystem, clean code i design patterny itd., ale nie chcę już Javy i przede wszystkim chcę się rozwinąć jako software engineer, a nie polegać na konkretnym narzędziu (tj. język programowania)

1. System design
   • zacząłem czytać System Design Interview – An insider's guide by Alex Xu
   • kolejne jest Designing Data-Intensive Applications Martin Kleppmann
   • coś jeszcze co byście polecali? Podobno spoko jest Grokking The System Design, ale nie wiem czy nie będzie się powielać z poprzednimi zbyt mocno?
2. Algorytmy
   • Grokking Algorithms: An Illustrated Guide Aditya Bhargava i myślę że to wystarczy. Interview raczej nie są algoritm-heavy :) ale może jakaś lepsza alternatywa?
3. Architektura/design aplikacji
   • Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans
   • przyznam, że tutaj średnio wiem co jeszcze byłoby pożądane
4. DevOps/konteneryzacja/cloud
   • tutaj zaczynają się schody. Od czego w ogóle zacząć? Docker, Kubernetes, Vagrant, Openshift, miliony dostawców rozwiązań chmurowych. Kompletnie jestem zagubiony :D bardzo chętnie przyjmę wszelkie wskazówki i źródła
5. Co innego?
   • Czy przychodzi wam na myśl coś innego, co powinienem ogarnąć? Coś o bazach danych, networkingu, bezpieczeństwie? Miękkie skille?
6. Last but no the least, chcę zmienić technologię na Go, ale tutaj sobie radzę i plan działania jest taki, intensywnie realizowany i myślę, że możemy pominąć ten krok, chyba, że ktoś ma protipy:
   • The Go Programming Language Brain Kernighan,
   • Concurrency in Go Katherine Cox-Buday,
   • Effective Go Inanc Gumus
   • dużo kodu i pobocznych projektów :)

Plan mam taki, żeby resztę 2023 spędzić na nauce i przygotowywaniu się do potencjalnych interview. Pod koniec roku zacząć aplikować i 2024 rozpocząć w nowej firmie, w której nie będę szambonurkiem bez odpowiedzialności.

Preferuję źródła pisane, bez polskich kołczówprogramowania najlepiej się uczę :)

Dziękuję i liczę na waszą pomoc!

throwaway2137 napisał(a):

Ja, będąc Java devem, robiłem tylko Java kody. I to z reguły Java 8, nawet nie 11 :P Zero devops, zero architektury, zero projektowania rozwiązań, zero nowy sexy buzzwordów, zero ogarniania DB. Tylko kod Java, a cała reszta była zawsze oddelegowywana do innych specjalistów.

Ja też Java Dev i wydaje mi się że to kwestia firmy i projektu. U mnie od około 3 lat robię to samo mniej więcej co poniżej opisałem:

1. Stawianie infry w Pulumi/Terraform/Cloud Formation
2. Robienie pipelinów Azure/AWS itd
3. OpenShift lub Kubernetes
4. Zbieranie wymagań podczas refinementów, opisywanie tasków, dbanie o backlog na Jirze (rzadko kiedy pracowałem z prawdziwym biznes analitykiem więc te rzeczy sam robiłem zazwyczaj)
5. Implementacja w Javie funkcjonalności / featerów
6. Faza QA/Compliance/Cloud Security i tym podobne rzeczy
7. Wdrożenie na poszczególne środowiska

Jeżeli chodzi o język Go to ja miałem 2 oferty pracy w tamtym roku, że chcieli mnie przyjąć jako Javowca, ale abym się doszkalał i robi w Go. Także może tędy droga? Są firmy które takie coś oferują.

@MarioBros33: tak, jest to zdecydowanie kwestia firmy i projektu. Jednak mi, mając mało sexy słów kluczowych z których korzystam w pracy, ciężko otrzymać zapro na interview, gdzie w ogłoszeniu stoi AWS, Docker, Kubernetes, mikroserwisy i co tam jeszcze. A w moim CV "Java 8, Spring, Gradle" :P dlatego potrzebuję się doszkolić ze wszystkiego wokół. Wiem, że wiele firm bierze na Go bez znajomości języka, ale właśnie wymagają kwestii wokół na których chcę się skupić i sam język programowania to tutaj mniejszość.

Będę również pisał list motywacyjny, czego nigdy nie zrobiłem. Ale jest to jedna z raczej niewielu opcji, żeby przebić się przez firewall słów kluczowych i wyjaśnić chęć zmiany i co zrobiłem, żeby się rozwinąć. :)

Mówimy partia, myślimy Lenin, mówimy Lenin, myslimy Partia. *)
Mówimy Java, myślimy JavoSpring

Ekosystem Javy nie jest tak wąski sam w sobie - ALE jak zarazem szukasz bezpieczeństwa socjalnego typu korporacyjnego, to jest głowny temat.
Na gruncie "nowych fajnych" jezyków tak samo staniesz wobec tego wyboru wielkości i stabilności pracodawcy (pewnie w mniejszych a'la startupach większa skłonności do eksperymentowania)

*) i tak już 25 lat co innego mówimy, co innego myslimy. Niby że z przemówienia Gomółki (dla młodzieży: pierwsze linia to fragment wiersza Majajowskiego w tłumaczeniu chyba Broniewskiego)

Trochę zaktualizowałem i wytłuściłem w pierwszym poście, bo nie chcę się skupiać na tym czy Java, czy Go, czy C# - to jest tylko narzędzie. Chcę się rozwinąć jako software engineer i liczę na waszę rady tutaj najbardziej

Do system design mogę polecić tą książkę Building Microservices. 2nd Edition Nie jestem zwolennikiem posiadania książek do IT bo się szybko deaktualizują, ale ta spokojnie da radę jeszcze przez kilka lat :) Z resztą DDD Evansa czy Vernona wciąż są aktualne a zostały wydane ponad 10 lat temu.

Co do chmury to skup się na jednej Azure/AWS/GCP nie ma znaczenia od której zaczniesz. W branży panuje przekonanie że Azure to .NET a AWS/GCP to cała reszta czyli Java/Python/Node, ale rzeczywistość nie jest zero-jedynkowa. To co chcę powiedzieć to że usługi chmurowe wysokopoziomowo są niemalże identyczne i przejście z używania takich Azure Functions na AWS Lambda to kilka dni. Podobnie jest z Kubernetesem. Jak zaczniesz z Kubernetesem na AKS to poradzisz sobie też na EKS. Oczywiście są różnice w deloymencie na niższym poziomie, ale ciebie jako programisty niskopoziomowe aspekty sieciowe nie powinny interesować. No chyba że chcesz robić rozwój i utrzymanie czyli po angielsku Fog Of... eee DevOps.

Do tego najlepiej ogarnąć darmowe laby od popularnych vendorów jak AWS czy Azure Większość z nich jest podzielona na role czyli wybierasz sobie Developer i dostajesz listę kursów wraz z dostępem do labowych rzeczywistych środowisk w chmurze na potrzeby wykonania ćwiczenia.

Vagrant, Openshift, Puppety, Chefy odpuść na razie. Zamiast tego ogarnij sobie Terraforma za pomocą którego tworzy się środowiska w chmurze i który jest niejako standardem mimo istnienia takich wynalazków jak Azure Bicep czy AWS CDK.

Do tego wiadomo Docker. Umiejętność stworzenia obrazu i deploymentu kontenera/ów ze swoją aplikacją/usługami to must-have.

Top 1 priority to zmiana pracy. Czym trudniejsza rekrutacja - tym lepiej, bo oznacza to ze inni twoi potencjalni zespolowi koledzy rowniez musieli przejsc ten sam proces.
Grokking Algorithms: An Illustrated Guide Aditya Bhargava to sa turbo podstawy. Jesli po 7 lat pracy masz problem z rzeczami tam obecnymi to nie jest najlepiej i oznacza to ze sporo czasu bedziesz musial poswiecic na leetcode. Samo poznanie tych algorytmow nie sprawi ze bedziesz potrafil nagle rozwiazywac zadania bazujace na nich. Polecam Elements of Programming Interviews, zdecydowanie lepsze niz CTCI.

Co do ksiazek okolo designowych:

• Designing Data-Intensive Applications
• Microservices Patterns With examples in Java
• Release it!
• Patterns of Enterprise Application Architecture
• Database Internals
• Data-Oriented Programming: Reduce software complexity
• Software Mistakes and Tradeoffs: How to make good programming decisions
• SQL Antipatterns: Avoiding the Pitfalls of Database Programming

Grokking The System Design jest bardzo dobre, ale jest to raczej wiedza "podstawowa". Jednak jesli nie miales duzo do czynienia z system designem to moze to byc dobry start.

Ja zamiast czytania dziesiątek książek i uczenia na sucho, zasugerowałbym stworzenie jakiejś open-source aplikacji klient-serwer w nowoczesnym stacku od podstaw i postawienie jej na jakimś cloudzie (np., oracle ma całkiem sensowny free tier). Jak nie chcesz babrać się w frontendzie to chociażby jakąś grę multiplayer z klientem skompilowanym do WASM (żeby działał w przeglądarce) gdzie backend napisany w np., go/rust dynamicznie skaluje się z użyciem kubernetesa, tymczasowe sesje trzymane są w Redisie a dane użytkowników w Postgres. Nauczysz się w praktyce jak end-to-end może wyglądać aplikacja, będziesz mógł bardziej swobodnie o tym rozmawiać, no i będziesz miał coś ciekawego do wpisania do CV/pokazania na interview.

Jak chcesz coś ciekawego porobić to generalnie radziłbym skupić się na konkretnej branży a nie na technologii. Wyspecjalizuj się nie w c++, ale np w przetwarzaniu obrazu. Znajomość domeny często jest game changerem.

Co do clouda, ogarnij jakie masz klocki na jednym z nich (ja najbardziej lubie AWS) , ktory do czego sluzy, przynajmniej te najbardziej podstawowe ec2, spot, LB, area 53, secret manager, aws uslugi popularnych technologii (np. Aurora), podstawy vpnow, rbac itp. A pozniej sobie tylko szukasz w google np. co jest odpowiednikiem ec2 w GCP.

hyacinth napisał(a):

Ja zamiast czytania dziesiątek książek i uczenia na sucho, zasugerowałbym [..]

No tak nie do końca bo żeby dobrze zaprojektować jakiekolwiek rozwiązanie trzeba mieć podstawy teoretyczne w zakresie architektury aplikacji oraz systemów. Przykładowo żeby dobrze zaprojektować API trzeba wiedzieć choćby jakie są sposoby na jego wersjonowanie, to po pierwsze. Po drugie trzeba rozumieć dlaczego wersjonowanie API (nieważne czy biblioteki czy HTTP czy SOAP) jest istotne. Po trzecie trzeba znać plusy i minusy każdego sposobu na wersjonowanie API.

To samo można powiedzieć o sposobach na integrację systemów w modelu zorientowanym na zdarzenia (event-driven). Co to jest orkiestracja, co to jest choreografia. Kiedy użyć jednego, a kiedy drugiego. Jakie są plusy i minusy każdego rozwiązania. I tak dalej i tak dalej. A sposób w jaki to zaimplementujemy, czy jakimiś Step Functions w AWS czy Logic Apps w Azure to już sprawa drugorzędna.

Zrobienie rzeczywistego projektu ok, ale pisanie, że czytanie książek, zwłaszcza tych poświęconych architekturze, które nie starzeją się po roku czy dwóch to bezsens moim zdaniem jest złe.

A co właściwie chcesz robić? archyekt? devłops? klepu klepu bitów w embedded?

no bo wypisałeś w sumie listę tak 1/3 "IT"

@MateuszZPolski:

Jesli po 7 lat pracy masz problem z rzeczami tam obecnymi to nie jest najlepiej i oznacza to ze sporo czasu bedziesz musial poswiecic na leetcode

A kto nie ma problemu z algorytmami?
Tak pytam bo sam mam

Podczas pracy spotkałem wielu mega gości. Byli mega ogarami
W bazach danych
W języku jako takim
W security
W testach
W performance
Ale nie spotkałem na żywo mega ogara w algo

Natomiast co do algo to jak trzeba było coś zrobić, bardziej poważnego, to
Albo zlecało się to uczelni
Albo wynajmowało się zespół do opracowania algorytmu
Żeby w razie czego był dupochron i podkładka że algo jest dobre

Zaryzykuję twierdzenie, że w codziennej pracy typowego programisty algorytmy są niemalże nieobecne. Konserwacja wiedzy algorytmicznej jest natomiast bardzo kosztowna (po sobie piszę)

Co do ogólnego problemu wątku
Niestety nasza branża wyjątkiem nie jest. Z 90 procent to rutynowa praca. Niektórzy mają szczęście i robią ciekawą, rozwijającą robotę
Moim zdaniem pierwiastek szczęścia jest bardzo ważny Umiejętności to warunek konieczny ale niewystarczający

Co do trudności rozmów jako prognostyku ciekawej pracy
Zdarzało się mi być maglowanym z system design i współbieżności a potem przez miesiące nawet jednego async await nie napisać, a zadania były typu, przejrzyj logi, zmień atrybut pola (wpis w kolumnie) w xmls itp.
Dla mnie tego typu przypadki były mega frustrujące. Po jasny wuj im był system design do przeglądania wpisów w logach.
Ogólnie rekrutacja w it to złożony problem. Najbardziej poryte w rekrutacji jest to, że jest to bardzo często jedyny moment w pracy, w którym w największym stopniu korzystasz ze swojej wiedzy.

Moim sposobem na w/w problem to zmiana pracy. Czy będzie lepiej? nie wiadomo.
Tyle ile tu było tematów, w stylu miały być złote góry, a skończyło się na grzebologi w bagnie świadczy o tym że problem jest dość powszechny.

Amerykański kult algorytmów to w dużej mierze taka romantyczna wizja, że programista musi być wybitny z matematyki, algorytmów i ogólnie najlepiej umieć wszystko od linuxa, przez asemblera, lutowanie układów, hakowanie itp. Pracowałem raz z takimi ludźmi i jeśli ktoś nie bywał w różnych projektach i nie ma expa to będzie czuł się jak oszust i nieogar. A w rzeczywistości programiści z jakimi się zderzyłem to, na nasze polskie warunki, wyceniłbym ich za średnich juniorów. Czar tego co mówili na rozmowach rekrutacyjnych prysł w 5 min po zobaczeniu kodu. Dramat to było mało powiedziane.

po prostu Java jest wykorzystywana w korpo kobylach. Zacznij prace w startupach w Go czy TS to zobaczysz rozrzut obowiązków.

wyjście ze złotej klatki javy to ciężka sprawa
przywołuję nekromatnę @jarekr000000

Marcin Marcin napisał(a):

wyjście ze złotej klatki javy to ciężka sprawa
przywołuję nekromatnę @jarekr000000

Dlatego, najgorszym co można sobie zrobić to zacząć zarabiać sporo bez zaspokojenia rozwojowych potrzeb, bo potem porzucenie tego na rzecz marzeń czy interesujących celów jest bolesne. Najpierw zabawa ciekawymi, rozwojowymi projektami np naukowymi a potem zarabianie poważnych pieniędzy, które w naszej branży często jest powiązane z utrzymaniem starej himery w fintechu.

i przede wszystkim chcę się rozwinąć jako software engineer, a nie polegać na konkretnym narzędziu

Jak dla mnie gadanie o rozwoju dla rozwoju jest bezcelowe, ale jeśli już musisz to weź się do roboty i wyprodukuj np. system operacyjny, bazę, język programowania, silnik do gry inaczej to tylko gadanie i samooszukiwanie.

A tak w ogóle to robisz typowy błąd, bo gdy chcesz być dobry we wszystkim to jeszcze bardziej poszarzejesz, nic nie będzie w Tobie specjalnego, godnego uwagi i tym samym wyróżnienia.

Jeśli myślisz, że problem jest w Twoim skillu technicznym to raczej nie skoro masz te 7 lat expa. Twój problem to brak skilla w sprzedaży i marketingu potencjału jaki w Tobie drzemie.

Chcąc wyjść z szarej strefy musisz mieć rozpoznawalność, uznanie i kontakty. Silna marka stokroć mocniej wpłynie na sprzedaż usług.

Chcesz się wybić to twórz, publikuj, udzielaj się, a przede wszystkim, swoim wkładem wpłyń na pracę devów czy firm. Ja tylko z powodu dobrych i ciekawych narzędzi / książek kojarzę ciekawe osobowości w naszej branży (np. https://www.taoensso.com/ albo https://www.booleanknot.com/ - każdy w społeczności clojure ich zna, bo za darmo napisali tak wiele użytecznych rzeczy).

Myślę, że ten cel najłatwiej osiągnąć koncentrując się na jakiejś niszy np. społeczności wchodzącego na rynek jakiegoś języka, bazy, czy innej technologii.

Genialna porada.
Komuś kto ewidentnie nie jest pasjonatem, ale próbuje znaleźć sposób jak nabyć typowe umiejętności wymagane na rynku pracy, odradzasz jego podejście, a zamiast tego sugerujesz jebnąć nową technologię.
Dokładnie o to mu chodziło.

Też miałem dość korpo, crudów, niedoceniania mnie jako kluczowej osoby. Poszedłem w krypto, w 4 lata wypracowałem markę osobistą w tym środowisku, odniosłem spore sukcesy. Polecam tę ścieżkę.

Lukxxx napisał(a):

Też miałem dość korpo, crudów, niedoceniania mnie jako kluczowej osoby. Poszedłem w krypto, w 4 lata wypracowałem markę osobistą w tym środowisku, odniosłem spore sukcesy. Polecam tę ścieżkę.

w jaki sposób wypracowałeś markę osobistą? Jak to się robi? Blogi, wystąpienia na konferencjach, coś takiego?

Jeżeli książka o algorytmach to tylko CLRS i Skiena, to co podałeś to słabizna. W tych które polecam jest dużo matematyki, ale spokojnie można pominąć przy pierwszym czytaniu i skupić się jedynie na tym jak działają algorytmy. Ważne, żeby rozwiązywać zadania z rozdziałów co najmniej te wymagające programowania.

W korpo nigdy nie będziesz robił:

1. tego co chcesz
2. czegoś ciekawego
3. nie poznasz dokładnie wszystkich procesów w aplikacji

Jeżeli chcesz robić coś ciekawego to tylko po godzinach honbystycznie :) A nuż może da się to jakoś sprzedać?

Te wszystkie marki osobiste... Potem miliony blogów z tym samym i trudniej znalezc cos wartosciowego.

Ciągła praca, udzielanie się w community. Bycie jedną z głównych twarzy jednego z klientów Ethereum. Udzielanie się na callach społeczności np. Ethereum All Core Devs. Branie udział w weryfikowaniu i pisaniu specyfikacji nowych EIP's itp itd. Mało występuję publicznie, więc ta marka jest raczej w wąskim kręgu faktycznych builderów protokołu, a nie szeroka.

snakeomeister napisał(a):

Te wszystkie marki osobiste... Potem miliony blogów z tym samym i trudniej znalezc cos wartosciowego.

Bo kiedyś to było bardziej autentyczne. Ktoś coś robił dla zajawki. A teraz dużo jest osób, które wrzucają spam, żeby zaistnieć, może osiągnąć sławę, może zmonetyzować, a może przeczytali, że trzeba to robić, żeby znaleźć pracę.

Nie żeby było coś złego w sławie czy monetyzacji, raczej chodzi o to, że widać, że to często jedyny powód, dla którego ktoś coś wrzucił do sieci. Gdzie jakość merytoryczna jest niska, a tematyka przewałkowana na setkach innych blogów.

No i brak pomysłu na siebie. Nie wiadomo kim jest autor i co go motywuje, czym się zajmuje, co chce osiągnąć od strony ideologicznej, nawet nie chcemy tego wiedzieć. Bo w zasadzie jest tam niby jakiś autor, ale to są treści, które mógłby napisać każdy.

pewnie bylo, to problem firmy, a nie technologii. Mozesz sprobowac zmienic firme juz teraz, najwyzej odpadniesz w rekrutacji, a i dowiesz sie czego nie wiesz. Szukaj firm produktowych, najlepiej mniejszych niz wiekszych.

członek zarządu napisał(a):

Amerykański kult algorytmów to w dużej mierze taka romantyczna wizja, że programista musi być wybitny z matematyki, algorytmów i ogólnie najlepiej umieć wszystko od linuxa, przez asemblera, lutowanie układów, hakowanie itp. Pracowałem raz z takimi ludźmi i jeśli ktoś nie bywał w różnych projektach i nie ma expa to będzie czuł się jak oszust i nieogar. A w rzeczywistości programiści z jakimi się zderzyłem to, na nasze polskie warunki, wyceniłbym ich za średnich juniorów. Czar tego co mówili na rozmowach rekrutacyjnych prysł w 5 min po zobaczeniu kodu. Dramat to było mało powiedziane.

Spróbuj robić leetcode za pomocą TDD. Zupełnie inaczej pisze się ,,na chybcika", a zupełnie inaczej porządnie. Najgorzej utrzymuje się kod, który najpierw powstał w głowie geniusza, a potem został przelany na klawiaturę (nawet jeśli jest napisany ,,porządnie"), a dopiero potem do niego powstały testy.

MarioBros33 napisał(a):

throwaway2137 napisał(a):

Ja, będąc Java devem, robiłem tylko Java kody. I to z reguły Java 8, nawet nie 11 :P Zero devops, zero architektury, zero projektowania rozwiązań, zero nowy sexy buzzwordów, zero ogarniania DB. Tylko kod Java, a cała reszta była zawsze oddelegowywana do innych specjalistów.

Ja też Java Dev i wydaje mi się że to kwestia firmy i projektu. U mnie od około 3 lat robię to samo mniej więcej co poniżej opisałem:

1. Stawianie infry w Pulumi/Terraform/Cloud Formation
2. Robienie pipelinów Azure/AWS itd
3. OpenShift lub Kubernetes
4. Zbieranie wymagań podczas refinementów, opisywanie tasków, dbanie o backlog na Jirze (rzadko kiedy pracowałem z prawdziwym biznes analitykiem więc te rzeczy sam robiłem zazwyczaj)
5. Implementacja w Javie funkcjonalności / featerów
6. Faza QA/Compliance/Cloud Security i tym podobne rzeczy
7. Wdrożenie na poszczególne środowiska

Jeżeli chodzi o język Go to ja miałem 2 oferty pracy w tamtym roku, że chcieli mnie przyjąć jako Javowca, ale abym się doszkalał i robi w Go. Także może tędy droga? Są firmy które takie coś oferują.

Śmiesznie, bo OP jawi się jako typowy dev-przegryw który w sumie ma 7 EXP ale nie umie nic ("tylko Java" to mniej więcej nic).

A pierwszy post od @MarioBros33 pokazuje jak powinny wyglądać umiejętności deva który umiał pokierować swoim rozwojem.

I w sumie koniec tematu.

Napisz na priv gdzie pracujesz, zachęciłeś mnie.