25 07 2016

W prawie każdym miejscu pracy sporo się uczymy, ale w przypadku programisty wydaje się być tego wyjątkowo dużo. Jestem pewny, że istnieją zawody, w których występuje to w podobnym, albo nawet większym stopniu – może znajdzie się ktoś, kto będzie mógł się tym podzielić w komentarzu – jednak skupmy się w tym wpisie na pracy programisty.

Zapraszam do materiału w formie wpisu na blogu, filmiku na YT i podcastu do pobrania jako mp3.

Ogrom technologii i narzędzi to wymusza

Każdy projekt ma swój specyficzny zestaw narzędzi i technologii. O ile jesteś osobą, która ma już jakieś doświadczenie, to może znasz parę z nich. Jeśli zaczynasz w branży, to najprawdopodobniej znasz ich bardzo mało.

By efektywnie pracować w jakimkolwiek projekcie, musisz mieć czas na to, by opanować jakieś narzędzie, czy technologię. Zazwyczaj wygląda to tak, że ktoś z projektu tłumaczy Ci z grubsza całą otoczkę i przydziela bardzo proste zadanie, które masz wykonać. Celem nie jest to, by te zadanie wykonać jak najszybciej, tylko byś liznął technologię, w którym wykonasz te zadanie, lepiej zapoznał się z narzędziami, które tu wykorzystują i byś powoli wdrażał się w projekt.

Nigdy nie jest tak, że ktoś siada z Tobą cały dzień, tłumaczy projekt od A do Z i następnie oczekuje, że będziesz wszystko wiedział. Jedyny realny sposób, to wykonywanie małych zadań, konsultowanie ich z kimś, kto dłużej siedzi w projekcie i następnie przechodzenie stopniowo do trochę większych zadań.

Czasami, w przypadku, gdy nie można znaleźć takiego małego zadania (co się zdarza), to możesz dostać za zadanie przerobienie tutorialu w pracy. Serio. Logiczne jest, że lepiej dać komuś parę dni, na zapoznanie się technologią w małym, edukacyjnym projekcie, w którym łatwiej załapać jakiś koncept, niż zmuszać go do grzebania w kolosie, przy którym nie zrobi ani kroku do przodu.

Czy nie zatrudniają ludzi, którzy znają dane narzędzia/technologie? Po co brać kogoś, kto musi uczyć się pracy?

Tak – w pierwszej kolejności (jeśli ma się wybór), to wybiera się osoby, które doświadczenie z technologiami i narzędziami, z których w projekcie korzysta. Jednak często zatrudnia się kogoś, kto jest dobry w podobnym kierunku i dobrze rokuje, by pracować w podobnej, ale trochę innej technologii. Prosta logika: jeśli potrafił się nauczyć i zrobić jakiś projekt w technologii „A”, to nie będzie miał problemu z „B”. Lepiej zatrudnić kogoś kompetentnego, u kogo założymy, że będzie potrzebował parę tygodni, by efektywnie pracować przy projekcie, niż bezskutecznie szukać „idealnego kandydata” i tracić na tym, że projekt stoi w miejscu.

Pamiętam, że kiedyś tego się bałem, że będę musiał od pierwszego dnia „wypracowywać normę”, czy coś podobnego. Na szczęście w miarę szybko mi to to przeszło. Jednak specyfika tej pracy powoduje, że źle ktoś, komu nie da się czasu na naukę, tylko każe się od razu odhaczać istotne taski, to w dłuższej perspektywie powoduje to więcej szkód, niż faktycznego pożytku – tworzy się wtedy dług techniczny (technical debt).

Przykład z nauką specyficznego narzędzia

Miałem taki przypadek, że planowano mnie wrzucić do projektu, w którym będzie wykorzystywane specyficzne narzędzie BI – Oracle BI Publisher. Nigdy nie miałem do czynienia z tym narzędziem i nikt nie oczekiwał, że będę mógł cokolwiek z nim zrobić z marszu. Zanim projekt się zaczął, miałem ponad tydzień czasu, w którym mogłem się „bawić” narzędziem. Stawiałem sobie lokalnie bazę danych, którą podpinałem do narzędzia, jakiś prosty webserwis, którym z tym pracował… następnie podczas samego projektu również mieliśmy zadania „edukacyjne”, by zrobić sobie samemu parę prototypów, które pomogą nam lepiej zapoznać się z narzędziem.

Taka nauka narzędzia, to normalny czas pracy, za który ma się płacone. Jest to jak najbardziej normalne, ale jakoś sporo osób nie jest tego świadomych i niepotrzebnie obawiają się, że muszą od pierwszego dnia znać „wszystko”.

Szukanie lepszych rozwiązań – czasami czytamy książki w pracy

Zdarza się, że podejmuje się decyzję, by ktoś w zespole poświęcił parę dni na reserach, albo wgryzł się w daną technologię i mógł zdecydować, czy jest to coś, co usprawni pracę w firmie. Może być to szukanie narzędzia, by poprawić jakość testów, albo coś co pozwoli współdzielić cześć kodu między platformami. Oprócz sprawdzania i testowania rzeczy, które znajdziemy w sieci, zamawia się również czasami jakąś książkę, którą pracownik czyta w godzinach pracy.

Spora część takich eksperymentów będzie zawsze nieudana – np. testowaliśmy kiedyś konwerter Java na Objective C, by część kodu z androida wykorzystać na iOS, ale narzędzia, które przetestowaliśmy okazały się nieodpowiednie. Czasami jednak udaje się znaleźć coś co usprawnia jakiś proces i dzięki temu profituje później cała firma.

Najważniejsza informacja na koniec.

Źle przeszkolony pracownik robi prawie zawsze więcej szkód niż pożytku. Powstaje więcej długu technicznego i wszyscy na tym tracą – pracownik ma więcej stresu, mniej się uczy, a firma ma gorszej jakości kod. Dlatego zawsze praktyką jest danie odpowiedniej ilości czasu na naukę, zanim będzie on na poważniej robił coś w projekcie. Kolejna „oczywista oczywistość”, ale sporo osób o to pytało. Mam nadzieję, że artykuł im wyjaśnił trochę rzeczy.

Podsumowanie pierwszej połowy roku + plany Wywiad z programistą gry „Wyraj” – porady dla przyszłych twórców gier.