Microsoft składa się ze 100 małych startupów. Poznaj historię Kuby Jędryszka – część 2
Jak od środka wygląda praca w Microsofcie? Jaką dowolność w wyborze narzędzi, frameworków mają programiści oraz w jaki sposób realizują własne pomysły na nowe produkty? Tego dowiecie się z dzisiejszej rozmowy, która jest transkrypcją live-streamów z programistami z całego świata. Na pytania odpowiadał Jakub Jędryszek, Software Engineer w Microsoftcie.
Jakub pracuje dla Microsoft w głównej siedzibie w Redmond. Od 2014 jest zaangażowany w pracę nad nowym portalem Azure. W chwili obecnej większość jego uwagi jest skupiona na aplikacji mobilnej Azure, pozwalającej zarządzać zasobami chmury Microsoftu. Od czasu do czasu można go spotkać na konferencjach w różnych częściach świata (od USA, przez Europę aż po Chiny i Australię). Przed Microsoftem Jakub studiował na Politechnice Wrocławskiej i Uniwersytecie Ekonomicznym, gdzie uzyskał tytuły inżyniera i licencjata. W trakcie studiów pracował przez rok we Wrocławiu, a potem wyjechał do USA studiować na Kansas State University, gdzie prowadził badania nad statyczną analizą kodu dla urządzeń medycznych. W wolnych chwilach jeździ na rowerze, pływa, biega, startuje w triathlonach, chodzi po górach i podróżuje.
Jak się okazało, nie było wcale to takie łatwe, a jego przykład dobitnie pokazuje, że droga do otrzymania pracy w Stanach, nawet dla wykwalifikowanych specjalistów, często bywa dość długa i nieco karkołomna. Zapraszamy do długiej lektury z naszej rozmowy z nim (pierwszą część rozmowy znajdziesz tutaj):
Spis treści
Piotr Nowosielski: Jak przeszedłeś z Research Labu do Microsoftu? Praca na uczelni Cię nie zainteresowała, czy wiedziałeś, że to jest początek, przystanek przed większymi wyzwaniami?
Jakub Jędryszek (JJ): Praca była ciekawa, ale dla mnie największym problemem było to, że pracowaliśmy nad narzędziem do generowania bezpiecznego kodu na podstawie modeli w języku ADL, prawdopodobnie niewiele ludzi o nim słyszało. (…) Największy problem był taki, że generowaliśmy to w języku Ada, który był bardzo często używany w samolotach (jak np. latacie boeingiem 737 czy 777 to większość jego softu jest napisany w Adzie, dlatego, że ten język bardzo dobrze sprawdza się w niezawodnych systemach).
Chciałem zobaczyć jak inne urządzenia medyczne są zaimplementowane, jak wygląda ten kod. Problem był taki, że kod tego typu urządzeń objęty był tajemnicą, trudno było go sprawdzić. (…) Potrafiłem za to opracować prototyp pompy do znieczulania dla pacjentów po operacji, by łatwiej było dozować morfinę czy inne środki. Było to ciekawe zagadnienie, ale rezultat byłby widoczny w dalekiej przyszłości. Profesor powiedział mi kiedyś, że cel jest taki, aby za 10-20 lat wszystkie tworzone urządzenia medyczne były kompatybilne do tej architektury.
Piotr: Wymagało to cierpliwości.
Jakub: Pomyślałem sobie, że nie chcę czekać 20 lat na efekt mojej pracy.
Piotr: Nie rozbudziło to Twojej wyobraźni? Jak rozumiem profesor, niechcący, przekonał Cię do tego, by szukać czegoś innego?
Jakub: To jest zależne od tego, co kto chce. Współpracowałem z kolegą, który robił doktorat i pracował w firmie już 7-8 lat. Jemu ta praca bardzo się podobała. Nie był zainteresowany pójściem do dużej korporacji jak Microsoft czy Google, żeby klepać kod. Było to ciekawe, była to jakaś innowacja, tylko że nikt się nią nie interesował. Chciałem spróbować raczej czegoś innego.
Kamil Kollman: Powiedziałeś o tej perspektywie, że ktoś może nie chcieć pracować w dużej korporacji. Podejrzewam, że w Stanach ta skala może być inna. Do jakiego rozmiaru zespołu uznałbyś, że to nie jest korpo, ale startup czy softwarehouse? Może nie tyle o mniejszym zasięgu, ale o specyficznej strukturze. Chciałbym to porównać z polskimi realiami.
Jakub: Na pewno takie firmy jak Microsoft, który zatrudnia ponad 100 tys. ludzi, Google z 30 tys. pracowników, czy Uber mający chyba 10 tys. osób na pokładzie, są postrzegane jako korporacja. Niektórzy mówią, że jest to “late startup”, ale firmy te mają swoje oddziały, które rekrutują ludzi bez wiedzy CEO, kto kim jest. Przez to początkujący lądują w zespole, w którym nikogo nie znają i nie do końca wiedzą, co będą robili. Ciężko jest zarysować taką granicę, ja myślę, że jeśli firma jest na rynku ponad 10 lat i ma ponad 10 tys. ludzi w zespole, to już nie jest startupem.
Kamil: Bardziej się zastanawiałem czy patrząc na perspektywę rynku w Stanach Zjednoczonych, który jest znacznie większy niż w Polsce, myśląc o firmie do 100 osób, w przedziale 50-100 osób, to dla ciebie już duża firma czy płotka, która ginie?
Jakub: To zależy od przypadku. Basecamp zatrudnia do 100 osób, ale dostał spore finansowanie i działa na rynku ponad 10 lat. Są cały czas małą firmą, pewnie większość ludzi się tam zna nawzajem, można powiedzieć, że jeszcze są startupem, ale idą w kierunku dużej firmy.
Kamil: Może specjalnie są na etapie startupu?
Jakub: Tak, ich celem jest żeby nie urosnąć za bardzo, bo wtedy wychodzi to poza kontrolę. Tak się stało ze StackOverflow i to już jest startup na końcowym etapie. Jak się zatrudnisz w tej firmie, to na pewno nie będziesz znał wszystkich jej członków.
Na pewno jak się pojedzie do San Francisco czy pracuje się w 10-20 osobowej firmie, to można uznać, że jest to startup. Są też firmy, które istnieją na rynku ponad 10-15 lat i dalej nazywają się late startupem. Koniec końców taka firma zmierza w stronę korporacji niż startupu. Co miałem na myśli mówiąc, że ktoś może nie chcieć pracować w korporacji? W takiej firmie mniej zależy od Ciebie. Im jest mniejsza, tym więcej od ciebie zależy. Jeśli jesteś CEO dużej korporacji, to wtedy wszystko od ciebie zależy, ale jeżeli jesteś studentem, to zaczynasz od dołu i wtedy masz bardzo mały wpływ na to co się dzieje.
Piotr: Podejrzewam, że ten poziom korporacji zaczyna się w momencie, kiedy okazuje się, że nie znasz wszystkich ludzi w firmie. Kiedy kogoś nowego zatrudniają, a ty nawet nie wiesz jak to działa, jakie rzeczy dzieją się poza Tobą. Podejrzewam, że wtedy firma nabywa takich cech korporacyjnych. Rozmawiałem z różnymi developerami i innymi osobami, które pracują w branży IT i według nich taki poziom jest mniej więcej już przy 30-40-50 osobach, kiedy wszystko się dzieli na procesy a ludzie mają pewne swoje miejsce. Często jest tak, że ktoś z kimś pracuje równolegle na jednym piętrze, ale się nie zna i zatracamy tę naturę pracy jak jedna wielka rodzina, tylko jesteśmy już jak ten Microsoft.
Jakub: Nie możemy podchodzić do tego tak zero-jedynkowo, że to jest korpo a to startup.
Piotr: To powiedz, co Microsoft nie ma z korporacji? Jak próbuje sobie z tym radzić? Podejrzewam, że to jest trudne mając 100 tys. pracowników, ale jak to działa u was?
JJ: Generalnie Microsoft to tak jakby 100 małych startupów.
Myślę, że w Microsoft jest ok 30 tys. developerów, jest dużo ludzi w dziale sprzedaży, duża część zespołu pracuje przy usługach czy przy biznesie. Generalnie to tak działa, że w Microsofcie wiele zespołów znacząco różni się od siebie. Jeżeli ktoś pracuje przy office, jeżeli ktoś pracuje przy jakimś code base, który ma już kilkadziesiąt lat, to jest zupełnie inaczej, jak ktoś kto jest w teamie pracującym nad nowym produktem. Tak naprawdę w Microsofcie zależy od tego, w jakim jesteś zespole. Niektóre zespoły są zorientowane bardziej startupowo.
Piotr: Mam pytanie do Kamila. Powiedz co wy robicie, żeby czuć się takim zespołem?
Kamil: Póki co nie mamy takiej sytuacji żeby pracownicy znali się tylko z widzenia. Druga sprawa jest taka, że mamy dobry kontakt nie tylko osobiście w biurze, ale też ze względu na to, że komunikujemy się na Slacku, dzięki któremu zawsze wiemy do kogo uderzyć odnośnie kodu. Dużo dają też organizowane spotkania, jako developerzy mamy spotkania techniczne, podczas których możemy podzielić się nowymi technologiami, które ktoś odkrył. I tu rodzi się pytanie do Kuby, bo wspomniałeś o tym, że przy takim kolosie jak Microsoft, pewna gibkość w podejściu do nowych projektów jest umiarkowana. Musicie stosować, podejrzewam, wypracowane standardy.
Piotr: Chciałem zapytać, czy nie brakuje Ci, Tobie jako developerowi, takiej wolności w stosowaniu zupełnie nowych rozwiązań przy konstruowaniu jakiegoś nowego projektu, czy budowaniu jego założeń czy budowaniu architektury itd. Nie wiem na ile macie, jako programiści w Microsofcie, wolność do tego żeby stosować nowe rozwiązanie, czyli coś co nie jest standardem utartym nawet nie tylko w branży, ale w obrębie własnego podwórka.
Jakub: Jeżeli pracujesz przy utrzymaniu jakiegoś kodu, który działa od jakiś 20-lat to jeśli przyjdziesz i powiesz: “hej! przepiszmy to wszystko”, to może się nie udać.
Jeżeli pracujesz przy nowym projekcie, to wtedy tak. Na początku w Microsofcie pracowałem na stanowisku Management Portal Officer, w sumie cały czas jestem w tym zespole, ale teraz robię aplikację mobilną. Jak zaczynaliśmy prace nad nowym projektem, to mieliśmy wszystkie nowsze technologie. Popularny wtedy był Knockout.js, do zespołu dołączył jego twórca [Steve Sanderson] i w tej bibliotece pracowaliśmy razem przez dwa lata bodajże.
Działa to tak, że mamy mikroserwisy na frontendzie i mamy dużo różnych serwisów Azure’owych na portalu i każdy z tych serwisów działa w osobnym frameworku i one są deployowane niezależnie od tego, jak jest deployowany core portalu. Jest to coś naprawdę innowacyjnego, z 10 czy 20 patentów ludzie dostali za zrobienie tego wszystkiego. Także tak, tutaj jak najbardziej trzymamy się “starych technologii”, ale jeżeli ktoś nowy przyjdzie do zespołu i powie: wyrzućmy Knockouta i używajmy Reacta, to to nie przejdzie.
Nad portalem pracuje ok 300-500 osób i są to zespoły z całego Microsoftu, np. mamy wirtualne maszyny, więc ktoś z korowego Azure’a robi front-end do wirtualnych maszyn, są tony kodu napisanego w Knockout’cie i to działa. Jeżeli mielibyśmy rozpocząć wszystko od nowa, to nie byłoby to ani biznesowo dobre, ani optymalne rozwiązanie. Aczkolwiek widziałem, że niektóre zespoły, bo każdy może mieć taki stack jaki chce, musi używać naszego frameworka żeby się komunikować z portalem na koniec, ale mogą używać jakich chcą bibliotek u siebie.
Widziałem, że niektóre zespoły używają nawet jakichś bibliotek Reacta, także dopasowanie jest naprawdę duże. Tak jak my zaczynaliśmy aplikacje mobilną, generalnie to byłem ja i jeszcze jeden developer, i my wymyśleliśmy cały stack. Zobaczyliśmy co było na rynku, zrobiliśmy analizę, które rozwiązania mają największy sens i po konsultacjach z innymi ludźmi doszliśmy do wniosku, że zrobimy to i teraz robimy tę aplikację w Xamarinie.
Piotr: Korzystacie ze Slacka? Bo to narzędzie, które kilka lat temu wypłynęło i okazało się bardzo fancy wśród developerów. Czy jak rzucasz temat: korzystamy ze Slacka, to jest: okej, spoko, sprawdźmy! czy raczej: nie, mamy już 5 innych komunikatorów Microsofta i robimy to na tym, bo tu też możemy się porozumieć.
Jakub: Tak, są zespoły, które używają Slacka. Mój zespół używa Microsoft Teams, to jest generalnie taki Slack, ale lepiej zintegrowany ze stackiem Microsoftu. Ja mam tylko Microsoft Teams i tu mam swój kalendarz, swojego Slacka, gdzie mamy dyskusje, mam animowane gify, których chyba nie ma w Slacku, a co jest bardzo ważne, mam też integrację z OneNotem, który jest jednym z lepszych produktów Microsoftu.
Piotr: OneNote to naprawdę dobry produkt.
Jakub: Z tego powodu my używamy Microsoft Teams. Są różne zespoły, które używają Slacka, my też używamy VSTS do naszych tasków i bagów, ale są też zespoły, które używają Trello. Ale potem się tak dzieje, że jest Trello i jest fajnie, ale np. VSTS umożliwia ci coś takiego, że możesz sobie łączyć zadania ze zmianami w swojej historii kodu źródłowego, a Trello nie ma takiej funkcji. Koniec końców okazuje się, że integracja między produktami Microsoftu ma sens. Dowolność jest, ale zawsze są plusy w wybieraniu narzędzi do siebie.
Kamil: Zapytam od strony technicznej, bo mówiłeś o integracji między narzędziami Microsoftu. Biorąc pod uwagę dzisiejsze czasy, te technologie bardzo szybko się zmieniają. Czy miałeś w trakcie swojej pracy jakieś myśli, że może byś jednak podryfował w kierunku innej technologii? Czy nie myślałeś nigdy o przejściu ze środowiska SEALs, Azure’a, czy próbowałeś kiedyś zmienić ścieżkę, w której programujesz?
Jakub: Dokładnie tak się stało. Kiedy pracowałem nad tym nowym portalem, to chyba w lipcu 2015 w Microsofcie zorganizowano hackathon, który nazywa się One Week Hackathon. Podczas tego wydarzenia ktoś rzucił pomysł, żeby zrobić mobile lab dla Azure’a i mi się to bardzo spodobało. Razem z dwoma kolegami zrobiliśmy prototyp tego mobile laba i potem pokazaliśmy to naszemu liderowi – Scottowi Goeffrey’owi. Powiedział, że to super pomysł i musimy mieć taką aplikację mobilną, to dobry krok. Wtedy nie zaczęliśmy pracować nad tym od razu, bo byliśmy w takiej fazie, kiedy migrowaliśmy ze starego portalu Azure’a do nowego. (…)
Najpierw musieliśmy skończyć ten nasz portal. Wtedy zacząłem po nocach prototypować tę aplikację, bo generalnie budowanie tak na stacku active directory i Azure API, które się zmieniają cały czas, jest trochę bardziej skomplikowane niż mogłoby się wydawać, o wiele bardziej niż mnie się wydawało.
Miałem taki plan, żeby pokazać ten prototyp i miałem nadzieje, że coś z tego prototypu wyjdzie. W międzyczasie jednemu project managerowi udało się przekonać kogoś tam, że to teraz jest czas, aby zacząć znowu. Luck is what happens when preparation meets opportunity. Miałem gotowy prototyp szkicu tej aplikacji. Kiedy padło hasło, że startujemy, wtedy ten prototyp uruchomiłem, trochę go przebudowaliśmy i mieliśmy taką wersję 1.0, którą pokazaliśmy Scottowi. Generalnie pół roku od tego czasu, aplikacja była zaprezentowana na wystąpieniu podczas największej konferencji Microsoftu.
Wtedy też zmieniłem swoją pracę codzienną z web developer na mobile developer i generalnie przez własną inicjatywę, beż żadnych nacisków, że „Ty teraz będziesz robił to”. Wszystko jest możliwe, pamiętam, że w pierwszym roku jak tu pracowałem w tym zespole, to miałem jakiś pomysł żeby coś zrobić i powiedziano mi, że jeżeli chcę coś zrobić to mam to zrobić i tyle. Taka zasada jest don’t ask for permission beg for forgiveness…
Zazwyczaj jest tak, że jeżeli coś zrobisz i udowodnisz, że ma to sens, to zawsze to potem wygrywa. Jeżeli chodzisz i opowiadasz, że masz jakiś plan na to i tamto…
Piotr: To znaczy, że się nie przebijesz.
Jakub: Dokładnie. Wszystko jest możliwe, koniec końców kod wygrywa.
Piotr: Co do tego, że wszystko jest możliwe, to powiedz ile to trwa. Właśnie fajne pytanie zadał Mateusz na naszym czacie na YouTube, gdzie jest 100 osób – przy okazji bardzo dziękuję za taką frekwencję. Pytanie padło tego typu: ile trwa research możliwych rozwiązań przed stworzeniem tej aplikacji mobilnej. Ile czasu się przygotowywaliście do tego, zanim zaczęliście to tworzyć?
Jakub: Podczas hackathonu zbudowaliśmy Windows Phone App. Przy okazji polecam posłuchać mojej rozmowy z Maćkiem Aniserowiczem na temat aplikacji mobilnych. Tworzenie aplikacji mobilnej nie jest takie tanie, jak tworzenie aplikacji webowych. To nie jest tak, że sobie siadasz, instalujesz coś i to gra.
Musisz np. przy iOSie wykupić sobie licencje developerską, do pracy potrzebujesz też iPhonea. Na początku najtańszą platformą do programowania, był Windows Phone. Potem było tak, że jeden kolega był zainteresowany Reactem, stworzył prototyp na iOSa, w androidzie próbowaliśmy robić natywną aplikację i tak widzieliśmy, że React do tego średni jest.
Hackathon zbiegł się nieco w czasie z największym rajdem rowerowym w Stanach Zjednoczonych – z Seattle do Portland. Przed rajdem poznałem się w Jamesem Montemagno, który w Xamarinie był jednym z ludzi, którzy go promowali i był jednym z developerów mobilnych. Podczas rajdu rozmawiałem z Jamesem, na temat pomysłu zrobienia aplikacji mobilnej dla Azure’a i James polecił, żeby spróbowali Xamarina. Okazało się, że jako cross platforma, ale nadal native bardzo fajnie działał. Porównując trade-offy, native, Xamarine, czy Apache Cordova, rozmawiałem z różnymi ludźmi, którzy robili projekty i doszliśmy do wniosku, że Xamarin jest najlepszym rozwiązaniem.
Piotr: Okej, a ile to trwało mniej więcej?
Jakub: Ile trwało podjęcie decyzji? Ciężko powiedzieć, nie podjęliśmy jej z dnia na dzień. Na początku to było bawienie się z technologiami, prototypowanie, potem coś nam wyszło i uznaliśmy, że można to popchnąć dalej. Kiedy Scott powiedział, że to jest dobry pomysł, to wtedy poszliśmy o krok dalej. W tzw. “międzyczasie” pracowaliśmy nad swoimi sprawami. Był to trochę projekt po godzinach. Ja robiłem po nocy projekt w Xamarinie, aby sprawdzić czy w ogóle się nada do tego. Generalnie moje prototypowanie udało się i po rozmowie z managerem i ludźmi z zespołu uznaliśmy, że idziemy w Xamarine, bo wiemy, że jest to możliwe i nie będzie poważnych blokerów i nie będziemy musieli pisać tego samego kodu dwa albo trzy razy.
To druga część historii Jakuba, kolejną opublikujemy już niebawem, a w niej dowiesz się dokładniej, w jaki sposób rekrutuje programistów Microsoft.
Jakub Jędryszek był gościem drugiego cyklu live-streamów z programistami z całego świata. Całość możesz poznać w poniższym wideo: