Dzisiaj będzie o jednym z częstych grzechów juniorów, który jednak w nieco zmienionej formie dopada również doświadczonych (i bardzo doświadczonych) koderów. Nie przedłużając, co się dzieje, gdy programista chce sam poradzić sobie z problemem?
Przecież sobie poradzę
Skończyłeś studia. Jesteś w swoim pierwszym projekcie. Chcesz się jak najlepiej zaprezentować. Widzisz, że inni developerzy są zajęci swoimi zadaniami. Ale może jakoś sobie poradzisz z napotkanym problemem. Szukasz, sprawdzasz na własną rękę (czasem jeszcze nie wiesz, jak efektywnie wyszukiwać w sieci, czasem nie radzisz sobie dobrze z debugowaniem, a czasem po prostu wierzysz, że kod po ponownym uruchomieniu jednak ‘magicznie’ zacznie działać), bo wiesz, że od tego powineneś zacząć. Ostatnio z resztą była o tym mowa, by zanim zawołasz kogoś do pomocy, żebyś sam poświęcił chwilę na wyszukanie rozwiązania…
Mija dzień, a ty na daily stand up zapewniasz, że jesteś o krok. Po przerwie na lunch jeden z developerów pyta: hej, jak tam? Mówisz, że jeszcze 20–30 min i będzie. Po godzinie kolega z zespołu znowu podchodzi i znowu pyta (choć na tak dociekliwych nie zawsze się trafi). Znowu mówisz, że dasz sobie radę. Ale w duchu nie masz pojęcia co robić, jednak tak bardzo chciałbyś dojść do rozwiązania sam… Jest 17, wszyscy powoli zbierają się do domu, a programista, który nagabywał Cię cały dzień, siada z Tobą i zagląda w twój kod. Weźmy tutaj opcję optymistyczną: siada z Tobą nad problemem i po 20 min wszystko działa. Mogłoby być i tak, że zadanie okazałoby się znacznie bardziej skomplikowane i nagle potrzeba nie jednej juniorskiej głowy, ale całego zespołu…
Hej, propoś o pomoc!
To chyba najlepsze podsumowanie tego, co tu się zadziało. Niemalże w każdym zespole spotkasz taką zosię-samosię, która nie chce “zamęczać” Cię swoimi problemami, chce sama je rozwiązać, bo chce się czegoś nauczyć, wydaje jej się, że masz ważniejsze rzeczy na głowie, że programiści w zespole są tak zajęci, że nie warto im przeszkadzać. I wszystko fajnie, ale … w projekcie, za sukces (czy za porażkę) odpowiada zespoł. Współpraca jest kluczowa. Komunikacja i wzajemna pomoc również. A na koniec dnia liczy się przede wszystkim wynik, którym dla biznesu będzie dostarczona funkcjonalność, a nie nieudaną próba poradzenia sobie samemu z zadaniem.
Przecież jest napisane
W poprzednim projekcie wszystkie zadania były dokładnie opisane w dokumentacji. Ot, taki waterfall, tylko w sprintach. Brałem zadanie, czytałem, dostarczałem. Wszystko grało. No, to tutaj też tak jest. Co napisane w JIRA to zaimplementowane. Ja przecież wykonałem swoją pracę!
Hej, czy jesteś pewnien?
W idealnym świecie, jeśli programista nie chce martwić się o biznes to nie musi. Ale takiego świata nie ma. A User Stories, czy konkretne scenariusze testowe zazwyczaj wymagają współpracy. Widziałam już przypadki implementowania czegoś wbrew logice i na złość, bo ktoś zrobił błąd w scenariuszu testowym. Sama też niedawno gdy implementowałam swoje pierwsze front endowe zadanie odkrywałam na nowo, co się dzieje, jak nacisnę anuluj albo zamknę okno dialogowe. I tak, w momencie czytania zadania nie przyszło mi na myśl, że obsługa tych przycisków mnie dotyczy. A mój biznes analityk nie pracował wcześniej z zespołem, który w całości uczy się frontendu więc pewne oczywiste zachowania po prostu pominął. I moglibyśmy tak sobie działać, ja implementując minimum wg tego co on dostarczył, tester zakładający wiele bugów, a potem znowu BA dorzucający feedback… Ale zaczeliśmy rozmawiać. Organizować sesje Three Amigos. Wspólnie brać odpowiedzialność za scenariusze, funkcjonalności, zrozumienie problemu. I wiecie co, może bugi magicznie nie znikły, ale jest ich mniej. Mniej też czasu spędzamy na mailach/chatach/rozmowach: a co to znaczy? Bo na samym początku poświęcliliśmy sobie na tą rozmowe te przysłowione 30 min. A czasem wystarczy 5. Albo nawet parafraza. Upewnienie się, czy aby na pewno przez to zadanie rozumiesz to i to.
Przecież wiem, co i jak
To jest pułapka, w która wpaść można bardzo łatwo. Wystarczy, że ostatni projekt był w tym samym stosie technologicznym. Wystarczy, że od X lat jesteś w danym projekcie / pracujesz dla tego samego klienta. Że od dawna, do twojego zespołu nie doszedł programista z innej organizacji… Powolutku masz wrażenie, że wiesz wszystko. A nagle, gdy się pojawia, dość łatwo rzucasz, sprawdzałem to 2 lata temu, nie działało. Albo, ponieważ nie można zmienić A ze względu na pewien problem z B, C musi pozostać jakie jest. I wierzę, że tak było. Jednak warto zastanowić się, czy nie lepiej zweryfikować (albo pozwolić zweryfikować) sprawę jeszcze raz. Osoby piszące władne DAO i nie korzystające ze Spring Data, kiedy mogą, to trochę moja (a może i Wasza) klątwa. Ale widzicie, ostatnim razem, trochę proaktywnie stwierdziliśmy, ok to robimy performance testy, nie ma problemu. I gdy pokazaliśmy wyniki, wszyscy byliśmy zgodni, co do rozwiązania. I choć trochę z inicjatywy oddolnej, decyzja została zmieniona.
Hej, może sprawdzimy jeszcze raz
Wydaje mi się, że ten przypadek może mieć dwa dna. Pierwsze to faktycznie pułapka nieomylności i wiedzy absolutnej w jaką można wpaść. Brak pokory. Pewne ‘pozjadanie rozumów’. Postawy bardzo niebezpieczne dla developerów, bo przecież technologie po prostu biegną do przodu. Ale czasem, może chodzić też o brak zaufania do tej drugiej strony? I bardziej niż ja wiem lepiej, jest ‘ty wiesz gorzej’. A gdy w zespole brakuje zaufania, albo gdy odcina się pewną jego cześć od decyzji i odpowiedzialności stawiając w pozycji klepacza kodu, to nic dobrego z tego nie wyniknie. Ja bym wtedy zmieniła pracę, ale znam osoby, które faktycznie zaczęły by bezmyślnie ten kod klepać. I znowu, nic nie stoi na przeszkodzie, by znaleźć ten dodatkowy czas na ponowne zweryfikowanie tematu. Sprawdzenie dostępnych opcji. Upewnienie się, że warunki wewnątrz organizacji się nie zmieniły. Że mamy te same dane i wiedzę.
Marnowanie czasu
Lepiej “zmarnować” 30 min czy 2 dni? Dzień czy Sprint? Znaleźć rozwiązanie za które weźmiesz odpowiedzialność tu i teraz, czy takie, które będzie działać 5 minut dłużej? Oj bo trzeba porozmawiać, zająć komuś czas, przeszkodzić… Zmarnować czas … Obyśmy tylko w taki sposób, wspólnie szukając rozwiązań, go w projekcie marnowali :)
Programista rzadko kiedy może być samotną wyspą. A żeby móc się fajnie rozwijać i uczyć to wydaje się to wręcz niemożliwe.
