Praca zdalna w IT - historia szczęśliwego Software Developera

Jesteś deweloperem w dużej firmie? Wkurzają Cię stosowane praktyki, środowisko pracy i marnotrawienie czasu? Masz ofertę pracy w firmie, która jest mniejsza, ale oferuje możliwość pracy z domu? Przyjmij ją!

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 imprezowałem) 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, pisałem w różnych językach, kompilowałem na różne architektury, itd. Robota wymagała również kontaktów z klientami i siedzenia 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ż mnie tak nie traktował).

Później po otrzymaniu dyplomu pomyślałem, że fajnie byłoby zostać inżynierem oprogramowania w dużej, prestiżowej firmie. 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 pracy 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.

Genialny pomysł w korpo

Mój kolega z zespołu wpadł na genialny pomysł robienia wszystkich tych żmudnych operacji w Pythonie. Po kilku dniach propotyp 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 w 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 i trener techniczny. Dano mi nawet 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)

Dostałem robotę!

Kilka tygodni minęło. Pierwsze tygodnie otworzyły mi oczy. Zidentyfikowałem mnóstwo problemów, które blokowały mnie w robieniu dobrych rzeczy. Część z nich:

• strach przed skomitowaniem czegokolwiek
• strach przed sukcesem
• strach przed modyfikowaniem istniejącego kodu
• paskudna higiena w gicie
• prototyp powinien wystarczyć
• słaba komunikacja
• OMG, wy wiecie wszystko, ja nic nie wiem
• osoba odpowiedzialna za zarządzanie moim czasem to najgorsza z możliwych: ja

Z drugiej strony byłem zachwycony:

• 0 czasu zmarnowanego na dojazd do pracy
• lepszy sprzęt do pracy (własny sprzęt)
• lepsze wsparcie IT (własne)
• duża niezawodność internetów (zgadnij)
• lepsza kawa (znowu ja)
  
  

Po prawie roku wydaje mi się, że pokonałem większość strachów, albo przynajmniej nie wpływają one tak mocno na moją pracę.

Nauczyłem się kilku rzeczy

1. Najważniejszy jest własny szacunek do roboty

W momencie, kiedy zaczyna się doceniać pisany kod zamiast tego, jak dobrze (lub jak długo) grzeje się stołek programisty, szacunek do pracy szybko przychodzi. Fakt, że kod będzie dostępny publicznie, że każdy będzie mógł go przeczytać, zrecenzować, odbranczować, podwaja te uczucia.

2. Sprawa zarządzania czasem jest odrobinkę bardziej skomplikowana

Trzeba sobie zdefiniować zasady i mocno się ich trzymać. Bez tego każda godzina w trakcie „godzin pracowych" będzie wykorzystana zarówno na pracę, jak i prywatne sprawy. Po czym po ~10 godzinach trudno będzie określić, na co poszedł czas. Łatwo jest później stwierdzić, że „pewnie nie spędziłem wystarczająco dużo czasu na robocie", co skutkuje jednym z dwóch: siedzeniem „w robocie" do końca dnia lub poczuciem, że nie pracowało się wystarczająco dużo.

Reżim czasowy jest bardzo istotny. Wcale nie postrzegam źle siedzenia cały dzień będąc pochłoniętym przez kod – wręcz przeciwnie – to daje wspaniałe uczucie ubersatysfakcji. Ale nie jest to dobry opatrunek na kiepskie zarządzanie czasem.

3. Praca z domu i brak sztywnych godzin pracy to duży bonus

Wiele spraw, kiedy załatwiane są w godzinach pracy „normalnych ludzi" nabiera lepszej jakości, jest tańsze i zajmuje mniej czasu. Wizyty u lekarzy zajmują dużo mniej czasu, trenowanie na gokarcie jest znacznie tańsze i jeździ się po prawie pustym torze i jazda samochodem poza godzinami szczytu też jest znacznie przyjemniejsza.

A! I jeśli lubisz gotować, to teraz najlepsze... Te wszystkie pieczenie, które pieką się kilka godzin, przez co zawsze planowane były na weekend... Teraz możesz je mieć w środę. Omnomnom.

4. Dochodzi jeszcze sprawa narzędzi

Zarówno sprzęt jak i soft. W moim przypadku do mnie należy obowiązek zbudowania i utrzymania maszyn, na których pracuję. Więc wyłącznie ode mnie zależy ich konfiguracja. I to jest genialne. Duże firmy nie ogarniają jak mocno to wpływa na pracę programisty, jaką frustrację może wywołać rytm wybijany na dysku, po prostym wywołaniu grepa, co przeważnie blokuje inne operacje. I z tego co wiem, firmy ciągle nie dają SSDków jako domyślny napęd w sprzęcie. Idioci.

I docieramy do środowiska programistycznego. Zrobienie prostego skryptu, który oszczędzi minutę czasu przy każdej następnej iteracji tego czegoś, co robisz, oszczędza Twój czas, co w konsekwencji oszczędza czas Twojego pracodawcy, Jarząbku. A dlatego, że to Ty nosisz czapkę z napisem „admin", nikt nie powstrzyma cię przed jego zrobieniem. Twoja kreatywność wreszcie może rozwinąć skrzydła. Nawet jeśli wywrócą parę rzeczy w pokoju.

Naprawdę cieszę się z pracy z domu. Uwielbiam tę robotę, tak jak i uwielbiałem poprzednią... Z zupełnie różnych powodów. Domowe biuro wymaga zainwestowania paru skill pointów w siłę woli, ale zyski są zdecydowanie tego warte. Jeśli grasz defensywnie i boisz się niestabilności, która często idzie w parze z robotami „z domu", to pomyśl, jak łatwo o pracę w tym zawodzie. 

Nie wahaj się!