Informatyk – klasyfikacja gatunku

Kiedy człowiek spoza branży myśli informatyk, zazwyczaj oczami wyobraźni materializuje sobie postać ubraną w kraciastą koszulę, w narzuconym na nią wygniecionym polarze, w kolorze zgniłej zieleni, która pojawia się w jego domu lub przy jego biurku w pracy aby podłączyć drukarkę, naprawić niedziałający Internet lub przywrócić usuniętą ikonę Worda na pulpicie. Osoba ta, bez większego zastanowienia, powinna być w stanie powiedzieć, który laptop warto kupić lub jaką kartę graficzną wybrać, aby najnowszy Wiedźmin chodził jak najlepiej. Osoba ta powinna też, najlepiej przez telefon, rozwiązać w pięć minut każdy możliwy problem zgłoszony przez system Windows, w dowolnej wersji, lub każde inne dostępne na rynku oprogramowanie (z reguły w wersji pirackiej). Niewiele osób spoza branży dostrzega w ogóle jakikolwiek inny podział tych dziwnych ludzi. Niewielu słyszało określenie programista, a ci co słyszeli (nie będąc przy okazji świadomym, że istnieje jeszcze taki zawód jak grafik), z reguły klasyfikuje ten dziwny typ ludzi jako tych, co potrafią zrobić stronę internetową.
Ten dziwny typ ludzi ma tez specyficzne poczucie humoru i posługuje się niby polskim, ale jak bardzo innym językiem. Nigdy nie zapomnę, jak moja wspaniała małżonka przez pięć minut nie mogła powstrzymać się od śmiechu, kiedy to chcąc zagaić, pewnego wieczora, powiedziałem że jej „procedura malowania paznokci jest bardzo interesująca”. Jak już opanowała gromki śmiech powiedziała coś w rodzaju: „Stary! Procedura malowania paznokci? Seriously? Kto tak mówi? A zapomniałam, że wyszłam za informatyka.”

Jednak gatunek informatyków jest dużo bardziej zróżnicowany. Ja w swoim krótkim wywodzie chciałbym się skupić na szczególnej grupie programistów.

Moje prawie dziewięcioletnie doświadczenie w branży, podczas którego pełniłem różne role, od szeregowego klepacza kodu do team leadera zespołu developerskiego jak i utrzymaniowego, pozwoliło mi zidentyfikować dwa podziały.

Pierwszy zasadniczy podział, to podział na developerów wytwarzania i developerów utrzymania. Z każdą grupą, podobnie jak w przypadku części mowy, można powiązać właściwe pytanie. Do developerów działu wytwarzania przypisałbym pytanie „Co?”, a do działu utrzymania pytanie „Jak?”. Developerzy działu wytwarzania zorientowani są na cel. Ich zadaniem jest zaimplementowanie nowej, super potrzebnej klientowi funkcjonalności. Dokładnie wiedzą co mają osiągnąć, jakie korzyści z tego będzie miał klient i dlaczego będzie zbierać szczękę z podłogi, jak już dostanie tę funkcjonalność. Ich działania są skierowane na realizację wymagań specyfikacji funkcjonalnej. Są przy okazji świadomi ram czasowych, w jakich funkcjonalność miałaby powstać, głownie za przyczyną Project Managera, cały czas gadającego o znienawidzonym przez nich harmonogramie, ograniczającym jedynie ich twórcze myślenie. Z reguły nie mają pełnej świadomości faktycznych pieniędzy, jakie otrzyma firma za ich jakże to twórczą pracę.

Kiedy developer działu wytwarzania przychodzi do developera działu utrzymania bardzo szybko, z ust tego drugiego, pada pytanie „Jak?”. Jaka jest procedura wdrożenia Twojej wspaniałej funkcjonalności. Rzadko kiedy padnie pytanie: co ona w ogóle umie ta Twoja super potrzebna, nowa opcja systemu? Jaka jest procedura rollback’u w przypadku, gdy podczas wdrożenia, coś pójdzie nie tak? Jaka jest konfiguracja? Jak długiego okna serwisowego potrzeba, aby to uruchomić, i jak długo system będzie niedostępny na produkcji? Developer działu wytwarzania, z reguły, traktuje to jak sztucznie tworzone problemy. Jednak developer działu utrzymania patrzy na systemy informatyczne przez zupełnie inny pryzmat. On jest jak chirurg operujący na otwartym sercu. Czas niedostępności systemu, działającego produkcyjnie, przekłada się na ilość gotówki w portfelu klienta, i dlatego jest bardzo ograniczony. Często okienko serwisowe, które można wykorzystać, na wdrożenie nowej funkcjonalności, może pojawić się dopiero w przeciągu tygodnia i nie może być dłuższe niż między 23 a 24 w nocy. W tym czasie musi on być w stanie przywrócić aplikację do poprzedniego stanu i zapewnić jej poprawną pracę, gdy w dowolnym momencie coś się wyłoży. Dlatego też dział utrzymania kocha procedury. Najlepiej takie napisane krok po kroku, nie pozostawiające najmniejszej możliwości interpretacji. Dla tych developerów dużo bardziej istotne jest jak coś robimy, niż co dokładnie dostarczamy. Jak coś ma działać, niż co klient dzięki temu osiągnie? Jak coś naprawić, aby nie przekroczyć terminów określonych w SLA. Developerzy ci są też dużo bardziej świadomi faktycznych zysków firmy, na jakie przekłada się każda godzina ich pracy. Działają w ramach abonamentów zawierających określoną liczbę godzin. CRy wyceniają w oparciu o cenę za godzinę pracy.

Kolejnym podziałem, jaki udało mi się zaobserwować, jest podział na tych „zorientowanych na kod” i „zorientowanych na funkcjonalność”. Ten podział jest dużo mniej oczywisty. Z tym podziałem znowu powiązałbym te same pytania, odpowiednio „Jak?” oraz „Co?”. Myślę, że ten podział w większej mierze można zastosować do developerów działu wytwarzania, jako ich klasyfikację wewnętrzną. W mniejszym stopniu ma on zastosowanie do developerów działu utrzymania.

Developerzy zorientowani na kod uwielbiają grzebać w kodzie. Zawsze mają ściągnięte źródła każdej biblioteki zewnętrznej, jakiej używają. Analizują te źródła mimo, że mogliby po prostu używać API, gdyż i tak są w stu procentach pewni, że działa ona poprawnie. W końcu nikt nie decyduje się na używanie niestabilnych rozwiązań. Lubia spędzać godziny na analizowaniu wszystkich properties’ów konfiguracyjnych zastosowanych framework’ów, nawet jeśi nie wszystkie z nich są na dany moment istotne. Sypia później tymi konfiguracjami jak z rękawa. Nie tolerują, gdy cokolwiek w ich rozwiązaniu, działa z domyślną konfiguracją, a już dosłownie dostają spazmów, gdy framework’i robią coś „pod spodem”, automatycznie. Dlatego też, kiedy rozmawiałem z niektórymi kolegami o Spring Boot, to słyszałem wiele negatywnych opinii. „Przecież tam się to dzieje magicznie. Nie możesz tego kontrolować. A co jeśli coś nie będzie działać? Przecież nie będziesz w stanie od razu powiedzieć dlaczego.? Programiści z tej grupy mają alergię na stosowanie konwencji ponad konfiguracją. U nich każdy komponent musi być jawnie zdefiniowany w XML?u, properties’ach czy yaml?u. Programiści ci często nie czują tego, że trzeba się zmieścić w harmonogramie. Przekroczona wycena jest dla nich sprawą drugorzędną. Nie kwapią się też do polemiki z analitykami. Najchętniej nie mieli by z nimi nic do czynienia. Analitycy są od tego, żeby dostarczyć nie pozostawiającą cienia wątpliwości, dokumentację. Nie ma potrzeby tracić czasu na rozmowy na temat inny niż kod.

Programiści zorientowani na funkcjonalność skupiają się na tym, aby funkcjonalności wymagały jak najmniejszej ilości pracy do ich realizacji. Lubią testować nowe framework’i, najlepiej takie, które wiele rzeczy dostarczają out-of-the-box. Konwencja ponad konfiguracją? Jak najbardziej. Im mniej kodu i konfiguracji tym lepiej. Liczy się czas i wypełnienie harmonogramu. Programiści Ci wiedzą, że w obecnych czasach, systemy muszą być dostarczane szybko i tanio. Inaczej nie ma szans na wygranie przetargu. Programiści ci nie muszą od razu wiedzieć wszystkiego o nowym framework’u. Poznają go przyrostowo, skupiając się na części, której aktualnie potrzebują. Ten typ developerów nie ma problemu z prowadzeniem dyskusji z analitykami czy klientem. Najczęściej ci właśnie programiści koordynują pracę zespołów, ale zawsze, ale to zawsze, chcą mieć w zespole programistów z drugiej grupy. Są świadomi tego, że tylko wsparty ich dogłębną wiedzą, o każdej linijce kodu systemu, projekt ma szansę powodzenia. Nie mając wsparcia, w swoich kolegach z drugiej grupy, zginęliby marnie w momencie, gdy system zaczyna działać niestabilne i trzeba, w krótkim czasie, odpowiedzieć na pytanie dlaczego?

Można śmiało powiedzieć, że te dwa typy programistów się wzajemnie uzupełnią. Tak samo, jak uzupełniają się programiści działu utrzymania i wytwarzania.