Michał Czinow żyje i pracuje w Berlinie od dwóch lat. Michał opowiedział, czym różni się praca programisty w Rosji i w Niemczech, czy w Berlinie są poszukiwani inżynierowie związani z DevOps i jak znajduje czas na podróże.
O przeprowadzce
Od 2018 roku żyjesz w Berlinie. Jak podjąłeś tę decyzję? Czy wcześniej świadomie wybierałeś kraj i firmę, w której chcesz pracować, czy dostałeś ofertę, której nie można odrzucić?
W pewnym momencie znudziło mi się życie w Penzy, gdzie się urodziłem, dorastałem i ukończyłem uniwersytet, a standardowa ścieżka przeprowadzki do Moskwy i Petersburga mnie nie interesowała z powodu specyfiki życia w tych miastach. Dlatego po prostu chciałem spróbować mieszkać w Europie, którą odwiedzałem przez ostatnie kilka wakacji. Nie miałem żadnych preferencji co do firmy, miasta ani nawet konkretnego kraju — po prostu chciałem się przeprowadzić jak najszybciej.
W tamtym momencie uznałem Berlin za najbardziej przystępne miasto do przeprowadzki dla programisty do firmy technologicznej, ponieważ na LinkedIn 90% firm tolerancyjnych na relokację znajdowało się w Berlinie. Później przyleciałem do miasta na 3 dni, aby przeprowadzić kilka rozmów twarzą w twarz. Miasto bardzo mi się spodobało, więc postanowiłem, że chcę mieszkać w Berlinie właśnie teraz. Po tygodniu niezwłocznie przyjąłem najpierwszą ofertę, jaką otrzymałem z berlińskiego tech-hubu.
Opowiedz, proszę, dokładniej o procesie przeprowadzki. Jak to u ciebie przebiegało? Jakie dokumenty zbierałeś? Czy pracodawca pomagał?
Nie mogę tutaj powiedzieć nic nowego, wszystko zostało już bardzo dobrze opisane w kilku artykułach. Bardziej podoba mi się , znana wszystkim, którzy interesują się tym tematem. W berlińskim tech-hubie proces jest praktycznie taki sam we wszystkich firmach pomagających inżynierowi z relokacją.
Czy spotkałeś się z czymś niespodziewanym i nietypowym w zakresie organizacji pracy, codzienności, mentalności? Jak długo przyzwyczajałeś się do życia na miejscu?
Tak, w rzeczywistości cały proces pracy w firmach berlińskiego tech-hubu początkowo mnie szokował. Dosłownie wszystko: od tego, jak i w jakiej liczbie odbywają się spotkania, po rolę umiejętności interpersonalnych w życiu inżyniera.
Na przykład w Niemczech kultura pracy koncentruje się na podejmowaniu decyzji w grupie, co oznacza, że na każdy kontrowersyjny temat zwoływane jest spotkanie, podczas którego szczegółowo omawiasz problem i wspólnie dochodzisz do konsensusu z waszych punktów widzenia. Dla rosyjskiego inżyniera taka praktyka początkowo wydaje się stratą czasu, biurokracją i brakiem zaufania, jednak w końcu ma to sens, tak samo jak podział odpowiedzialności za wynik decyzji.
Takie momenty, jak również brak zrozumienia samego siebie ze strony kolegów, skłoniły mnie do przeczytania książki i zrozumienia, że wszystkie twoje wewnętrzne frustracje są raczej odmową akceptacji rzeczywistości nowego środowiska, w którym się znalazłeś, niż próbą znalezienia prawdy. Po przeczytaniu książki praca stała się znacznie łatwiejsza, zaczynasz rozumieć sens fraz i decyzji swoich kolegów.
Jeśli chodzi o życie, proces adaptacji w nowym kraju jest znacznie trudniejszy niż proces adaptacji w kulturze pracy. Zazwyczaj psycholodzy wyróżniają , przez które przechodzi człowiek. W tym sensie moja droga nie była wyjątkiem. Z drugiej strony, wydaje mi się, że adaptacja po przeprowadzce do wielokulturowego miasta takiego jak Berlin, Londyn czy Barcelona przebiega z założenia łatwiej niż w jakimkolwiek klasycznym mieście.
Po dwóch latach życia w Berlinie, co ci się podoba, a co nie w tym mieście?
Trudno mi stworzyć listę plusów i minusów miasta, ponieważ Berlin dość szybko stał się moim domem w każdym tego słowa znaczeniu.
Myślę, że przez całe moje świadome życie dążyłem do wolności we wszystkich jej przejawach: fizycznych, społecznych, finansowych, politycznych, duchowych, mentalnych. Nawet tej samej wolności w pracy, nie lubię kontroli z góry i mikrozarządzania, kiedy ciągle wskazuje mi się, co i jak powinienem robić. W tych kwestiach Berlin wydawał mi się i wciąż wydaje jednym z najbardziej wolnych miast na świecie z powodu swobodnych poglądów na życie w społeczeństwie, stosunkowo liberalnych cen za wynajem mieszkania i innych potrzeb oraz wielu możliwości rozwijania swojej wolności w innych aspektach.
O pracy w Berlinie
Jaki stos technologiczny jest standardem w berlińskich startupach? Jak w ogóle różni się on od średniego w Rosji?
Z punktu widzenia technologii, lokalne stacki subiektywnie wydają mi się nudne, jeśli nie są to firmy FinTech. Większość startupów oraz tych, które przeszły z etapu startupu do korporacji, zostały założone w latach 2010-2012 i zaczynały od najprostszej architektury: monolityczny backend, a czasami nawet z wbudowanym frontendem, język — albo Ruby, albo PHP, albo Python, w użyciu zawsze frameworki, baza na MySQL, cache na Redis. Także, z moich osobistych odczuć, 90% firm ma cały produkcyjny system na AWS.
Teraz wszyscy mają tendencję do rozdzielania monolitu na mikrousługi, pakowania ich w kontenery, wdrażania w Kubernetes i polegania na Golangu jako standardowym języku dla nowych aplikacji. Dzieje się to dość powoli, dlatego w większości firm główny funkcjonalność wciąż jest zakopana w monolicie. Jestem daleki od frontendu, ale tam zazwyczaj standardem jest React.
Duże firmy technologiczne, takie jak Zalando i N26, starają się wprowadzać więcej technologii do swoich usług, aby przyciągać ambitnych programistów na rynku. Inne firmy technologiczne również dążą do nadążania za najnowszymi technologiami, jednak z zewnątrz widać, że przygniata je ciężar monolitycznej architektury oraz narastającego przez lata długu technologicznego.
Jako inżynier podchodzę do tego dość spokojnie, ponieważ w tech-hubie Berlina jest wiele interesujących firm z punktu widzenia produktu. W takich firmach ciekawiej jest pracować dla idei i produktu, który osobiście ci się podoba, niż traktować firmę jako miejsce pracy z modnym stackiem technologicznym, z którym koniecznie trzeba się zmierzyć.
Czym różni się życie i praca programisty w Rosji i w Niemczech? Czy są jakieś rzeczy, które cię zaskoczyły?
W Niemczech, podobnie jak w każdym innym kraju północnej/centralnej Europy, lepiej wygląda kwestia równowagi między pracą a życiem a także relacji między kolegami, jednak gorzej z szybkością pracy. Na początku czułem dyskomfort przyzwyczajając się do wewnętrznych projektów, które zajmują kilka miesięcy, podczas gdy w firmach technologicznych w Rosji podobne projekty zajmowały kilka tygodni. W rzeczywistości, to nie jest straszne, ponieważ są obiektywne powody, dlaczego tak jest, a firmy zazwyczaj nie traktują takich sytuacji krytycznie.
W pozostałych kwestiach trudno mi porównać Niemcy i Rosję, ponieważ nie mam doświadczenia w pracy w znanych firmach, takich jak Yandex czy Tinkoff, gdzie sytuacja może być podobna do berlińskiego tech-hubu.
Zaobserwowałem, że w Berlinie dużą wagę przykłada się do tworzenia komfortowej atmosfery pracy w firmach, regularnych wydarzeń wewnętrznych oraz różnorodności kolegów, z którymi zawsze interesująco jest rozmawiać na tematy niezwiązane z IT. Myślę jednak, że zależy to bardziej od firmy, w której się pracuje, niż od kraju.
Z Twoich obserwacji, jacy specjaliści są poszukiwani w Niemczech? Czy specjaliści związani z DevOps są pożądani?
W większości firm odczuwalny jest problem z postrzeganiem kultury DevOps oraz zrozumieniem, czym tak naprawdę jest DevOps. Jednak ofert pracy z dopiskiem DevOps jest bardzo dużo, co wyraźnie pokazuje zapotrzebowanie na specjalistów na rynku.
Obecnie w lokalnym IT z równą intensywnością poszukiwani są wszyscy aktualne na dzisiaj kierunki. Mogę jedynie wyróżnić duże zapotrzebowanie na Data Engineer/Data Analyst.
Porozmawiajmy o wynagrodzeniach, ile tak naprawdę można zarobić jako inżynier DevOps w Niemczech?
Trudno odpowiedzieć na to pytanie, ponieważ IT to wciąż młoda branża, w której nie ma konkretnych norm dotyczących wynagrodzenia. Jak wszędzie, wysokość wynagrodzenia w dużej mierze zależy od doświadczenia i kwalifikacji inżyniera. Ważne jest również postrzeganie kwoty jako wynagrodzenia przed podatkami oraz różnymi składkami społecznymi/ubezpieczeniowymi. Ponadto wynagrodzenie w Niemczech w dużym stopniu zależy od miasta, w którym pracujesz. W Berlinie, Monachium, Frankfurcie i hipotetycznym Getyndze przedział wynagrodzeń różni się nieco między sobą, podobnie jak koszty życia.
Mówiąc o Berlinie, główną zaletą kariery jest to, że popyt na inżynierów wciąż przewyższa podaż, więc wynagrodzenie może szybko rosnąć, jeśli jest taka potrzeba. Główną wadą jest to, że większość firm nie ma jasno określonej polityki przeglądu wynagrodzeń ani kryteriów oceny wkładu w tworzony przez firmę produkt.
Liczby można zobaczyć w , StackOverflow lub . Statystyki są aktualizowane co roku, dlatego nie biorę na siebie odpowiedzialności za mówienie o przedziale wynagrodzeń.
Czy możesz dać jakieś rady, co robić, jeśli pracujesz jako Site Reliability Engineer i chcesz przeprowadzić się do Niemiec? Od czego zacząć? Gdzie iść?
Nie sądzę, żebym miał jakieś szczególne rady dla czytelników. Może tylko nie bać się, nie rationalizować za bardzo przed przeprowadzką i być otwartym na wszelkie trudności, jakie mogą się pojawić w emigracji. A trudności na pewno będą.
Czy w Berlinie jest silna społeczność DevOps? Czy często chodzisz na lokalne wydarzenia? Opowiedz trochę o nich. Jakie są?
Na meetupy chodzę dość rzadko, więc nie mogę powiedzieć, jakie są szczególności lokalnej społeczności DevOps. Mam nadzieję nadrobić to w przyszłym roku. Mogę tylko podzielić się swoimi wrażeniami z ogromnej liczby tematycznych grup na meetup.com: od zapaleńców Pythona i Golanga po miłośników Clojure i Rust.
Z tych meetupów, które odwiedziłem, bardzo dobra jest HashiCorp User Group — ale ogólnie naprawdę podoba mi się społeczność HashiCorp z jej grupami w różnych miastach.
Czytałam, że przeprowadziłeś się bez znajomości niemieckiego. Jakie są postępy po roku? Czy potrzebny jest język niemiecki do pracy, czy można się bez niego obejść?
Nauczyłem się niemieckiego, obecnie mój poziom waha się między B1 a B2. Wszystkie kontakty z Niemcami z pierwszego roku życia w Berlinie nadal utrzymuję po angielsku, ponieważ tak jest łatwiej obu stronom, a wszystkie nowe kontakty zaczynam od niemieckiego. W najbliższych planach mam zamierzam poszerzyć swoją wiedzę, zdając egzamin na certyfikat B2, ponieważ chcę pewniej się komunikować, czytać klasykę literatury w oryginale.
W Berlinie język jest bardziej potrzebny do adaptacji w kraju, zdobycia wewnętrznego komfortu i pełnego dostępu do sfery rozrywki (teatr/kino/stand-upy), jednak w pracy inżynierii oprogramowania język raczej nie jest potrzebny. W każdej firmie angielski jest oficjalnym językiem działu inżynieryjnego, nawet w dużych niemieckich firmach jak Deutsche Bank, Allianz i Volkswagen.
Głównym powodem jest niedobór kadry, status miasta jako międzynarodowego centrum kulturalnego, wielu ekspatów, którzy mają problemy z nauką języka niemieckiego. Niemniej jednak każda firma oferuje cotygodniowe kursy niemieckiego w godzinach pracy, żeby ułatwić życie pracownikom poza pracą.
Przez wszystkie dwa lata kontaktów z firmami i rekruterami tylko dwa razy rozmawiano ze mną po niemiecku. W takich wyjątkowych przypadkach wystarcza zazwyczaj poziom B1/B2. Podobnie jak Amerykanie z angielskim, Niemcy dość spokojnie podchodzą do błędów językowych, ponieważ rozumieją, że język nie jest łatwy.
W swoim piszesz, że DevOps to nie umiejętność manipulowania Kubernetesem i Prometheusem, lecz kultura. Twoim zdaniem, co powinny robić firmy, aby rozwijać kulturę DevOps w zespole, nie tylko na słowach, ale w praktyce? Co robisz u siebie?
Myślę, że w pierwszej kolejności trzeba być szczerym i jasno określić odpowiedzialność za produkt. Główny problem, który rozwiązuje DevOps, to przerzucanie odpowiedzialności i związanych z nią problemów przez mur. Gdy ludzie zrozumieją, że dzielenie się odpowiedzialnością jest korzystne zarówno dla firmy, jak i dla inżynierów – można ruszyć z miejsca i zająć się konkretną pracą: dostrajaniem Delivery Pipeline, redukcją Wskaźnika Niepowodzeń Wdrożeń i innymi rzeczami, które można skontrolować w kontekście stanu DevOps w firmie.
W swojej karierze nie promowałem jeszcze DevOps z perspektywy technical leada czy CTO firmy, zawsze występowałem z pozycji inżyniera, który coś wie o DevOps. W rzeczywistości, w DevOps rola lidera kultury jest rzeczywiście ważna, szczególnie w zakresie jego wpływu oraz umiejętności przywódczych. W mojej ostatniej firmie początkowo panowała stosunkowo płaska hierarchia oraz atmosfera zaufania między kolegami, co znacznie ułatwiło moją misję promowania kultury.
Odpowiadając na konkretne pytanie, co można zrobić dla dobra DevOps. W moim wystąpieniu na główna myśl jest taka, że aby rozwijać kulturę DevOps, należy angażować się nie tylko w technologie w infrastrukturze, ale także w wewnętrzny coaching oraz rozdzielanie odpowiedzialności w procesach technicznych.
Na przykład, poświęciliśmy dwa miesiące pracy jednego inżyniera na stworzenie platformy dla serwerów QA i PR na potrzeby programistów i testerów. Jednak cała ta niezwykła praca przepadnie, jeśli informacje o możliwościach nie będą przekazane w sposób poprawny, funkcje nie zostaną udokumentowane, a szkolenie pracowników nie zostanie zakończone. I odwrotnie, po dobrze przeprowadzonych warsztatach i sesjach programowania w parach, zdeterminowany inżynier jest zainspirowany nową, przydatną funkcjonalnością i sam stawia czoła kolejnym problemom związanym z platformą infrastrukturalną.
Jeśli masz więcej pytań o DevOps, oto , w którym Misza szczegółowo odpowiada na pytania „Po co potrzebny jest DevOps?” oraz „Czy należy tworzyć specjalne działy DevOps w firmie?”
O rozwoju
Na swoim kanale czasem rekomendujesz profesjonalne artykuły i blogi. A czy masz jakieś ulubione książki fikcyjne?
Tak, staram się znajdować czas na czytanie literatury pięknej. Nie mogę czytać konkretnego pisarza po kolei, powieść za powieścią, więc mieszam rosyjskie i zagraniczne utwory. Z rosyjskich autorów bardziej podoba mi się Pelevin i Dowłatow, ale również lubię czytać klasykę XIX wieku. Z zagranicznych autorów przemawiają do mnie Remarque i Hemingway.
Wspomniałeś dużo o podróżach, a w podsumowaniach roku 2018 napisałeś, że odwiedziłeś 12 krajów i 27 miast. To niesamowity wynik! Jak udaje ci się łączyć pracę z podróżowaniem?
W rzeczywistości wszystko jest wystarczająco proste: trzeba dobrze wykorzystać dni urlopu, weekendy i święta, a dodatkowo aktywnie podróżować w trakcie wyjazdu 🙂
Nie jestem cyfrowym nomadem i nigdy nie pracowałem zdalnie na stałe, ale czasu na podróże w wolnym czasie, moim zdaniem, jest wystarczająco dużo, aby odkrywać świat. Sytuacja poprawiła się po przeprowadzce do Berlina: jest on położony w centrum Europy i mam więcej dni urlopu.
Próbowałem również podróżować przez miesiąc między starą a nową pracą, ale dla mnie nawet miesiąc w podróży wydaje się zbyt długi. Z tej podróży staram się brać urlopy trwające tydzień lub półtora, aby można było wrócić do pracy w miarę bezboleśnie.
Jakie trzy miejsca podobały ci się najbardziej i dlaczego?
Jako backpacker z krajów, najbardziej podobają mi się Portugalia, Oman i Indie. Portugalia jest atrakcyjna z perspektywy europejskiej historii i cywilizacji, takiej jak architektura, język, kultura. Oman zachwyca niesamowitą gościnnością i przyjaznością lokalnych mieszkańców, a także atmosferą względnego zrelaksowania pośród napięć Bliskiego Wschodu. O Omanie nawet napisałem . Indie są ciekawe dzięki różnorodności życia wewnątrz regionów i tożsamości kulturowej, ponieważ era planety Starbucks i galaktyki Microsoft, spisana przez Palahniuka, jeszcze ich nie dotknęła. Bardzo podobają mi się także Bangkok i północna część Tajlandii. Południowa część z morzem, wyspami i półwyspami wydała mi się zbyt turystyczna.
Notatki Miszy o podróżach można poczytać w jego kanale na Telegramie
Jak udaje Ci się utrzymać równowagę między pracą a życiem prywatnym? Podziel się sekretami 🙂
Nie mam tutaj jakiegoś specjalnego sekretu. Zarówno w Rosji, jak i w Niemczech normalne firmy technologiczne dają Ci możliwość zorganizowania czasu pracy tak, jak Ci wygodnie. Zazwyczaj nie siedzę w pracy do późna, jeśli serwis działa stabilnie i nie pojawia się jakiś kryzys. Po prostu dlatego, że po 17-18 mój mózg nie reaguje zupełnie na wezwania do działania i prosi o odpoczynek oraz dobry sen.
Prawie wszystkie rodzaje zawodów w branży tech — od programowania po design — są zawodami kreatywnymi, które nie wymagają dużej ilości godzin pracy. Wydaje mi się, że crunch w ogóle jest szkodliwy dla pracy kreatywnej, ponieważ ostatecznie zaczynasz myśleć wolniej i robisz mniej niż mógłbyś bez nadgodzin. 4-6 godzin aktywnej pracy w flow — to naprawdę dużo, bez przerwy i zmiany kontekstu można osiągnąć wiele.
Mogę także polecić dwie książki, które mi pomogły: od chłopaków z Basecamp i od Maksima Dorofiejeva.
Teraz wielu ludzi rozmawia o wypaleniu. Czy czułeś coś podobnego? Jeśli tak, to jak sobie z tym radzisz? Jak sprawiasz, że swoją pracę uczynić ciekawszą?
Tak, szczerze mówiąc, wciąż czasami odczuwam wypalenie. To logiczne, z filozoficznego punktu widzenia wszystko, co ma skłonność do płonięcia, ostatecznie gaśnie 🙂 Można walczyć ze skutkiem, ale wydaje mi się, że o wiele ważniejsze jest zidentyfikowanie przyczyny wypalenia i jej usunięcie.
Przyczyny są różne: dla niektórych to nadmiar informacji, niektórzy przepracowują się w głównym zawodzie, są sytuacje, gdy fizycznie nie zdążasz połączyć pracy, hobby i życia towarzyskiego. Czasami po prostu nie czujesz nowych wyzwań w swoim życiu i zaczynasz się tym martwić. Większość problemów można rozwiązać, przemyślając swoją filozofię życiową, osobiste wartości oraz rolę pracy w twoim życiu.
Ostatnio prawie nie doświadczam utraty zainteresowania pracą ani nudnych zadań. Istnieje wiele technik, jak uczynić nudną pracę ciekawą, część z nich zaczerpnąłem z mojego przyjaciela Kirilla Shirinkina. Ale staram się rozwiązywać ten problem na poziomie przyczyny, po prostu wybierając pracę, która oferuje maksymalną ilość wyzwań dla mojej kariery i osobowości oraz minimalną biurokrację organizacyjną.
7 grudnia Michaił wystąpi na konferencji z wykładem „Wszyscy jesteśmy DevOps”, w którym wyjaśni, dlaczego ważne jest skupienie się nie tylko na sposobie wdrażania najnowszego stosu technologicznego, ale także na kulturowym aspekcie DevOps.
W programie również: Baruch Sadogurski (JFrog), Aleksandr Czistjakow (vdsina.ru), Roman Bojko (AWS), Pawel Selivanow (Southbridge), Rodion Nagornow (Laboratorium Kasperskiego), Andriej Szorin (konsultant DevOps).
Przyjdź się poznać!
Źródło: habr.com
