– Samo bycie w takim środowisku powoduje, iż człowiek się rozwija, zaczyna widzieć pewne wzorce i podejścia jakie warto stosować w środowisku pracy – powiedział nam Dawid Weltrowski-Knopik, który przez 3 lata pracował w Facebooku (Mecie), a dziś jest Software Engineer w firmie Atlassian. Opowiedział nam o tym, jakie wartości ceni w tego typu organizacjach.
“Język programowania to tylko narzędzie” – powiedziałeś przed wywiadem. Organizacje takie jak Meta i Atlassian mają takie samo podejście?
Dokładnie tak, obie te organizacje są znane z takiego podejścia do języków programowania. Mówiąc to, jednak trzeba wyjaśnić pewne kwestie co do dokładnego znaczenia tego stwierdzenia. Samo traktowanie języka programowania jako narzędzie nie oznacza, iż jako pracownik mogę samodzielnie zdecydować jaka technologia zostanie użyta do rozwiązania danego problemu. Są wyznaczone pewne firmowe zasady, które wskazują jakie języki programowania są dozwolone w danej firmie i do jakich projektów zaleca się ich używanie. Reguły takie istnieją, gdyż zbyt duża mieszanka technologiczna spowolni rozwój firmy i zwiększy tech debt na dłuższą metę.
Dużą zaletą obu firm jest fakt, iż podczas rekrutacji sprawdzają wiedzę rozwiązywania problemów, niezależnie od języka programowania z jakiego korzystasz. Co za tym idzie, przed rekrutacją kandydat może zdecydować w jakim języku programowania chce przechodzić proces. Tym sposobem właśnie traktują one język programowania jako narzędzie, a potencjalnych pracowników jako osoby, które mogą się nauczyć używania tych narzędzi w pracy.
Co to tak naprawdę oznacza? Z czym wiąże się to podejście wyboru języka programowania?
To nie jest do końca tak, iż do dowolnego problemu podchodzimy wykorzystując dowolny język programowania. Są języki, które są stworzone do działania lepiej w pewnych projektach niż w innych. Przykładowo, o ile istnieje konieczność bardzo wysokiej wydajności systemu to nie będziemy używali do tego Javascriptu. Przykładem mogą być bazy danych i rozwiązanie o nazwie Cassandra, które zostało napisane w Javie. Natomiast po stworzeniu Cassandry, niektórzy uznali, iż taki rodzaj bazy danych może lepiej działać w języku C++ i powstała ScyllaDB. Jest to jeden z wielu przykładów pokazujących, iż wiele języków programowania może zostać użytych do stworzenia podobnych oprogramowań. Nie zawsze jednak chodzi o wydajność.
Warto wziąć pod uwagę też doświadczenie ludzi w zespole oraz deadliny projektowe. o ile wszyscy w zespole mają doświadczenie z Pythonem, a alternatywą jest Rust, którego każdy musi się nauczyć od zera, to trzeba sobie odpowiedzieć na pytania takie jak np. “Czy potrzebujemy szybkości Rusta do naszego projektu?”. Można by więc zmienić nieco oryginalne stwierdzenie na “Do dowolnego problemu podchodzimy wykorzystując jeden z odpowiednich (spełniających nasze potrzeby) języków programowania”.
Nie można też zapominać o różnicach pomiędzy projektami greenfield i brownfield. Przy projekcie greenfield wybór dowolnego języka programowania brzmi fantastycznie, gdyż zaczynamy od zera i możemy sami zdecydować o wielu aspektach tego projektu. Przy projektach brownfield, często nie jest opłacalne przepisanie projektu na nowy język programowania.
Czego jeszcze nauczyła Cię praca w dużych organizacjach?
Praca w dużych organizacjach znacznie różni się od pracy dla małych firm czy startupów. Poznałem ludzi, którym nie przypasowała praca w dużej organizacji i ostatecznie wrócili do środowiska startupowego. Większość mojej kariery przepracowałem w dużych organizacjach i jest kilka aspektów, które mogą posłużyć za dobre lekcje.
Standardy są ważniejsze niż nagłe wizje i trendy. Dołączając do startupu, często mamy możliwość wpłynięcia na firmę. Na jej kulturę, sposób pisania kodu czy chociażby używane biblioteki i sposób onboardingu. W dużych firmach często ważniejsze jest, aby śledzić już wyryte standardy. Dzięki takiemu podejściu otrzymujemy spójność i prostotę dzielenia się kodem w całej firmie oraz łatwość dla nas samych w analizowaniu i zrozumienia czyjegoś kodu. Oczywiście duże firmy też śledzą trendy, ale zanim nastąpi taka zmiana, musi to przejść przez wiele szczebli i musi zostać odpowiednio zaplanowane.
Aby dokonać zmiany, musisz sam o nią zawalczyć. o ile chcesz zobaczyć jakąś większą zmianę w firmie, to nie wystarczy poruszyć tego tematu na spotkaniu i liczyć na to, iż temat ruszy dalej. choćby o ile spodobał się większości. Trzeba samemu podjąć akcję, przygotować się i przeprowadzić więcej spotkań, przygotować dokumenty itd. aby przekonać innych do danego pomysłu. Oczywiście duże firmy mają mnóstwo różnorodnych procesów i ścieżka zawsze będzie inna.
Tak jak języki programowania, faktyczne narzędzia i systemu z jakich korzystamy w pracy się zmieniają. Nie warto przyzwyczajać się do jednego narzędzia, a raczej zrozumieć podstawy ich działania. Dołączając do Mety, przedstawiono mi infrastrukturę narzędzi, programów i rozwiązań, których nie znajdziesz nigdzie indziej. Są one podobne do innych, ale jednak nie identyczne. Koniec końców, nowe rozwiązania są tworzone i będą zastępowały stare, a my jako pracownicy będziemy musieli się ich nauczyć. To samo wiąże się ze zmianą pracy. Uważam, iż warto skupić się na nauce, jak coś działa i jakie problemy rozwiązuje, a nie tylko na tym, jak je obsługiwać.
Procesy ewaluacji pracowników przez cały czas nie są proste. Po tylu latach, duże firmy dalej regularnie zmieniają swoje procesy sprawdzania, jak dobrze sprawdził się pracownik przed dany okres. Powodem ciągłych zmian może być dynamiczna sytuacja na rynku w ostatnich latach (dużo zatrudnień, potem zwolnienia powodują potrzebę zmian procesów). Koniec końców, o ile nie chcesz przegrać z procesem i dobrze sobie radzić podczas ewaluacji, to warto wykonać pewne przygotowania. Po pierwsze, o ile firma prowadzi jakiegoś rodzaju widoczne statystyki to czasem może istnieć potrzeba dopasowania się do nich. Nie jestem fanem tego rozwiązania, ale przy dziesiątkach tysięcy pracowników, jest to niestety jedna z metryk i warto mieć to na uwadze. Po drugie, nie tylko trzeba wykonywać swoją pracę, ale też tworzyć swój dokument na performance review na bieżąco. Dopisywać wykonane zadania, interesujące aspekty z nich, co zostało naprawione, jaki był impact tego itd. To pozwala podejść do procesu przygotowanym i nie martwić się potem o zapełnienie dokumentu w kilka dni. Finalnie dodam, iż warto konsultować z managerem, który ma często więcej informacji o procesie niż my sami.
“Dokument na performance review” – ciekawe. Opowiesz coś więcej? W jaki sposób przedstawiasz, co udało Ci się zrobić?
Dokumenty tego typu różnią się w zależności od firmy. Niestety nie ma uniwersalnego rozwiązania. W przypadku programisty, musimy skupić się na kilku osiach. Mogą to być przykładowo:
- Impact,
- Engineering Excelence,
- Direction,
- People.
Częścią procesu jest zaplanowanie swojej pracy tak, aby zdobyć osiągnięcia w każdej osi. Priorytet danej osi jest zależny też od poziomu pracownika.
Nie zawsze mamy podany dokładny wzór dokumentu na proces performance review. Co za tym idzie, dokument tworzony przed procesem powinien być elastyczny. W moim przypadku, dzielę taki dokument na te 4 przykładowe osie, następnie o ile wykonam większe zadanie, które było na tyle znaczące, iż dodanie wewnętrznego posta o nim ma sens, to wejdę w taki dokument, i dodam go pod jedną lub kilkoma osiami (bo tak też można), opiszę co zostało rozwiązane, jak i dlaczego ma to znaczenie dla tej osi.
Innym przykładem jest sytuacja, gdzie jesteś on-callem, lub po prostu coś się zepsuło w produkcji i naprawisz taki problem. Często ma to znaczenie i jest czymś wartym udokumentowania w takim dokumencie, żeby nie zapomnieć później przy faktycznym procesie.
Tak przygotowany dokument wstępny, powinien bez problemu przygotować każdego do sprawnego przejścia przez finalny proces, poprzez przeklejenie z mniejszymi lub większymi poprawkami już przygotowanych opisów.
Czym kierujesz się szukając nowego pracodawcy, wybierając nowe miejsce pracy?
To czym kieruję się podczas szukania pracodawcy zmieniało się wraz z moim doświadczeniem. Początki wyglądały podobnie jak w dzisiejszych czasach, czyli po ukończeniu studiów szukałem pracy na pozycji programisty w branży. Tutaj nie stawiałem wysokich wymogów, gdyż nie posiadałem jeszcze doświadczenia i raczej liczyłem na to, iż firma da mi szansę.
Przed rozpoczęciem szukania nowego miejsca pracy zacząłem podążać trochę za tak zwanym American Dream i chciałem pracować w jednym z tech gigantów (FAANG), co mi się udało i po przejściu procesu rekrutacyjnego trafiłem do Facebooka. Po dołączeniu do jednej z najbardziej pożądanych firm w branży, długo rozmyślałem nad kolejnym krokiem i czym powinienem się kierować przy kolejnym kroku w karierze.
Po trzech latach, zmieniłem pracę na moją aktualną, czyli Atlassian. Tym razem, poszedłem w kierunku znalezienia interesującego mnie projektu, miejsca pracy typu people-first, gdzie wartości firmy mi odpowiadają i mogę pracować komfortowo.
Narazie nie mam planów na zmianę pracodawcy, ale o ile kiedyś to się wydarzy to aktualnie staram się dopasować firmę do takich wartości:
- praca zdalna,
- people-first,
- dobrze rozplanowana praca asynchroniczna,
- ciekawy projekt (subiektywne).
Taki zestaw wartości pojawia się często w naszych wywiadach, ale nie zawsze definicje tych określeń są takie same. Co rozumiesz poprzez “firma people-first”?
Zgadzam się, iż nie ma jednej uniwersalnej definicji dla firmy people-first i często słowo to jest używane jako chwyt marketingowy. Dla mnie osobiście firma people-first powinna posiadać cechy takie jak:
Elastyczne godziny pracy – nie mówię tutaj też tylko o możliwości zaczęcia godzinę później/wcześniej, ale o dużej elastyczności z ewentualnymi wymaganymi core hours dla on-calli i spotkań synchronicznych typu standup. W życiu zawsze może coś wypaść i fakt, iż pracownik wyjdzie na godzinę czy dwie, nie powinien być problemem, o ile istnieje linia zaufania między pracownikiem i firmą.
Cele wynikowe – najlepsze teamy i firmy skupiają się na wynikach, a nie na czasie, jaki pracownik przesiedzi na krześle przed monitorem. Trzeba ustalać cele, ocenić i wprowadzić poprawki wedle potrzeb.
- Praca zdalna – są wyjątki, ale często miejsca, gdzie faktycznie chodzi o ludzi, nie mają z tym problemów i są do tego przystosowani. Uważam, iż dla większości ról programistycznych nie ma potrzeba pracy stacjonarnej. Trzeba jednak wziąć pod uwagę, iż pewne procesy trzeba dostosować pod pracę zdalną i nie każda firma jest na to chętna lub miała złe doświadczenia w przeszłości. Nie oznacza to automatycznie, iż firma nie jest “people-first”.
- Komunikacja asynchroniczna – często firmy nie są do tego przystosowane i stąd są memy typu “to spotkanie mogło być mailem”. Często nie ma potrzeby zapraszania całego zespołu na regularne spotkania, które nic nie wnoszą. o ile dobrze zaplanujemy asynchroniczną komunikację, to możemy zaoszczędzić czas, a choćby zwiększyć jakość.
- Transparentność – firmy, które są otwarte ze swoimi pracownikami, często są darzone większym zaufaniem. Otwarte mówienie o stawkach jakie są oferowane, jaka jest sytuacja finansowa firmy, jakie błędy firma popełniła itd. Świadczy to o otwartości i szczerości, a te cechy są bardzo doceniane w naszym społeczeństwie.
Każda z tych cech mogłaby być opisana znacznie dłużej, ale też nie jestem ekspertem w tej dziedzinie. Mogę jednak polecić stronę peoplefirstjobs.com (brak affiliacji z mojej strony), gdzie są wypisane firmy z ofertami pracy spełniającymi te “wymagania”.
Na koniec, powiedz proszę co dotychczas dało Tobie największy boost w karierze?
Uważam, iż profesjonalne doświadczenie jakie można zdobyć w praktycznej pracy jest niezastąpione. Praca w Mecie zwiększyła moją pewność siebie, miałem okazję poznać niesamowitych ludzi w Polsce, jak i za granicą oraz wiele się od nich nauczyć. Samo bycie w takim środowisku powoduje, iż człowiek się rozwija, zaczyna widzieć pewne wzorce i podejścia jakie warto stosować w środowisku pracy. Uważam, iż warto od początku budować relację ze swoimi współpracownikami. Daje to nie tylko komfort później podczas dyskusji technicznych, czy zadawania pytań, ale pozwala też znaleźć pewnego rodzaju mentora lub mentorów od których można się wiele nauczyć. Finalnie takie kontakty pozwalają po prostu na dalszy networking, choćby po odejściu z danej firmy. Do mojego obecnego pracodawcy Atlassiana, networking pozwolił mi sprawnie rozpocząć proces rekrutacyjny.
Dawid Weltrowski-Knopik. Software Engineer w firmie Atlassian. Ostatnie trzy lata pracował dla Mety (wcześniej Facebook) w podobnej roli. Większość kariery pracował jako fullstack z naciskiem na systemy backendowe, przy których się specjalizuje. Poza pracą interesuje się siłownią, samorozwojem i dobrymi grami komputerowymi.
