Ewa Maciaś , Software Engineering Manager, Google

 

ołączyłam do Googla dokładnie 10 lat temu, jako stażystka będąc jeszcze studentką informatyki na AGH. Miałam już wtedy około dwuletnie doświadczenie w pracy w innych firmach.

Moim zadaniem było zbudowanie interfejsu jednego z narzędzi Google. Pierwszą rzeczą, która mnie uderzyła w Google to to, że mimo, iż byłam stosunkowo młodą inżynierką, otrzymałam bardzo mało instrukcji, co do tego jak mam moje zadanie wykonać. Nikt nie powiedział mi jakiej technologii użyć, jak aplikacja ma działać, ani na kiedy ma być dostarczona. Dziś wiem, że tak po prostu działa Google: stawia się przed pracownikami problemy i prosi się ich by rozwiązali je najlepiej jak potrafią. Jest to dowód ogromnego zaufania co do kompetencji pracowników oraz daje duże pole do kreatywności i robienia rzeczy w sposób niestandardowy. W końcu wiele z problemów, które rozwiązujemy w Google nikt przed nami nie rozwiązywał.

Po stażu dołączyłam na pełny etat do działu zwanego Infrastrukturą Techniczną i jestem tam do dziś. Przez pierwsze kilka lat budowałam interfejs narzędzia, który udostępnia dane o użytkowaniu zasobów obliczeniowych takich jak dysk, procesory i pamięć serwerów Google. W tym projekcie miałam okazję obserwować sposób budowy dużych systemów przetwarzających informacje na dużą skalę.

Kolejnym produktem, który tworzyłam była aplikacja webowa będąca wewnętrznym narzędziem dla inżynierów w Google. Dziś jest ona używana przez większość inżynierów w ich codziennej pracy. Projekt ten był prowadzony przez fantastycznego menedżera, który miał jasno określoną wizję produktu i potrafił nas zmotywować i zainspirować. Nauczyłam się, że jedna osoba może wpłynąć na pracę ogromnej części firmy.

W 2014 roku dołączyłam do zespołu Google Cloud Platform. Niedługo przedtem objęłam rolę menadżerki. Wtedy po raz pierwszy poczułam, że pracuję w naprawdę dużej organizacji. Chcąc oferować swoje usługi dużym klientom, nasz zespół miał bardzo dużo do zrobienia. Wymagało to silnego zarządzania całą organizacją, ale też bardzo intensywnego wysiłku od każdego z biorących udział w projekcie. Przede wszystkim poprzez bardzo agresywne priorytetyzowanie pracy, tak aby robić to czego klienci najbardziej w danej chwili potrzebują.

Zespół, który prowadziłam bardzo szybko urósł z kilku do kilkudziesięciu osób. Wielu pracowników było wtedy nowych w Google, nierzadko ze stosunkowo małym doświadczeniem w innych firmach. Prowadzenie dużego zespołu było dla mnie zupełną nowością, uczyłam się robiąc to, nierzadko na błędach.

Praca w Google to nieustająca lekcja, bo moja rola zmienia się dość mocno co około 2 lata. Pojawiają się nowe obowiązki, które sprawiają, że wciąż muszę uczyć się nowych umiejętności. To trudne, ale daje też ogromną satysfakcję.

Gdybym miała wskazać czynnik, który najbardziej pomaga mi w mojej pracy i rozwoju kariery, to zdecydowanie powiedziałabym, że są to ludzie, z którymi pracuję. Nie sposób wymienić wszystkich, ale chcę wspomnieć mojego długoletniego menadżera, który miał kluczową rolę w kształtowaniu mojej kariery. Stawiał on przede mną zadania, które zawsze były odbierane przeze mnie jako zbyt trudne. Jednocześnie też dostarczał mi bardzo dużo wsparcia.

Bardzo też cenię sobie wsparcie mentorów. Korzystam regularnie z pomocy osób z dłuższym stażem pracy, którzy stosunkowo niedawno byli w roli podobnej do mojej. Jest to praktyczny sposób na popełnianie mniejszej liczby błędów, albo też – uczenia się dzięki ich doświadczeniu.

 

Jakub Onufry Wojtaszczyk , Senior Staff Software Engineer, Google

 

racuję w Google od około siedmiu lat. Przyszedłem do firmy bez żadnego doświadczenia zawodowego, z doktoratem z rachunku prawdopodobieństwa i kilkoma osiągnięciami w konkursach programistycznych. Zaczynałem ucząc się od zera najprostszych rzeczy – już w Google napisałem swoje pierwsze zautomatyzowane testy, i poznałem procesy tworzenia oprogramowania w większym zespole.

Przez pierwszy rok pracowałem w Krakowie, nad silnikiem bazodanowym Supersonic (dostępny dla wszystkich na otwartej platformie Github, pod adresem google/supersonic). Zaczynałem od dość konkretnych, drobnych zadań, które pozwoliły mi lepiej poznać nasz kod (i zacząć samodzielnie proponować ulepszenia); po pół roku zająłem się trudniejszym zadaniem wdrożeniowym – wykorzystaniem naszego silnika w systemie do wyliczania sprawozdań finansowych dla całej firmy.

W ciągu tego roku dużo się nauczyłem – zarówno elementarnego rzemiosła programisty, jak i tego, jak organizować pracę swoją i innych – pod koniec prowadziłem trzyosobowy zespół, który w ciągu kwartału miał poprawić stabilność całego systemu.

Po roku przeniosłem się do nowo otwartego biura w Warszawie. Tu we czterech stworzyliśmy oddział zespołu, którego główna część znajdowała się w siedzibie Google w Kalifornii. W przeciwieństwie do Supersonic’a, którego większość twórców siedziała koło mnie, system, nad którym wtedy pracowałem miał około osiem lat, a większość jego twórców od dawna zajmowała się czymś innym. Przez pierwsze pół roku bardzo często poruszałem się po omacku, starając się zrozumieć, co dokładnie się dzieje.

Przez dwa lata nauczyłem się dużo o pisaniu kodu, który nie ma prawa nie działać – na naszym systemie opierają się wszystkie większe serwisy Google (w tym wyszukiwarka, YouTube czy Gmail). Dowiedziałem się też wiele o prowadzeniu zespołu – zostałem jednym z trzech liderów całego, rozproszonego zespołu. Tymczasem nasz system postarzał się o kolejne dwa lata, i zaczęliśmy (wraz z dwoma liderami z USA) rozważać napisanie jego drugiej wersji.

Pisanie drugiej wersji trwało kolejne dwa lata, i ostatecznie jej nie wdrożyliśmy – uznaliśmy, że ryzyko jest zbyt duże. Dla mnie była to olbrzymia okazja do nauki – zarówno w prowadzeniu zespołu (w pewnym momencie nad nową wersją pracowało 10 osób, którymi kierowałem), jak i o trudnościach wdrażania nowych systemów i przekształcania starych czy o tym, jak podejmowane są trudne decyzje przy bardzo niepełnych danych. Patrzenie jak inni inżynierowie i menedżerowie atakują niedodefiniowane problemy (przykładowo, czy warto wdrażać naszą nową wersję systemu, albo – jeśli tak – jak to zrobić) było dla mnie niesamowicie cennym doświadczeniem.

Nowa wersja, pomimo, że jej nie wdrożyliśmy, posłużyła za wzorzec dla przekształcania starej wersji kodu – bo problemy, które próbowaliśmy rozwiązać przepisywaniem, nie zniknęły same w ciągu tych dwóch lat. Następne półtora roku kierowałem dziesięcioosobowym zespołem, którego zadaniem było wprowadzić kluczowe rozwiązania (model wielowątkowości, abstrakcje, modularyzacja) naszej nowej wersji do wersji starej (co ostatecznie zakończyło się sukcesem). Patrząc wstecz, doceniam kulturę panującą w Google – niepowodzenie pierwszego podejścia nie było winą, którą trzeba było kogoś (np. mnie) obciążyć, a raczej doświadczeniem, z którego wyciągnęliśmy lekcję; niepowodzenie nie było też problemem dla mojej kariery – przeciwnie, dzięki temu, że druga wersja projektu się udała otrzymałem kolejny awans.

Po tym czasie uznałem, że pora na nowe wyzwania – po pięciu latach spędzonych w czeluściach naszych systemów, blisko jądra Linuxa, stwierdziłem, że pora nauczyć się czegoś nowego, i od ponad pół roku zajmuje się interfejsem użytkownika w usłudze Google Cloud Platform, czyli platformie chmurowej dla biznesowych klientów firmy.

Z perspektywy czasu, chyba najważniejszą rzeczą, której nauczyłem się ostatnio jest bezlitosne ograniczanie tego, co chcę osiągnąć – nie poprawianie wszystkiego, co można by poprawić, a cały czas zwracanie uwagi na to, czy praca, którą wykonuję ja lub mój zespół jest kluczowa dla projektu czy długoterminowego planu. Zdobyłem też – doświadczeniem własnym i cudzym – dużo wiedzy o tym, jakie rozwiązania techniczne działają lepiej, a jakie gorzej. Mam teraz bardzo bogaty zestaw narzędzi programistycznych i projektowych, którymi mogę się posługiwać. Mimo, że jestem – formalnie, według wewnętrznych stopni – najbardziej doświadczonym inżynierem w warszawskim biurze, wciąż uczę się bardzo dużo od ludzi wokół siebie – zarówno technicznie, jak i organizacyjnie.