Zaczynam zastanawiać się czy nie lepiej by się żyło jakby przebranżowić z senior deva na devopsing na który jest teraz ogromne ssanie na rynku.
+ nie musisz mieć wiedzy domenowej/biznesowej o projekcie, skupiasz sie tylko głównie rzeczach technicznych. Nieraz trafiasz do firmy, która swoją domeną zajmuje się pare lat, nie ma za bardzo szkoleń z domeny, która do zrozumienia często wymaga wykształcenia się w tematach całkowicie niezwiązanych z IT. Ciężko jest stać się ważną osobą w projekcie jak jestes nowy to nie nadrobisz tych brakow wiedzy nawet po roku pracy. + brak parcia na "dowożenie" + jeszcze lepsze zarobki.
- już nie piszesz kodu tylko #!$%@? się z konfigami. Choć aktualnie będąc seniorem to bardziej wymaga się ode mnie wiedzy co się dzieje w projekcie, jak coś działa niż pisania kodu i nowych ficzerów, także tego kodowania i tak nie ma dużo `
Czy ktoś zrobił taki myk? Warto? Naprawdę chciałbym uciec od tego wymagania ode mnie wiedzy domenowej a wrócić do bawienia się technicznymi rzeczami i myślenia nad jakimiś nowymi rozwiązaniami. #programista15k #programowanie #devops
@PoteznyMagWody: devops here - w zalezności od firmy i struktury często wymagana jest wiedza z wielu projektów o których nie masz zielonego pojęcia. Nie ma szkoleń, ciągle szukasz ludzi którzy coś wiedzą. Nie masz czasu na nadrabianie braków wiedzy, jest task i musi być zrobiony bo dev stoi i jesteś blokerem ;) - bardzo dużo rzeczy jest na asap + kasa się rzeczywiście zgadza, ale to dopiero jak ogarniasz tematy.
@PoteznyMagWody: czesc, ja zajmuje sie devem(java, spring) i devopsowaniem, spoko sprawa, jednak nie zgodze sie z tym, ze nie piszesz kodu - implementujesz duzo automatyzacji(ansible) no i infra to tez kod (IaaC), czyli klepiesz terraform/CDK/CloudFormation itp. Dodatkowym atutem jest to, ze znasz sie na devie i bedziesz mogl sie dogadac z programistami, ja czesto implementowalem jakies niskopoziome tematy pod mikroserwisy(tracing, caching, logi)
@PoteznyMagWody: tutaj @walczak__ ma rację - często devops może być blokerem jeśli np jest sam jeden. U mnie np devops jest tak zawalony robotą że część rzeczy typu dockery i configi robimy dla niego sami, a on review + adaptacja do infry ¯\_(ツ)_/¯
@PoteznyMagWody: z tą presją to różnie....jest duża szansa że trafisz do korpo które robi wielką "transformację" i cię będą #!$%@?ć scrumem, sprintami i ciągłymi spotkaniami...been there, done that...
najlepiej celować w projekt/firme która ma już dość ugruntowane środowisko prod i nie robią gigantycznej transformacji a bardziej bieżące sprawy i lekkie ulepszenia xD
w dodatku musisz wspierać dużą ilość zespołów deweloperskich które ciągle coś od ciebie potrzebują...
że część rzeczy typu dockery i configi robimy dla niego sami
@Arogancky: patrzę i płączę, jak cała masa adminów, ludzi od infry itp myśli że ma cokolwiek wspólnego z kulturą DevOps. To co właśnie napisałeś to jest sedno DevOpsowania, sam sobie robisz. Po co ci potrzebny jakiś człowiek od tego, nie musisz czekać, nie ma podziału na Dev(ty) i Ops (twój pseudo-devops).
To co właśnie napisałeś to jest sedno DevOpsowania, sam sobie robisz.
@Djelon: nierealne, doświadczonych ludzi którzy są bardzo dobrymi devopsami i jednocześnie bardzo dobrymi deweloperami jest BARDZO MAŁY % rynku. nie mówię tu o takich pierdołach jak poprawianie skryptu do CI/CD, ale o wzięciu odpowiedzialności za całość części devopsowej łącznie z bezpieczeństwem itp itd.
@villager: wystarczy że zapewnisz proste możliwości konfiguracji + CI/CD i każdy developer będzie mógł sobie odpalać usługi czy zmieniać ich konfigurację. U mnie nawet Junior Dev da radę. Dla DevOps Engineera pozostaje zapewnienie żeby to sprawnie działało i ewentualny support. Nie wiem co określasz jako "całość części devopsowej", ale mam wrażenie że dzieląc to na części masz jakąś część tylko-Opsową. A bezpieczeństwo nie jest częścią "devopsową", każdy musi dbać o to
@villager: a kto twierdzi że developer ma to przygotować? Ale to jest narzędzie dla developera, od jego strony prostą warstwą abstrakcji są jakieś yamle, tfvarsy itp. I na bazie tego można mu dać możliwość pracy w kulturze DevOpsowej. Jeżeli DevOps engineer ma zarządzać infrastrukturą to staje się tylko opsem/adminem, z #!$%@?ą etykietką i zbyt wysokim kosztem i o tym mówię. Za 1/2-2/3 ceny można mieć CloudOpsa.
@Djelon: to że devopsi robią szablony, moduły, narzędzia i jednocześnie dążą do tego żeby deweloperzy sami mogli ich używać jest raczej oczywiste w każdej firmie
A mnie już Ci Ukraińcy wkurzają. Laski w klubach a faceci se chodzą na piwko burgera i do Ikei. A na front? Nie jestem ruska onuco cokolwiek to znaczy.
+ nie musisz mieć wiedzy domenowej/biznesowej o projekcie, skupiasz sie tylko głównie rzeczach technicznych. Nieraz trafiasz do firmy, która swoją domeną zajmuje się pare lat, nie ma za bardzo szkoleń z domeny, która do zrozumienia często wymaga wykształcenia się w tematach całkowicie niezwiązanych z IT. Ciężko jest stać się ważną osobą w projekcie jak jestes nowy to nie nadrobisz tych brakow wiedzy nawet po roku pracy.
+ brak parcia na "dowożenie"
+ jeszcze lepsze zarobki.
- już nie piszesz kodu tylko #!$%@? się z konfigami. Choć aktualnie będąc seniorem to bardziej wymaga się ode mnie wiedzy co się dzieje w projekcie, jak coś działa niż pisania kodu i nowych ficzerów, także tego kodowania i tak nie ma dużo `
Czy ktoś zrobił taki myk? Warto? Naprawdę chciałbym uciec od tego wymagania ode mnie wiedzy domenowej a wrócić do bawienia się technicznymi rzeczami i myślenia nad jakimiś nowymi rozwiązaniami.
#programista15k #programowanie #devops
- w zalezności od firmy i struktury często wymagana jest wiedza z wielu projektów o których nie masz zielonego pojęcia. Nie ma szkoleń, ciągle szukasz ludzi którzy coś wiedzą. Nie masz czasu na nadrabianie braków wiedzy, jest task i musi być zrobiony bo dev stoi i jesteś blokerem ;)
- bardzo dużo rzeczy jest na asap
+ kasa się rzeczywiście zgadza, ale to dopiero jak ogarniasz tematy.
Pisane
@PoteznyMagWody: tutaj @walczak__ ma rację - często devops może być blokerem jeśli np jest sam jeden.
U mnie np devops jest tak zawalony robotą że część rzeczy typu dockery i configi robimy dla niego sami, a on review + adaptacja do infry ¯\_(ツ)_/¯
najlepiej celować w projekt/firme która ma już dość ugruntowane środowisko prod i nie robią gigantycznej transformacji a bardziej bieżące sprawy i lekkie ulepszenia xD
w dodatku musisz wspierać dużą ilość zespołów deweloperskich które ciągle coś od ciebie potrzebują...
a co do płac, to
@Arogancky: patrzę i płączę, jak cała masa adminów, ludzi od infry itp myśli że ma cokolwiek wspólnego z kulturą DevOps.
To co właśnie napisałeś to jest sedno DevOpsowania, sam sobie robisz. Po co ci potrzebny jakiś człowiek od tego, nie musisz czekać, nie ma podziału na Dev(ty) i Ops (twój pseudo-devops).
@Djelon: nierealne, doświadczonych ludzi którzy są bardzo dobrymi devopsami i jednocześnie bardzo dobrymi deweloperami jest BARDZO MAŁY % rynku. nie mówię tu o takich pierdołach jak poprawianie skryptu do CI/CD, ale o wzięciu odpowiedzialności za całość części devopsowej łącznie z bezpieczeństwem itp itd.
Nie wiem co określasz jako "całość części devopsowej", ale mam wrażenie że dzieląc to na części masz jakąś część tylko-Opsową.
A bezpieczeństwo nie jest częścią "devopsową", każdy musi dbać o to
Jeżeli DevOps engineer ma zarządzać infrastrukturą to staje się tylko opsem/adminem, z #!$%@?ą etykietką i zbyt wysokim kosztem i o tym mówię. Za 1/2-2/3 ceny można mieć CloudOpsa.
@PoteznyMagWody: Musisz mieć i to jeszcze większą niż deweloperzy, bo zajmujesz się całością, a nie tylko wycinkiem.
@PoteznyMagWody: Parcie jest i to jeszcze większe, bo ludzie są zblokowani jak czegoś nie ma.
@PoteznyMagWody: Piszesz też kod, ale raczej nie logikę biznesową tylko optymalizację pod CI, CD lub