Programisto, daj sobie pomóc

By 27 March 2017Inspiracje, ITlogy

Dzisi­aj będzie o jed­nym z częstych grzechów juniorów, który jed­nak w nieco zmienionej formie dopa­da również doświad­c­zonych (i bard­zo doświad­c­zonych) koderów. Nie przedłuża­jąc, co się dzieje, gdy pro­gramista chce sam poradz­ić sobie z prob­le­mem?

Przecież sobie poradzę

Skończyłeś stu­dia. Jesteś w swoim pier­wszym pro­jek­cie. Chcesz się jak najlepiej zaprezen­tować. Widzisz, że inni devel­op­erzy są zaję­ci swoi­mi zada­ni­a­mi. Ale może jakoś sobie poradzisz z napotkanym prob­le­mem. Szukasz, sprawdza­sz na włas­ną rękę (cza­sem jeszcze nie wiesz, jak efek­ty­wnie wyszuki­wać w sieci, cza­sem nie radzisz sobie dobrze z debu­gowaniem, a cza­sem po pros­tu wierzysz, że kod po ponownym uru­chomie­niu jed­nak ‘mag­icznie’ zacznie dzi­ałać), bo wiesz, że od tego powineneś zacząć. Ostat­nio z resztą była o tym mowa, by zan­im zawołasz kogoś do pomo­cy, żebyś sam poświę­cił chwilę na wyszukanie rozwiąza­nia…

Mija dzień, a ty na dai­ly stand up zapew­ni­asz, że jesteś o krok. Po prz­er­wie na lunch jeden z devel­op­erów pyta: hej, jak tam? Mówisz, że jeszcze 20–30 min i będzie. Po godzinie kole­ga z zespołu znowu pod­chodzi i znowu pyta (choć na tak dociek­li­wych nie zawsze się trafi). Znowu mówisz, że dasz sobie radę. Ale w duchu nie masz poję­cia co robić, jed­nak tak bard­zo chci­ałbyś dojść do rozwiąza­nia sam… Jest 17, wszyscy powoli zbier­a­ją się do domu, a pro­gramista, który nagaby­wał Cię cały dzień, sia­da z Tobą i zaglą­da w twój kod. Weźmy tutaj opcję optymisty­czną: sia­da z Tobą nad prob­le­mem i po 20 min wszys­tko dzi­ała. Mogło­by być i tak, że zadanie okaza­ło­by się znacznie bardziej skom­p­likowane i nagle potrze­ba nie jed­nej juniorskiej głowy, ale całego zespołu…

Hej, propoś o pomoc!

To chy­ba najlep­sze pod­sumowanie tego, co tu się zadzi­ało. Niemalże w każdym zes­pole spotkasz taką zosię-samosię, która nie chce “zamęczać” Cię swoi­mi prob­le­ma­mi, chce sama je rozwiązać, bo chce się czegoś nauczyć, wyda­je jej się, że masz ważniejsze rzeczy na głowie, że pro­gramiś­ci w zes­pole są tak zaję­ci, że nie warto im przeszkadzać. I wszys­tko fajnie, ale … w pro­jek­cie, za sukces (czy za porażkę) odpowia­da zespoł. Współpra­ca jest kluc­zowa. Komu­nikac­ja i wza­jem­na pomoc również. A na koniec dnia liczy się przede wszys­tkim wynik, którym dla biz­ne­su będzie dostar­c­zona funkcjon­al­ność, a nie nieu­daną pró­ba poradzenia sobie samemu z zadaniem.

Przecież jest napisane

W poprzed­nim pro­jek­cie wszys­tkie zada­nia były dokład­nie opisane w doku­men­tacji. Ot, taki water­fall, tylko w sprint­ach. Brałem zadanie, czy­tałem, dostar­cza­łem. Wszys­tko grało. No, to tutaj też tak jest. Co napisane w JIRA to zaim­ple­men­towane. Ja prze­cież wykon­ałem swo­ją pracę!

Hej, czy jesteś pewnien?

W ide­al­nym świecie, jeśli pro­gramista nie chce martwić się o biznes to nie musi. Ale takiego świa­ta nie ma. A User Sto­ries, czy konkretne sce­nar­iusze testowe zazwyczaj wyma­ga­ją współpra­cy. Widzi­ałam już przy­pad­ki imple­men­towa­nia czegoś wbrew log­ice i na złość, bo ktoś zro­bił błąd w sce­nar­iuszu testowym. Sama też niedawno gdy imple­men­towałam swo­je pier­wsze front endowe zadanie odkry­wałam na nowo, co się dzieje, jak nacis­nę anu­luj albo zamknę okno dial­o­gowe. I tak, w momen­cie czy­ta­nia zada­nia nie przyszło mi na myśl, że obsłu­ga tych przy­cisków mnie doty­czy. A mój biznes anal­i­tyk nie pra­cow­ał wcześniej z zespołem, który w całoś­ci uczy się fron­tendu więc pewne oczy­wiste zachowa­nia po pros­tu pom­inął. I moglibyśmy tak sobie dzi­ałać, ja imple­men­tu­jąc min­i­mum wg tego co on dostar­czył, tester zakłada­ją­cy wiele bugów, a potem znowu BA dorzu­ca­ją­cy feed­back… Ale zaczeliśmy roz­maw­iać. Orga­ni­zować ses­je Three Ami­gos. Wspól­nie brać odpowiedzial­ność za sce­nar­iusze, funkcjon­al­noś­ci, zrozu­mie­nie prob­le­mu. I wiecie co, może bugi mag­icznie nie znikły, ale jest ich mniej. Mniej też cza­su spędza­my na mailach/chatach/rozmowach: a co to znaczy? Bo na samym początku poświę­clil­iśmy sobie na tą roz­mowe te przysłowione 30 min. A cza­sem wystar­czy 5. Albo nawet parafraza. Upewnie­nie się, czy aby na pewno przez to zadanie rozu­miesz to i to.

Przecież wiem, co i jak

To jest pułap­ka, w która wpaść moż­na bard­zo łat­wo. Wystar­czy, że ostat­ni pro­jekt był w tym samym stosie tech­no­log­icznym. Wystar­czy, że od X lat jesteś w danym pro­jek­cie / pracu­jesz dla tego samego klien­ta. Że od daw­na, do two­jego zespołu nie doszedł pro­gramista z innej orga­ni­za­cji… Powolutku masz wraże­nie, że wiesz wszys­tko. A nagle, gdy się pojaw­ia, dość łat­wo rzu­casz, sprawdza­łem to 2 lata temu, nie dzi­ałało. Albo, ponieważ nie moż­na zmienić A ze wzglę­du na pewien prob­lem z B, C musi pozostać jakie jest. I wierzę, że tak było. Jed­nak warto zas­tanow­ić się, czy nie lep­iej zwery­fikować (albo poz­wolić zwery­fikować) sprawę jeszcze raz. Oso­by piszące władne DAO i nie korzys­ta­jące ze Spring Data, kiedy mogą, to trochę moja (a może i Wasza) kląt­wa. Ale widzi­cie, ostat­nim razem, trochę proak­ty­wnie stwierdzil­iśmy, ok to robimy per­for­mance testy, nie ma prob­le­mu. I gdy pokaza­l­iśmy wyni­ki, wszyscy byliśmy zgod­ni, co do rozwiąza­nia. I choć trochę z inic­jaty­wy odd­ol­nej, decyz­ja została zmieniona.

Hej, może sprawdzimy jeszcze raz

Wyda­je mi się, że ten przy­padek może mieć dwa dna. Pier­wsze to fak­ty­cznie pułap­ka nieomyl­noś­ci i wiedzy abso­lut­nej w jaką moż­na wpaść. Brak poko­ry. Pewne ‘poz­jadanie rozumów’. Postawy bard­zo niebez­pieczne dla devel­op­erów, bo prze­cież tech­nolo­gie po pros­tu bieg­ną do przo­du. Ale cza­sem, może chodz­ić też o brak zau­fa­nia do tej drugiej strony? I bardziej niż ja wiem lep­iej, jest ‘ty wiesz gorzej’. A gdy w zes­pole braku­je zau­fa­nia, albo gdy odci­na się pewną jego cześć od decyzji i odpowiedzial­noś­ci staw­ia­jąc w pozy­cji klepacza kodu, to nic dobrego z tego nie wyniknie. Ja bym wtedy zmieniła pracę, ale znam oso­by, które fak­ty­cznie zaczęły by bezmyśl­nie ten kod klepać. I znowu, nic nie stoi na przeszkodzie, by znaleźć ten dodatkowy czas na ponowne zwery­fikowanie tem­atu. Sprawdze­nie dostęp­nych opcji. Upewnie­nie się, że warun­ki wewnątrz orga­ni­za­cji się nie zmieniły. Że mamy te same dane i wiedzę.

Marnowanie czasu

Lep­iej “zmarnować” 30 min czy 2 dni? Dzień czy Sprint? Znaleźć rozwiązanie za które weźmiesz odpowiedzial­ność tu i ter­az, czy takie, które będzie dzi­ałać 5 min­ut dłużej? Oj bo trze­ba poroz­maw­iać, zająć komuś czas, przeszkodz­ić… Zmarnować czas … Obyśmy tylko w taki sposób, wspól­nie szuka­jąc rozwiązań, go w pro­jek­cie marnowali :)

Pro­gramista rzad­ko kiedy może być samot­ną wyspą. A żeby móc się fajnie rozwi­jać i uczyć to wyda­je się to wręcz niemożli­we.

 

  •  
  •  
  •  
  •  
  •