Praca - trochę szczegółów - część 2

Organizacja pracy

Jak sobie pościelisz tak się wyśpisz chciałoby się napisać. W firmie jest znikoma ilość jakikolwiek procedur czy rzeczy narzuconych z góry. Zespoły same sobie wypracowują styl pracy czy własne procedury, jeśli są potrzebne. Coś cię wkurza w organizacji pracy - zaproponuj jak zrobić to lepiej i zaczniemy tak robić. Jakieś narzędzie z którego korzystam w pracy nie działa dla mnie? Popraw/zgłoś błąd/zrób lepsze. Widzisz gdzieś problem - zareaguj - nie oczekuj że ktoś inny magicznie go dostrzeże i zareaguje za ciebie. Jakaś technologia nad którą cały zespół pracował 2 lata jest zła według ciebie - powiedz czemu. Idź do miejsca gdzie siedzi ten zespół i pogadaj programistami czy managerem zespołu i powiedz im co robią nie tak. 

Pamiętaj, że twój kod to nie twoje dziecko i jak ktoś ma powody, żeby stwierdzić, że twoje rozwiązanie jest głupie i trzeba się go pozbyć to nie znaczy to, że on uważa, że ty jesteś głupi. Cytując jednego z guru programistycznych, którego poznałem tutaj: "mam nadzieje, że nigdy nie dojdzie do sytuacji że ktoś będzie się bał zakwestionować moje rozwiązanie i powiedzieć że jest głupie". Zadawanie takich pytań i kwestionowanie różnych rozwiązań jest wręcz pożądane - dużo rzeczy to naleciałości historyczne, jak wszędzie, i tylko zadając takie pytania można pomóc się ich pozbyć. Coś co było dobrym pomysłem 2 lata temu dzisiaj faktycznie może być głupie.

Nie ma też głupich pytań - "jak działa X i dlaczego go używamy?", gdzie X to dowolna rzecz - od podstaw Linuxa, przez nasze komponenty, po komunikat na świat z działu PR.

Ciągle mnie to tutaj zadziwia - widzę problem, w kodzie człowieka który pracuje w firmie od X lat a na ten temat pisał książki - podchodzę do jego biurka i mówię - "hej, chyba znalazłem problem w twoim kodzie - możesz spojrzeć na to?" - "O , faktycznie. Stwórz mi zadanie z dokładniejszym opisem i to poprawię". Czasem jest trochę gorzej "jest tu problem - ale nie jest to dla nas teraz priorytet bo musimy zrobić X. Ale jeśli jest to dla ciebie ważne to z chęcią pomogę ci poprawić to i zaakceptuje kod który to poprawia". Przechodziłem to już wiele razy. Żadnych rozmów przez managerów jeśli dotyczy to innego zespołu, formalizacji, spychologii. Celem jest po prostu zrobienie tego co trzeba zrobić i wszystko w organizacji firmy obraca się wokół tego. Po budynkach porozwieszane są ekrany dotykowe na których można wyszukać gdzie jest biurko jakiegoś innego pracownika - podchodzisz, szukasz, idziesz do gościa i rozwiązujecie problemem.

Ma to też swoje wady, ale jest to świadoma decyzja Facebooka - maksymalne uproszczenie organizacji pracy kosztem problemów które może to czasem powodować. Dokumentacja dość często jest chaotyczna/przestarzała (jeśli istnieje ;-) ) i najczęściej jak chce się dowiedzieć jak dokładnie coś działa i czy np. nadaje się do użytku przeze mnie to mam do wyboru albo czytanie kodu bądź szukanie właściwej osobę do rozmowy na ten temat. Ważną rzeczą jest więc po prostu duża ilości znajomości w obrębie firmy - nie wiem kto odpowiada za X, ale znam faceta który kiedyś pracował nad czymś podobnym - może on będzie wiedział gdzie mnie skierować. Albo nie mam zielonego pojęcia gdzie zacząć w ogóle szukać czegoś na ten temat - napiszę na paru różnych wewnętrznych grupach, może ktoś wskaże, albo pójdę do rejonu gdzie siedzą ludzie którzy zajmują się czymś choć trochę podobnym i zacznie ich losowo pytać :-).

Można powiedzieć, że cała struktura działu inżynierów przypomina 10 osobową firmę w której pracują znajomi ze studiów, a nie kilkutysięczną korporację wartą aktualnie $70 miliardów. I o dziwo działa to nadzwyczajnie sprawnie. Wynika to też z tego, iż poprzeczka na zatrudnienie jest wysoka i nie chodzi tylko o umiejętności techniczne, ale też o kwestie kultury pracy (nie mam tu na myśli nieużywanie przekleństw - żaden dział inżynierski nie przeżyje bez nich ;-) ). Musisz być osobą która jest w stanie pracować w takim środowisku, akceptować odpowiedzialność i być super otwartym na krytykę (nie osobistą) oraz być w stanie dawać konstruktywną krytykę wobec innych rozwiązań (nie ludzi). Nie ważne jak dobry będziesz - jeśli inni nie będą chcieli z tobą pracować albo będziesz się zachowywał arogancko wobec innych - nie zagrzejesz tutaj miejsca (albo, co bardziej pożądane - nie dostaniesz oferty pracy od Facebooka).

Architekci

Nie istnieje pozycja architektów. Każdy inżynier ma być w stanie zarówno pisać kod jak i projektować system. Wiadomo - są bardziej doświadczeni ludzie, czy też ludzie z wizją na temat konkretnego komponentu, ale nie siedzą oni i zajmują się tylko przydzielaniem zadań dla innych. Oni też sobie "brudzą" ręce przy kodowaniu, a ty jako świeżak w zespole też masz za zadanie ruszyć szarymi komórkami i pomagać przy projektowaniu. Nie logujesz się więc z rana do systemu z zadaniami, wybierasz co na dzisiaj, robisz i wychodzisz.

Moja pozycja jest trochę inna niż programistów, ale po trochę ponad 2 miesiącach w zespole więcej niż połowa zadań które mam w kolejce do realizacji to zadania które sam sobie przydzieliłem, znalazłem w wyniku poszukiwań z programistami, etc, a nie przydzielone z góry przez kogoś. Wiadomo - mamy parę głównych celów do zrealizowania jako zespół w danym okresie, ale są one określone w taki sposób np. "sprawić, żeby X było bardziej niezawodne". Jak? Nikt nie wie na początku najczęściej i nie udaje tego. Więc samodzielność w pracy jest bardzo pożądana - managerowie nie są tu po to żeby cię pilnować czy pracujesz i dorzucać ci pracy.

Managerowie

Każdy manager którego poznałem do tej pory jest osobą bardzo techniczną i będąc managerem nadal też udziela się technicznie, choć w małym stopniu. Nie są to ludzie wyciągnięci z kapelusza którzy skończyli kurs zarządzania. Nie są to też ludzie którzy byli inżynierami i teraz są wielkimi managerami którzy twierdzą, że to wina zespołu a oni są super i tylko ci głupi pracownicy sprawiają. że coś nie wyszło - gdyby on to napisał to by wszystko działało, ale nie może bo ma ważne sprawy na głowie. W wypadku problemów z jakimś komponentem manager odpowiedzialny za niego może siąść z inżynierami z innego zespołu, który z niego korzysta i powiedzieć im co jest nie tak i jak poprawić ich interakcję z tą częścią aby nie sprawiała ona problemu bądź skierować do właściwego inżyniera który odpowiada za tą działkę. Jest on zwykłym członkiem zespołu, który zajmuje się też przyziemnymi kwestiami organizacyjnymi, ścieżką kariery, synchronizacją z innymi zespołami, jeśli jest to potrzebne, etc, ale o tym nie ma co pisać.

Błędy są akceptowalne

Brak formalizacji skutkuje czasem też w mniejszych czy większych awariach (architekturę i rozwiązania techniczne mamy bardzo fajne i robimy wszystko żeby nawet duże awarie nie miały wpływu na użytkowników końcowych, ale nie zawsze się to udaje). Jest to koszt polityki move fast and break things. Ale jak coś zepsujesz, to wiedz jak to naprawić :-).

Kod i metryki zawsze wygrywają spór, więc błędy są wkalkulowane w ryzyko. To, że zrobiłeś jakiś błąd który położy pół serwisu - ok. Przeanalizujemy go i nauczymy co zrobić na przyszłość aby się to nie powtórzyło. Ale w 99% nie będziemy dodawać procedur ale poprawimy skrypty, monitoring, automatyczne testy, konfigurację, etc.

Co tydzień jest spotkanie infrastruktury na którym analizowane są ważne problemy z ostatniego tygodnia. Manager na początek w zespole mi zapowiedział, żebym nie miał żadnych złudzeń - w przeciągu roku na pewno co najmniej raz będę na tym spotkaniu, omawiając co było nie tak w moich komponentach. Jeśli nie spowodujesz takiego problemu - to znaczy że nie próbujesz wystarczająco mocno :-). Nie chodzi w tym wszystkim o wysyłanie na produkcję nieprzetestowanych/głupich rzeczy. Ale przy takiej skali może się zdarzyć wszystko.

Jak masz ponad miliard aktywnych użytkowników (aktywnych w przedziale miesiąca - i nie, nie liczymy podwójnie użytkowników z komórek czy też fakeowych kont - potrafimy liczyć :-) ) to jeśli coś ma prawdopodobieństwo wystąpienia 1 na milion to zdarzy się to całkiem często :-). Oprócz tego inne komponenty też się stale zmieniają, a infrastruktura jest super skomplikowana - nie jesteś w stanie przewidzieć dokładnie efektu twojej zmiany, nawet jeśli wydaje ci się że pomyślałeś o wszystkim.

Nie ma tu polityki wytykania palcami i zrobienie błędów, nawet takich które kosztują sporo kasy, jest akceptowalne i nie zostaniesz z tego powodu napiętnowany (nie mówię oczywiście o celowym robieniu błędu, czy pracy "na odwal się" - ale o czymś takim jeszcze nie słyszałem). Inaczej firma nie działałaby i już dawno by nas nie było na rynku, bo nikt nie odważyłby się robić większych zmian i zadowalał statusem quo - dużo firm tak skończyło w biznesie IT - my robimy wszystko, żeby nie być kolejną taką firmą.