To jest 233. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o awansie od juniora do seniora w DevOps.

Notatkę, linki oraz transkrypcję do dzisiejszego odcinka znajdziesz pod adresem porozmawiajmyoit.pl/233.

Zastanawiasz się nad zmianą pracy, ale gdy przeglądasz oferty na popularnych stronach, to nie jesteś przekonany, czy młody, dynamiczny zespół oraz owocowe środy są dla Ciebie? Na szczęście jest SolidJobs, portal z ofertami pracy dla tych, którzy chcą wiedzieć, ile będą zarabiać, z jakimi technologiami i nad jakim projektem będą pracować. Solidne oferty pracy znajdziesz na solid.jobs.

Podcast Porozmawiajmy o IT  jest dostępny zupełnie za darmo. Obowiązuje tylko jedna zasada: Jeśli jesteś tu przynajmniej po raz drugi, to po pierwsze rozgość się, a po drugie, odwdzięcz za te treści, wystawiając ocenę w Twojej aplikacji podcastowej lub polecając odcinek w social mediach. Dziękuję.

Dla tych, którzy wytrwają do końca odcinka, czeka konkurs, w którym do wygrania są trzy niedawno wydane książki The Linux DevOps Handbook, której autorami są Damian Wojsław i Grzegorz Adamowicz.

Ja się nazywam Krzysztof Kempiński. Moją misją jest poszerzanie horyzontów ludzi z branży IT, co realizuję m.in. poprzez ten podcast. A teraz zapraszam Cię już do odcinka.

Odpalamy!

 

Cześć! 

Mój dzisiejszy gość to doświadczony inżynier DevOps i architekt chmury z ponad 4-letnim doświadczeniem w projektowaniu, automatyzacji i zarządzaniu środowiskami chmurowymi dla prestiżowych klientów. Podróżnik i inwestor na międzynarodowych rynkach. Cały czas pogłębia wiedzę z zakresu rozwoju osobistego, medycyny naturalnej oraz niekonwencjonalnej psychologii. Moim i Waszym gościem jest Paweł Frączyk.

Cześć, Pawle, bardzo miło mi gościć Cię w podcaście.

 

Cześć, Krzysztof. Witam wszystkich słuchaczy.

 

Dzisiaj będziemy mówić o bardzo popularnej ostatnio specjalizacji IT, nie tylko jeśli chodzi o liczbę osób, które chciałyby w niej pracować, ale również jeśli chodzi o zainteresowanie pracodawców i potrzeby na rynku. Mowa oczywiście o DevOps. a na podstawie historii Pawła zobaczymy, jak można dokonać awansu od juniora do seniora w tej specjalizacji.

Standardowo jednak chciałbym Cię, Paweł, najpierw zapytać, jak każdego mojego gościa, czy słuchasz podcastów. Jeśli tak, to może będziesz w stanie coś ciekawego polecić.

 

Tak, jak najbardziej słucham i podcastów, i kanałów YouTubowych, gdzie często wyłączam video, więc traktuję to też jako podcasty. Jeśli chodzi o naszą branżę, to wzorowałem się w swoich pierwszych miesiącach nauki na kanale Pasja informatyki, Mirosław Zelent. Duża wartość i zachęcam w szczególności osoby, które rozpoczynają swoją przygodę z IT, ale również szukają czegoś głębiej, bo na tym kanale oprócz rzeczy stricte technicznych bardzo zaciekawiły mnie podróże do własnego wnętrza, do ego, bardzo dużo fajnych treści.

Natomiast jeśli mówimy o takim szerszym kontekście, to dosyć szeroko interesuję się podróżami, inwestycjami, stąd też jeżeli chodzi o rozwój osobisty, to kanały takie jak Zen jaskiniowca czy Ekspert w bentleyu lub takie bardziej z branży nieruchomości, czy inwestycji Kuba Miller, czy Przygody przedsiębiorców, czy Grzegorz Kurz, gdzie też możemy zahaczyć o rzeczy nie tylko związane z naszymi finansami, ale z inwestowaniem w swoje zdrowie i rozwój, dążenie do zachowania tego popularnego balansu.

 

Tak, myślę, że śmiało wszystkie te kanały można polecić. Chciałbym rozpocząć naszą rozmowę o rozwoju, o awansie w DevOpsie od Twojej historii, bo nic nie inspiruje ludzi tak, jak historie innych. Więc jak to się stało, że w ogóle pojawiłeś się w tej specjalizacji? Jak ten proces nauki, rozpoczynania kariery u Ciebie wyglądał?

 

Historia moja bierze się stąd, że w 2016 r. odbyłem 100-dniową podróż do południowo-wschodniej Azji, to była samotna podróż backpackerska z plecakiem, miałem wtedy 29 lat i od ok. 10 lat moją profesją było bycie DJ-em. Nie kończyłem studiów technicznych, kończyłem stosunki międzynarodowe w Gdyni, natomiast takie rzeczy techniczne pojawiały się gdzieś tam w moim życiu we wczesnych latach, mówimy tutaj o czasach, gdy była jeszcze Neostrada 512, i stworzyliśmy z sąsiadami własną sieć na cztery komputery, żeby dzielić sobie łącze internetowe, więc gdzieś tam troszkę dłubałem przy takich rzeczach około technicznych, ale moje życie potoczyło się tak, że przez kolejne lata niekoniecznie aż tak dużo miałem wspólnego z branżą IT. 

Natomiast podczas tej podróży poznałem moją obecną żonę. Ona jest obywatelką Tajlandii. I wpadłem wtedy na taki pomysł, że fajnie byłoby coś zmienić w swoim życiu, aby móc pracować zdalnie i żeby nie musieć pracować już na nocki, tak jak to robiłem przez wiele lat jako DJ. I w roku 2018 postanowiłem spróbować uczyć się samemu podstaw programowania. Trafiłem na taką świetną stronę i bardzo ją polecam: freecodecamp.org, oni też mają kanał na YouTubie. Pamiętam, że wtedy po konsultacjach z moim kuzynem Krzyśkiem, którego serdecznie pozdrawiam, on jest programistą .NET-owym z wieloletnim doświadczeniem i on mnie tak nakierunkował, że jedną z dwóch takich furtek do IT to albo testowanie oprogramowania, albo frontendowe tematy, i chyba najczęściej ludzie zaczynają od tego kierunku.

W moim przypadku to było kilka miesięcy bardzo intensywnej nauki. Równocześnie załapałem się w Gdyni na taki kurs, to są te słynne bootcampy, natomiast to było dofinansowywane z jakiegoś programu miejskiego, więc miałem okazję korzystać z moich dni wolnych, bo pracowałem w weekendy, a w tygodniu miałem sporo wolnego czasu, więc zawziąłem się i spędzałem nad tym czas praktycznie od rana do wieczora, i efektem tego było po 3–4 miesiącach złapanie pierwszej pracy jako junior manualny tester w Trójmieście.

I przechodząc do tematu, skąd w ogóle DevOps, to też jest trochę dłuższa historia, natomiast podczas moich wcześniejszych wypadów do Tajlandii złapałem taką grupę o inwestowaniu, prowadzoną przez człowieka z Bangkoku, pozdrawiam też Maćka serdecznie, natomiast w tym gronie okazało się, że jest osoba mieszkająca niedaleko mnie, w Trójmieście, w Rumii, która wówczas była DevOpsem, pracowała dla jednego z bardzo dużych graczy na rynku trójmiejskim. I jak się spotkaliśmy, opowiedziałem Pawłowi swoją historię przebranżowienia, już pracowałem wtedy od kilku miesięcy jako tester i on mnie zachęcił, żeby może nie iść w kierunku programowania, ale może w kierunku DevOpsowym, żebym się podszkolił z zakresu automatyki, budowania pipelines, administrowania, i rozpocząłem w trakcie swojej pracy jako tester poznawanie tajników DevOpsowych.

W moim przypadku to było kilka miesięcy bardzo intensywnej nauki. Równocześnie załapałem się w Gdyni na taki kurs, to są te słynne bootcampy, natomiast to było dofinansowywane z jakiegoś programu miejskiego, więc miałem okazję korzystać z moich dni wolnych, bo pracowałem w weekendy, a w tygodniu miałem sporo wolnego czasu, więc zawziąłem się i spędzałem nad tym czas praktycznie od rana do wieczora, i efektem tego było po 3–4 miesiącach złapanie pierwszej pracy jako junior manualny tester w Trójmieście.

 

Czy te doświadczenia wcześniejsze związane z testowaniem w jakiś sposób według Ciebie pomogły Ci wystartować w tym obszarze DevOps? Były jakoś przydatne? Albo czy są teraz? Czy raczej odciąłeś grubą kreską i rozpocząłeś nowy rozdział w karierze?

 

Zdecydowanie tak, jako tester pracowałem przez rok, w międzyczasie zacząłem aplikować na stanowiska DevOpsowe. W tamtym czasie, to był rok 2019, nie było zbyt dużo ofert zdalnych, ja celowałem w oferty w Trójmieście i wysyłałem swoje CV na ogłoszenia zarówno z rocznym, trzyletnim wymaganym minimalnym doświadczeniem i ku mojemu zaskoczeniu otrzymywałem zaproszenie na rozmowy. I to było bardzo ciężkie przeżycie dla mnie, bo praktycznie co rozmowa rekrutacyjna to były totalnie inne zagadnienia, totalnie inne pytania. Na jednej rozmowie np. na zagadnienia związane z systemem operacyjnym CentOS, z jedną bazą danych, ale w innym projekcie już wymagana była inna baza danych, inne zagadnienia. I to mi w tamtym momencie pokazało też, jak szeroka jest ta specjalizacja, i to się potwierdza w tej chwili w mojej pracy, że nigdy nie wiemy, z czym będziemy mieli do czynienia, natomiast co do skilli z testowania wydaje mi się, ze przez ten rok i parę miesięcy wcześniej, gdy się przygotowywałem do podjęcia tej pierwszej pracy, nauczyłem się takiej staranności, tzn. patrząc na kod, który piszę, z punktu widzenia, jakby go już trochę otestować albo założyć kilka scenariuszy, co się może wydarzyć z tym kodem, i to uważam za cenną umiejętność, którą do dziś dzień praktykuję.

 

Super, że to się daje tak łączyć, że to daje taką faktycznie wartość. Coś, co jest unikalne, myślę, to jest właśnie łączenie tego typu różnych specjalizacji, to powoduje, że nie jesteśmy tacy sztampowi, tylko wnosimy jakąś dodatkową wartość.

To jest pewnie swego rodzaju truizm, ale myślę, że bardzo teraz widoczne jest na rynku pracy, że najtrudniejsze jest to wejście, rozpoczęcie pracy w branży. Jakie miałbyś rady, jak Ty do tego podszedłeś, jak pokazywałeś podczas rekrutacji, że faktycznie posiadłeś już jakąś wiedzę i umiejętności, że spędziłeś określony czas na nauce tych systemów?

 

Muszę przyznać, że pierwsze 2–3 lata to był dosyć ciężki okres dla mnie pod kątem takim, że o ile podczas pracy jako tester w godzinach wieczornych siadałem dalej do kursów online na popularnych platformach, jak Udini, bardzo fajnie w tamtym czasie też rozwijał się A Cloud Guru w języku angielskim, to też taki bardzo fajny tip dla osób, które zaczynają, aby szukać jak najwięcej materiałów jednak w języku angielskim i uczyć się, mimo że ten język techniczny może być dosyć ciężki. I pamiętam pierwsze kroki swoje, gdzie pomimo w miarę biegłego mojego angielskiego, musiałem dość mocno poszerzyć go o aspekty techniczne. I w tej chwili już łatwiej mi opowiadać o czymś technicznym w języku angielskim, niż przekładać to na język polski. Natomiast ten czas, to odcięcie się od życia social, bo pamiętam, że tamte pierwsze 2–3 lata to było zminimalizowanie jakichś wyjść wieczornych ze znajomymi, a uwierz mi, że przez tych 10 lat bycia DJ-em prowadziłem dosyć towarzyskie życie…

 

Domyślam się.

 

Więc trzeba było się trochę odciąć od tych znajomych i może nie wszyscy to akceptowali, ale właśnie wydaje mi się, że trzeba w pewnym momencie podjąć jakieś decyzje i trochę się skupić, tym bardziej że miałem wtedy już lekko ponad 30 lat. I powiedziałem sobie, że okej, fajnie, ludzie zaczynają zaraz po studiach czy nawet w młodszym wieku jako junior i może komuś aż tak się nie spieszy, natomiast ja też nie chciałem być juniorem przez 3–4 lata, mając już trzydzieści parę lat, stąd to moje takie zawzięcie, które, patrząc z perspektywy czasu, okazało się bardzo dobrą inwestycją w siebie.

Natomiast jak mówimy o rozmowach rekrutacyjnych, o rekruterach, to pamiętam, że często spotykałem się z odmową już na samym starcie, wysyłając aplikację, że no niestety, ale szukamy kogoś z większym doświadczeniem, nie tylko w branży IT, ale już jako DevOps, a najcięższe było, że pomimo tego, że już ileś pracowałem jako tester, to to było zachętą do tego, żeby doprowadzić do rozmowy wstępnej z HR-ami i zaprezentować swoją osobę jako bardzo dociekliwą, jako osobę bardzo pracowitą, ciekawą życia i całego świata DevOpsowego.

Chyba największym challengem była ta pierwsza praca. W pewnym momencie po prostu zacząłem pisać również w tym okienku, gdzie jest dodatkowa wiadomość, tak dosyć bezpośrednio, że rozumiem, że moje doświadczenie komercyjne być może nie jest zbyt duże, natomiast bardzo bym prosił o wzięcie pod uwagę mojego wieku, doświadczenia życiowego, podróżniczego, z różnych innych branż, które też może się przenieść na sposób i efektywność wykonywanej przeze mnie pracy, i oczywiście te godziny, które są spędzone na kursach.

Więc kursy, które robiłem, i certyfikaty chmurowe starałem się wypunktować w CV, żeby pokazać, że mimo krótkiego czasu komercyjnego te 8 godzin w pracy czy to przez 5, czy 12 miesięcy nigdy nie będą równe pomiędzy dwójką kandydatów.

Więc kursy, które robiłem, i certyfikaty chmurowe starałem się wypunktować w CV, żeby pokazać, że mimo krótkiego czasu komercyjnego te 8 godzin w pracy czy to przez 5, czy 12 miesięcy nigdy nie będą równe pomiędzy dwójką kandydatów.

 

Tak, absolutnie. Cieszę się bardzo, że tutaj mówisz, że nie ma takich dróg na skróty i trzeba faktycznie swoją pracę wykonać. Ale myślę też, że druga bardzo ważna rzecz, o której wspomniałeś, to jest to, żeby podkreślać swoje zaangażowanie i zainteresowanie tym tematem, żeby ten rekruter/ rekruterka po drugiej stronie, nawet jeśli jest tam osoba, która ma małe doświadczenie komercyjne, to widziała tę osobę, która będzie się chciała rozwijać, będzie zainteresowana zgłębianiem i w jakimś tam krótkim terminie będzie z tej osoby większa wartość dla firmy. Często jak rozmawiam z rekruterami, to właśnie takiego podejścia poszukują u kandydatów. Tym możemy sobie nadrobić, jeśli faktycznie brak jeszcze tych doświadczeń na koncie.

Chciałbym Cię spytać, bo oczywiście podejście podejściem czy przekazywanie naszego zainteresowania tą dziedziną jest ważne, to robi dobre wrażenie, ale nie ma co uciekać też od stwierdzenia, że firmy poszukują twardych kompetencji, osoby, która będzie w stanie określoną pracę wykonać. I tutaj chciałbym Cię zapytać, na bazie Twoich doświadczeń, jakie umiejętności, obszary według Ciebie są kluczowe w tym awansie od juniora do seniora w DevOps?

 

Jedna bardzo ważna rzecz, o którą zahaczyłeś, i to jest świeży temat, bo dosłownie wczoraj w organizacji, dla której w tej chwili pracuję jako konsultant, mieliśmy takie 2-godzinne warsztaty, w których brałem udział z drugim DevOpsem i mieliśmy opracować ścieżkę rozwoju w organizacji. I ten poziom 0 był taki mocno basic, i wspólnie stwierdziliśmy, że u takiej osoby, która wchodzi świeżutko w tematy DevOpsowe i nie przebranżawia się z bycia administratorem czy sieciowcem, czy może bazodanowcem, tylko jest taką osobą świeżą w IT, najbardziej pożądaną cechą jest po prostu umiejętność myślenia.

Czyli mówimy tutaj o tym, że w sferze DevOps mamy do czynienia z tyloma narzędziami, niejednokrotnie też, o ile np. ktoś nie zasiedzi się tych 15 lat w jednym projekcie, ale mówimy, że to wszystko z jednej strony ewoluuje, a z drugiej strony, pracując np. w software housie, gdzie mamy do czynienia z wieloma projektami, będziemy się spotykać czasami z różnymi językami programowania, gdzie trzeba będzie wesprzeć zespół developerski, więc takich podstawowym skillem będzie otwarte myślenie, połączone oczywiście później z taką bystrością umysłu w troubleshootingu, w rozwiązywaniu problemów, w łączeniu kropek. Więc ja bym na takim poziomie podstawowym nie stawiał koniecznie tych skilli technicznych.

I tutaj odniosę się też do swojego doświadczenia, takiego może troszkę właśnie niemiłego z niektórych rozmów, gdzie pamiętam, jak na tym etapie juniorskim dostawałem takie pytania typu podaj komendę Linuxową, która zrobi to i tamto. Oczywiście jest to jakiś sposób sprawdzania sztywnej technicznej wiedzy, ale ja zawsze wychodzę z założenia, i sam jak teraz prowadzę rozmowy rekrutacyjne z kandydatami, to bardziej ciekawi mnie na tym podstawowym etapie, jak ktoś myśli, jak ktoś podchodzi do jakiegoś problemu. Jeżeli wpisał w CV, że miał już do czynienia z jakimś serwisem, to podciągnąć tę rozmowę bardziej pod to, z jakimi problemami będziemy mieli do czynienia, bo większość możemy jednak wyczytać w tej dokumentacji, jeżeli mówimy tutaj o jakichś takich podstawowych komendach.

Natomiast jeśli mówimy o takiej drugiej fali sklilli, to będzie to tak szerokie i zależne (czyli magiczna odpowiedź: to zależy), ale jakbym miał zachęcić kogoś na start, to usiadłbym do takich podstawowych rzeczy typu język Bash, czyli troche sryptowania się pouczyć w Linuxowych systemach, oczywiście takich podstaw też związanych z systemami Unixowymi, a potem to jest szerokie i głębokie, bo patrząc chociażby z mojej perspektywy: ja się specjalizuję w chmurze AWS Amazona, również pracowałem z Microsoftowym Azurem, natomiast jeśli ktoś szuka DevOpsa AWS-owego, i to też sobie np. wczoraj na warsztatach omawialiśmy, które są core’owe skille, więc tutaj bym powiedział, że zaczynamy od compute, czyli podstaw takich.

I to u mnie też się fajnie przełożyło, bo pamiętam, że jako nastolatek sam sobie składałem peceta, więc coś tam pamiętałem, że była płyta główna, trzeba było włożyć kość RAM, mieliśmy procesor. Pamiętam jeszcze stare czasy Celerona, jak gdzieś trochę go podgrzałem i kupowało się pastę i się ją wymieniało do chłodzenia, więc takie elementy składowe.

Pamiętam też, że oglądałem w języku angielskim jeden taki kurs, przypominając sobie trochę hardware. Więc takie ogólne pojęcie, nie musimy schodzić aż tak nisko dokładnie do tego, jak zerojedynkowo jest to wszystko procesowane, ale chyba ten compute tutaj, takie ogólne pojęcie o komputerach, o administrowaniu, bo potem pójdą za tym różne węższe już tematy. Możemy się specjalizować w sieciowych tematach, w chmurze to jest w tej chwili też podstawa umieć zrobić prywatną VPC, wiedzieć, co to są tabele rutingowe, jaka jest różnica między internet gatewayem a nat gatewayem. Z tym że np. chmura nam daje o tyle fajną możliwość, że nie musimy schodzić do aż tak niskich gdzieś tam, głębokich poziomów, żeby coś móc skonfigurować. Dla przykładu przez ostatnie 2 lata pracowałem dla jednego klienta, gdzie korzystaliśmy z oprogramowania, które pozwoliło nam połączyć północ, południe, wschód, zachód, tutaj mówimy o sieci, czyli połączenie tzw. on-preme’u z tradycyjnych serwerowni do chmury, pomiędzy sieciami w chmurze mówimy właśnie wschód-zachód, i to wszystko bez znajomości konfiguracji konkretnego switcha, routera itd. Więc świat idzie troszkę ku takiej prostocie, natomiast w obszarach DevOpsowych nie zawsze może będziemy ekspertem we wszystkim, ale im szerzej będziemy patrzeć na to, co się dzieje w branży IT, tym bardziej nam chyba będzie łatwiej później się odnaleźć w konkretnych projektach.

 

Czyli te podstawy tak czy siak warto znać, niezależnie od tego, jaką specjalizację w ramach DevOps sobie wybierzemy. Później dużo by mówić, bo w zależności od tego, jaka to chmura, jaka specjalizacja, obszar, to narzędzia, toole i wymagania też są inne, natomiast chciałbym jeszcze na chwilę wrócić do tego etapu początkowego. On jest taki najtrudniejszy zazwyczaj, najtrudniej jest wejść. 

Jeśli mamy taką sytuację jak Ty, że się przebranżawiamy, to może być nawet trudniej, bo faktycznie zależy nam na tym, żeby to nie rozciągnęło się za bardzo w czasie, być może jesteśmy już na jakimś etapie życia, w którym też nie chcemy np. się cofać finansowo, różne rzeczy mogą wchodzić w grę.

Właśnie w tym kontekście chciałbym Cię zapytać o to przebranżowienie. Czy masz jakieś porady, strategie, co zadziałało, aby skutecznie się przebranżowić?

 

Zdecydowanie polecam nie bać się zrobić kroku do tyłu finansowego. Ja to przerobiłem i opłaciło się, tzn. patrząc długofalowo na swoje życie, i tego też uczyłem się à propos inwestowania. Więc tutaj akurat przygotowałbym się do tego albo rozplanował, ale to już będziemy wchodzili bardziej w finansowe tematy, natomiast jeśli chodzi o ten pierwszy okres juniorski, w moim przypadku było tak, że rozpocząłem pracę w jednym z software house’ów, i to była praca w pełni zdalna, to jeszcze było przed covidem, końcówka 2019 roku. Zostałem tam zatrudniony jako junior i poprzez dosyć ciężką pracę i aktywne podejście do wykonywanych obowiązków, miałem też to szczęście, że w tym pierwszym okresie pracowałem w 12-osobowym zespole, więc miałem dosyć szerokie pole do nauki, dużo projektów, dużo czasu spędzonego z osobami, które miały więcej doświadczenia ode mnie i po 3 miesiącach na podsumowującej rozmowie zostałem awansowany już na mida.

I wydaje mi się, że tutaj to był efekt wcześniejszej pracy jako tester, tych godzin wieczornych spędzonych, jak i  bagażu doświadczenia życiowego, o którym wspomniałem wcześniej.

W tym pierwszym etapie, gdy się już dostanie pierwszą pracę polecałbym – i tego chyba też się oczekuje od juniora – by był dociekliwy, by nie bał się zauważać pewnych niedoskonałości, bo nie ma idealnych projektów, firm, ludzi, kodu, a patrząc na niektóre osoby, które teraz zaczynają i z którymi miałem okazję współpracować, że jadą trochę po minimalu, ale być może właśnie boją się ruszyć kod, bo jak działa, to nie ruszaj. Ale wydaje mi się, że zaangażowanie, aktywność, zauważanie, szczególnie w naszej pracy, gdzie dużo rzeczy automatyzujemy. Ja też staram się patrzeć do tej pory na rzeczy, które wykonuję, jeżeli to jest czynność jednorazowa, dwurazowa w ciągu tygodnia czy miesiąca, jeżeli coś zaczyna się manualnie powtarzać, to w głowie sobie układam, jak by to zautomatyzować, jaki by tu skrypt napisać, jak to ogarnąć, żeby następnym razem tylko kliknąć czy dać jakiś imput i żeby już automat poleciał i zrobił to za nas.

 

Ty niejako dosyć szybko przeskoczyłeś do DevOps z testowania i stwierdziłeś, że były to mimo wszystko przydatne doświadczenia i nadal ten mindset wykorzystujesz. Czy jak obserwujesz swoje otoczenie, swoje koleżanki i swoich kolegów po fachu, to według Ciebie są jakieś specjalizacje IT albo jakieś wcześniejsze doświadczenia IT, które mogą pomóc w tej karierze, w jakiś sposób przyspieszyć rozwój inżyniera DevOps?

 

Zdecydowanie tak. Jak już wspomniałem, dużo osób migruje z bycia administratorem do systemów Linux czy Windows. W dwóch dużych korporacjach, w których miałem okazję pracować już jako DevOps inżynier, zauważyłem, że firmy same promują ludzi, i jeśli spojrzymy na ten jeszcze taki bardziej tradycyjny podział IT sprzed lat, gdzie były zespoły Linux Administrators, Windows Database Administrators, to najczęściej osoby, które wyrażały zainteresowanie, były właśnie wciągane w zadania DevOpsowe bądź potem migrowały ze swojego zespołu do zespołu DevOpsowego, Cloudowego, natomiast tutaj chyba najczęściej są to jednak osoby operacyjne, które migrują, niż programiści. Chyba się nie spotkałem jeszcze, żeby ktoś był DevOpsem, a wywodził się z programowania. Może dlatego, że jest tak ciężko u nas, a jednak życie programisty jest spokojniejsze. Nie no, żartuję oczywiście. Tzn. bardzo in plus jest ta otwartość taka wśród programistów na rzeczy związane bardziej z infrastrukturą, ale ja się wcale nie dziwię, bo tak jak wspomniałem, nie można być ekspertem we wszystkim, a wszyscy mamy sporo na głowie.

Wracając do pytania, ja wyskoczyłem z bycia testerem. Widziałem osoby, które z testowania też szły w tym kierunku. Jest to na pewno cięższa droga niż przeskoczenie z bycia administratorem, bo jednak w DevOpsowych tematach tak się czasami na to mówiło jeszcze z rok, dwa lata temu, że DevOps to jest taki Admin 2.0, natomiast ja tak na to nie patrzę.

Tutaj w DevOpsowych rzeczach jednak też jest bardzo ważna umiejętność empatyczna, co też w sumie testerzy mają, bo niejednokrotnie musimy pracować z ludźmi, którzy są mniej techniczni, z którymi trzeba usiąść, pokazać coś na ekranie, jak się robi. Taka otwartość, łamanie lodów w organizacjach. I to jest też może taki skill, o którym warto powiedzieć, że nie sztuką jest zrobienie wszystkiego samemu, tylko np. miałem też jedno z takich zadań w jednej z firm, że staraliśmy się zdecentralizować, bo wszystko, cała firma, było właściwie w rękach jednego człowieka, który zajmował się tak naprawdę wszystkim od strony technicznej, naszym zadaniem było wyciągnięcie tego, bo nie było żadnej dokumentacji, wiele rzeczy było robionych na jego komputerze, nie wszystko było zautomatyzowane, developerzy nie mieli praktycznie do niczego dostępu. Mówimy tutaj o nieprodukcyjnych środowiskach, żeby nawet dać ludziom troszkę więcej tutaj możliwości do eksperymentowania ze swoim kodem. 

Więc ja w kulturze DevOpsowej staram się w organizacji dać to, że po to rzeczy automatyzujemy, po to robimy infrastrukturę jako kod, aby móc to szybko odtworzyć, aby nie bać się czegoś zepsuć. I przy zmienianiu branży to może też być takim trochę ryzykiem, że jeżeli ktoś np. miał 5, 10 czy 15 lat doświadczenia w tym, czym się zajmował, że mogą być pewne naleciałości, zwyczaje, a osoba, która wchodzi na świeżo, może mieć totalnie świeże podejście.

Wiadomo, że nie ma rzeczy idealnych, bo z jednej strony doświadczenie bierze górę przy pewnych skomplikowanych sprawach, a z drugiej strony czasami świeże spojrzenie osoby, która nigdy czegoś nie robiła, pozwoli na znalezienie innego rozwiązania.

W dwóch dużych korporacjach, w których miałem okazję pracować już jako DevOps inżynier, zauważyłem, że firmy same promują ludzi, i jeśli spojrzymy na ten jeszcze taki bardziej tradycyjny podział IT sprzed lat, gdzie były zespoły Linux Administrators, Windows Database Administrators, to najczęściej osoby, które wyrażały zainteresowanie, były właśnie wciągane w zadania DevOpsowe bądź potem migrowały ze swojego zespołu do zespołu DevOpsowego, Cloudowego, natomiast tutaj chyba najczęściej są to jednak osoby operacyjne, które migrują, niż programiści. Chyba się nie spotkałem jeszcze, żeby ktoś był DevOpsem, a wywodził się z programowania.

 

Wspomniałeś o certyfikatach, sam zresztą jesteś posiadaczem wielu z nich. Zastanawiam się, czy w DevOps warto robić certyfikaty i dla kogo się to robi? Dla siebie czy może, żeby się lepiej spozycjonować na rynku?

 

Dla mnie certyfikaty to były narzędzia do pokazania swojego zaangażowania, szczególnie na tych wczesnych etapach, żeby móc się wyróżnić spośród innych kandydatów. Bardzo dużo robiłem różnych laboratoriów online, gdzie nie tylko było suche przechodzenie przez teorię, mówię w szczególności o chmurze AWS, bo od niej zaczynałem, natomiast wykonywanie praktyczne zadań, nawet krok po kroku, robiąc pauzę w filmie i odtwarzając to samo na własnym koncie AWS-owym dało mi tę przewagę, że jak już miałem obowiązek wykonania jakiegoś zadania w pracy, to o wiele szybciej schodziło mi się z tym, bo nawet jeżeli robiłem to raz czy dwa trzy miesiące wcześniej, to jednak już gdzieś w tej głowie było i o wiele łatwiej było podejść do tego zadania.

I wydaje mi się, że właśnie tutaj te certyfikaty bardzo dużo mi pomogły w pierwszych miesiącach pod kątem wdrażania się do projektów. Teraz bardziej już je traktuję, szczególnie w AWS-ie te poziomy Proffesional, mówimy tutaj o Solutions Architect i o DevOps Professional, jako taki challenge dla siebie i o bycie na bieżąco z tym, co się dzieje w AWS-ie, uaktualniam swój stan wiedzy poza doświadczeniem płynącym z projektów. Poprzez przygotowywanie się do tych egzaminów człowiek patrzy dosyć szerszym spojrzeniem na to, co się dzieje w danej technologii.

 

Mówiłeś dużo o uczeniu się, wspomniałeś, że poświęcałeś wiele godzin wieczornych, żeby tę wiedzę nadgonić, również teraz, poprzez certyfikaty, to jest ważne oczywiście, żeby się uczyć po pracy, ale też nie da się ukryć, że to, nad jakimi projektami pracujemy i w jakich firmach, to też jest doskonały sposób, żeby się uczyć, jest to wręcz częścią naszej nauki. Czy wobec tego według Ciebie jest jakiś profil firm albo wielkość firm, w których Twoim zdaniem łatwiej, korzystniej awansować jako DevOps, czy nie ma to żadnego znaczenia?

 

miałem możliwość pracować zarówno jako kontraktor dla bardzo małych klientów, gdzie byłem jedynym inżynierem DevOps i były mi przypisane stricte czasowe zadania, po prostu pracowałem na portalu freelancerskim po godzinach, mając już te +3 lata doświadczenia i zacząłem już trochę zmieniać ten układ, czyli nauki po godzinach już było trochę mniej, a szukałem sobie takich dodatkowych zajęć po głównej pracy, jak i byłem na fulltime w dosyć dużej firmie w skali globalnej. 

Powiedziałbym, że na dobry początek poleciłbym pójście do pracy do software house’u, gdzieś, gdzie jest zespół DevOpsowy, tak jak w moim przypadku było ponad 10 osób i to było owocne doświadczenie. Ja się też cieszę, bo dostałem w tamtym okresie taki feedback, że to nie było coś na zasadzie, że przyszedł junior i za jakiś czas sobie poszedł, tylko faktycznie wnosiłem jakąś wartość do tych projektów. Fajnie, bo z niektórymi osobami, z którymi wtedy zaczynałem pracować, do dzisiaj mamy kontakt i to jest chyba dosyć istotne, bo nie oszukujmy się, ale ludzie często piszą najpierw gdzieś po znajomych, że gdzieś jest poszukiwany DevOps, więc na samym starcie polecałbym pójście do software house’u i pracę z osobami bardziej doświadczonymi. 

Akurat mój kolega, z którym zaczynałem pracować wtedy jako junior, został np. w tamtej firmie do dzisiaj i jest najdłużej pracującym DevOpsem (ok. 5 lat). Każdy idzie swoją ścieżką. Ja robiłem troszkę takie częstsze te skoki, szczególnie na początku, wychodząc z założenia, że im więcej zobaczę, tym szybciej złapię doświadczenia, szerszego spojrzenia, niż siedząc w jednym projekcie przez 4 lata, co może też nie wszystkim się podobać, np. pracodawcy, ale starałem się zawsze w okresie pracy, wraz z większą odpowiedzialnością na wyższych stanowiskach zostać dłużej niż na czas jednego projektu. Natomiast czas na pracę przy startupach przychodzi później, jak już człowiek faktycznie zjadł zęby na różnych problemach, widział to i tamto. Ale też chyba mało kto zatrudnia do startupów juniorów, raczej są poszukiwane tu osoby na stanowiskach seniorskich i wyżej. 

Nie polecałbym chyba na start pójście do dużego korpo, tzn. do firmy produktowej bezpośrednio jako junior. Wydaje mi się, że tam ten proces może być troszkę wolniejszy. Aczkolwiek nie wszędzie na pewno. Moje prywatne zdanie.

Powiedziałbym, że na dobry początek poleciłbym pójście do pracy do software house’u, gdzieś, gdzie jest zespół DevOpsowy, tak jak w moim przypadku było ponad 10 osób i to było owocne doświadczenie. Ja się też cieszę, bo dostałem w tamtym okresie taki feedback, że to nie było coś na zasadzie, że przyszedł junior i za jakiś czas sobie poszedł, tylko faktycznie wnosiłem jakąś wartość do tych projektów. Fajnie, bo z niektórymi osobami, z którymi wtedy zaczynałem pracować, do dzisiaj mamy kontakt i to jest chyba dosyć istotne, bo nie oszukujmy się, ale ludzie często piszą najpierw gdzieś po znajomych, że gdzieś jest poszukiwany DevOps, więc na samym starcie polecałbym pójście do software house’u i pracę z osobami bardziej doświadczonymi. 

 

Dzięki za te wskazówki. Zapamiętałem to, co mówiłeś przy wysyłaniu CV na początku swojej drogi, ze tam zaznaczałeś wręcz swoje doświadczenie podróżnicze, pisałeś o tym, że to może ubogacać Cię jako przyszłego pracownika i wnosić dodatkową wartość. Jestem bardzo tego wątku ciekawy, jak te Twoje podróże wpłynęły na decyzje związane z karierą, jak otworzyły Cię na różne możliwości. Czy według Ciebie to jest istotne, żeby właśnie w ten sposób również się rozwijać?

 

Zdecydowanie tak. Polecam podróżowanie wszystkim, ponieważ nigdy nie wiemy, co te podróże nam tak naprawdę w życiu przyniosą. I w sumie ten przeskok do świata IT był spowodowany właśnie m.in. moimi podróżami, tym, że poznałem w Azji swoją żonę, gdzie w tej chwili też mieszkam i skąd pracuję. Nigdy się nie spodziewałem, że trzy lata po moim pierwszym przylocie tutaj będę mógł stąd pracować. 

Myślę też, że kluczowym czynnikiem za są po prostu ludzie, bo to o to chodzi w podróżowaniu, żeby poznawać ludzi. Ja w tamtym okresie podróżowałem backpackersko, to są takie doświadczenia, szczególnie wylatując gdzieś na koniec świata, na obcy kontynent, że trzeba się liczyć z tym, że będą jakieś niedogodności, a to jakiś autobus nie przyjedzie, a to zamówienie w restauracji jest nie takie, jak się chciało. Ja nauczyłem się bardzo dużo elastyczności poprzez podróże, i to też jest fajny skill, który przenoszę do pracy; i takie spojrzenie na to, że świat nie jest idealny. Tak też jest w kulturze DevOpsowej, właśnie o to chodzi, żeby skracać czas iteracji, żeby był ten szybszy feedback, że to nie musi być wszystko od samego początku idealne. 

To chyba też trochę z Agilem się wiąże, żebyśmy dostarczali zawsze jakąś wartość wraz z każdą iteracją, tak to sobie uzmysłowiłem, plus na pewno podróżowanie po innych kulturach pozwoliło mi sobie uświadomić, że to, że coś jest inne, nie znaczy, że jest lepsze lub gorsze. Ono jest po prostu inne. I może nie trzeba się spieszyć z ocenianiem. 

Więc jak najbardziej podróże. Polecam, zachęcam i jeżeli jest w ogóle taka możliwość i pracodawca czy kontrahent się zgadzają, to według mnie trochę takiego workation jest też świetnym rozwiązaniem, zwłaszcza jak się jest samemu. Ja mam już teraz na głowie rodzinę, żonę i małe dziecko, więc z nimi podróżowanie i praca już jest troszkę mniej efektywne. Więc raczej już tak nie podróżujemy, tylko to są już raczej takie urlopowe tematy.

 

Tak, ale generalnie praca w IT ułatwia podróżowanie, tak jak mówiłeś, chociażby workation jest dobrym rozwiązaniem, praca zdalna, no mamy sporo narzędzi w naszej branży, żeby pogodzić w jakiś sposób podróżowanie z pracą zawodową.

Przedstawiając Cię na początku, wspomniałem, że interesujesz się rozwojem osobistym, medycyną naturalną, psychologią, a jestem ciekawy, jak te obszary łączą Ci się z rozwojem zawodowym, czy myślisz, że w jakiś sposób na siebie wpływają, cy wykorzystujesz jedno w drugim?

 

Wydaje mi się, że tak. Patrzę na swoje życie jak na taką sinusoidę i mogę tu powiedzieć nawet o takich fizycznych aspektach, bo był okres, że ważyłem prawie 100 kg, zszedłem w trakcie pracy w IT do 80, w zeszłym roku wskoczyłem na 94 z powrotem, teraz jestem na granicy 90. 

To są takie przyziemne problemy, a szczególnie jak pracujemy przy komputerze i jest trochę mniej tego ruchu, a dochodzi stres w pracy, bo są deadline’y, jakieś ciśnienie, bo coś trzeba dowieźć itd. i każdy z nas na pewno różnie na to reaguje. Ja np. miałem taki okres, że zajadałem ten nawał pracy strasznie. A szukając jakichś alternatywnych kanałów na YouTubie i źródeł informacji, jak sobie poradzić z nadwagą, odkryłem np. styl niskowęglowodanowy. To jest coś, o czym nigdy wcześniej nie słyszałem, a był też okres, że patrzyłem na to negatywnie, a w tej chwili, od 3 tygodni to bardzo mi pomaga, czuję, że jestem mega spokojniejszy. Czyli pierwszym odruchem było zajadanie stresów, a wydaje mi się, że to potem potęguje w człowieku taką emocjonalność, np. lampka wina co wieczór dla rozluźnienia stresu może okazać się błędnym kołem. 

Swojego czasu też rozszerzałem wiedzę na temat wystawiania swojego organizmu na zimno. Jest taka osoba w Holandii jak Wim Hof, który pokonał wiele rekordów, chyba nawet też Guinnessa, z tego co pamiętam, pływając pod taflą lodu czy wspinając się na Kilimandżaro w spodenkach itd. 

Staram się szukać takich różnych rzeczy, które może nie idą w mainstreamowych mediach. I dla mnie to było bardzo ciekawe, bo jak pierwszy raz spróbowałem jego techniki oddychania, to po raz pierwszy w życiu wstrzymałem oddech na ponad 2 minuty. I to był taki game changer dla mojego umysłu, że tak można, bo kiedyś dla mnie to było 30-40 sekund i to był maks. Więc tego typu zgłębianie wiedzy to dla mnie fajna przygoda i zadzwienie, bo czasami nasze życie jest rutynowe, wpadamy w tygodniową, miesięczną rutynę, a nie ma czasu, żeby się na chwilę zatrzymać i zastanowić nad tym, do czego tak naprawdę jesteśmy zdolni. I tutaj polecam taką otwartość, a internet nam daje naprawdę w tej chwili bardzo duże możliwości, żeby poszukać czegoś nowego, żeby odkrywać. I to chyba też się trochę wiąże z podróżowaniem. Czyli odkrywanie nie tylko nowych lądów, pięknych widoków, ale odkrywanie też nas samych.

 

Tak, to bardzo dobre podsumowanie. Jak by nie było, pracujemy też „naszym ciałem, umysłem, więc jeśli o nie nie zadbamy, to oczywiście nie będziemy wystarczająco wydajni, nasz rozwój kariery też nie będzie na tyle skuteczny i szybki, na ile byśmy tego oczekiwali.

Myślę, że wyszedł nam odcinek o bardzo holistycznym podejściu do awansu od juniora do seniora w DevOps. I bardzo dobrze, bo nie tylko kwestie techniczne, twarde się liczą, ale też cała otoczka, która temu towarzyszy.

Bardzo przyjemnie, fajnie mi się z Tobą rozmawiało i dziękuję Ci za to spotkanie.

 

Bardzo dziękuję i do usłyszenia.

 

Dzięki wielkie. Powiedz jeszcze na koniec, gdzie Cię można znaleźć w internecie, gdzie możemy odesłać słuchaczy.

 

Można mnie znaleźć na YouTubie. Nie jestem jakimś dużym YouTuberem, ale mam kanał Paweł Frączyk, taki prywatny, trochę o podróżach, trochę o życiu. Również nagrywałem trochę filmów na temat chmury AWS-owej Terraforma, kanał nazywa się DevOps Codes i można znaleźć mnie także na LinkedInie.

 

Oczywiście wszystkie linki będą w notatce do odcinka. Paweł, jeszcze raz bardzo Ci dziękuję. Do usłyszenia, cześć!

 

Dzięki, cześć!

 

I to na tyle z tego, co przygotowałem do Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

A teraz obiecany konkurs. Książkę autorstwa Damiana Wojsława i Grzegorza Adamowicza pt. The Linux DevOps Handbook otrzymają 3 osoby, które jako pierwsze wyślą poprawną odpowiedź na dwa pytania na wspomniany adres e-mail krzysztof@porozmawiajmyoit.pl:

1. Jakiej komendy użyjesz do zainicjowania nowej konfiguracji Terraforma katalogu?
2. Która instrukcja jest używana do kopiowania plików z maszyny hosta do obrazu dockera.

Powodzenia!

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o awansie od juniora do seniora w DevOps. 

Zapraszam do kolejnego odcinka już wkrótce. 

Cześć!