Programista przy biurku czy praca zdalna? Część 1

Moją pierwszą (płatną) robotę programisty dostałem, gdy byłem na studiach. Jako że musiałem pogodzić studenckie obowiązki: chlanie, budowanie lepszego związku z moją poduszką (która bardzo za mną tęskniła, kiedy ja imprezowałem), a! i czasem jakieś wykłady, większość 'pracowego' kodu powstawała popołudniami, w domu, w trakcie przedawkowywania kofeiny. To było 'prawdziwe' programowanie, większość rzeczy tworzona była od zera, pisząc w różnych językach, kompilując na różne architektury itd.

Ta robota wymagała również kontaktów z klientami, siedzenie w siedzibie firmy, naprawiając sprzęt – na szczęście, to zdarzało się sporadycznie. Pewnie dlatego nie traktowałem tego zatrudnienia poważnie (i patrząc z perspektywy czasu na kasę, którą zarabiałem, mój szef też jej tak nie traktował). Później, po otrzymaniu dyplomu, pomyślałem, że fajnie byłoby zostać inżynierem oprogramowania dla dużej, prestiżowej firmy. Wycelowałem w jeden z największych megakorpów i zostałem przyjęty. Byłem zachwycony procesem rekrutacyjnym, pewnie dlatego, że był to mój pierwszy prawdziwy. Do poprzedniej zostałem przyjęty od kopa, nie mieli człowieka, który mógłby zmierzyć mój 'inżynierski talent'.

No i stało się. Centrum Badawczo-Rozwojowe megakorpo. Piękny budynek w centrum Warszawy. Dużo knajp dookoła, dostęp przez RFID, całkowity brak parkingów. Cudownie.

Ekipa była świetna. Gromadka geeków wychowana w czasach, kiedy świat konwertował się z analogów do ośmiu bitów. Wydawało mi się, że korpo wymagałoby więcej skromności i powściągliwości w rehackowaniu i refaktoryzacji kodu, który miał ponad 10 milionów linii. W sumie zastanawiam się, dlaczego nie puściłem cloca na tym wszystkim... Możliwe, że bym już skończył (dyski, corpo-ware, ogrom kodu = tragiczne IO). Sorry za dygresję. Po kilku miesiącach wgryzania się w kod, w produkt i w narzędzia, część zespołu, do której należałem, dostałem proste zadanie: pomagać klientom robić ‚customizowację' produktów. Polegało to na branchowaniu kodu w tę i we w tę, poprawkach w plikach konfiguracyjnych i na edytowaniu kilku headerów C/C++, dodając kolejną porcję #ifdef-owych okropieństw. Pamiętam jeden z głównych headerów, który spuchł do ponad 100 tys. linii #ifdef-owych rzygów.

Zadanie było dosyć proste (kiedy już wiedziało się, co i jak edytować). Było nudne, żmudne i bardzo podatne na ludzkie błędy. Typowe podejście – hackuj-buduj-testuj-iteruj – można było sobie w buty wsadzić, jako że pełny build trwał dzień (tak, dobę – 24h). Przes*anie sytuacji łatwo było wyczuć, otwierając jeden z głównych headerów.

Mój kolega z zespołu wpadł na genialny pomysł robienia wszystkich tych żmudnych operacji w Pythonie. Po kilku dniach prototyp był gotowy. Po kilku tygodniach używaliśmy go, zamiast ręcznie machać szpadlem. Narzędzie było doskonałe. Miałem okazję napisać trochę kodu w Pythonie, który robił coś pożytecznego i to jeszcze pod okiem dużo bardziej doświadczonego kodera! Cieszyła nas myśl rozpuszczenia tego narzędzia po wszystkich centrach megakorpo. Tysiące roboczogodzin i fakapów uratowane. 

Polecieliśmy do jednego z ośrodków produkcyjnych firmy z demonstracją naszego panaceum. To był moment, w którym zrozumiałem jak działa korporacja. Jeśli nad twoją uśmiechniętą mordką jest więcej niż 10 poziomów w schemacie organizacyjnym, szansa na przepchanie twojego genialnego pomysłu jest bliska 0. Załóżmy, że jest 80% szansy na to, że twój menadżer albo menadżerka popchną twój pomysł do góry, a masz 10 poziomów nad sobą, na końcu daje to 10% szans. Ta 80% szansa 'per-szczebel' i tak jest optymistyczna.

Próbowaliśmy reklamować narzędzie, które wyręczało ludzi z pracy. Nie to, że ktoś by ich nagle zwolnił – zawsze znajdzie się praca dla ludzi, którzy nie bledną na widok kodu źródłowego. Zamiast tego, odbiliśmy się od ściany, którą było konserwatywne podejście do pracy.

To był pierwszy znak, że praca w korpo może nie być dla mnie.

Kolejne 5 lat byłem kulką we fliperze menadżmentu, pracując jako technical leader, trener techniczny, nawet dano mi małą ekipę do zarządzania. Po czym abdykowałem. Lubiłem te wszystkie zajęcia – miałem okazję nauczyć się nowych rzeczy, byłem odpowiedzialny za projekty badawcze. Dzieliłem się wiedzą z innymi i dużo podróżowałem. Kupa frajdy... dopóki nie kapnąłem się, że moja miłość do kodu była coraz mocniej przyduszana z każdym dniem, że ja i mój zespół mocniej podążaliśmy za standardami firmy niż dobrymi inżynierskimi wartościami. Gdy moja żądza porządnej inżynierii osiągnęła maksimum, zrzuciłem z siebie wszystkie obowiązki niezwiązane z programowaniem. Przynajmniej tak mi się wydawało.

Wraz z rozrostem firmy i naszego działu, poziom umiejętności zatrudnianych ludzi leciał na pysk. Najbardziej wartościowi byli praktykanci. Absurd. Musiałem uciekać. W podskokach.

Pamiętasz kolegę od prototypu wyręczającego biednych ludzi? W czasie, kiedy ja rozwijałem swoją cierpliwość, on odszedł z korpo. Do Linaro, skąd później przemigrował do Canonicala. Kiedy ja zacząłem szukać pracy, on miał tam już kilka lat za pasem. Pomysł pracy z domu, rozwijając open-sourcowe oprogramowanie i to dla firmy, którą naprawdę szanowałem, brzmiało jak marzenie.

Moim zmartwieniem było jedynie "czy jestem wystarczająco dobry?".
Rekrutacja poszła gładko (pomijając fakt, że spóźniłem się na jedną z sesji, bo jak ta durna pała, źle policzyłem różnicę czasu)…

Część druga tutaj...