Dzisiaj omówię i podzielę się wynikiem ankiety, którą umieściłem na LinkedIn na moim profilu – Ile procentowo czasu programista poświęca na pisanie kodu, a ile spędza na dogadywaniu się z osobami zlecającymi wykonanie oprogramowania?.
Sam jestem zaskoczony wynikiem ankiety! Na wstępie chciałem podziękować wszystkim osobom, które wzięły udział w ankiecie oraz dodały swój komentarz. W sumie zagłosowało 145 osób, komentarze pozostawiło 8 osób + moje odpowiedzi na te komentarze. Podział czasu między kodowaniem, a dogadywaniem się wygląda następująco: “tylko” ~20% osób dzieli czas 50/50, ~40% osób dzieli czas 70/30, ale również ~40% osób dzieli czas 30/70.
Moje początkowe zaskoczenie wynikiem ankiety bardzo dobrze opisuje komentarz Jakuba: “Jeśli programista poświęca 70% czasu na dogadywanie się, to znaczy, że projekt jest niezorganizowany albo programista jest juniorem.”. Zgadza się, jeżeli programista jest juniorem, to ważne, aby więcej czasu poświęcał na dogadywanie się, aby lepiej zrozumieć, to co musi przedstawić w postaci kodu. Więcej pisałem o tym w Ja chcę pisać tylko kod, nie interesują mnie wymagania biznesowe!, celnie opisał, to również Mariusz w komentarzu: “Zgadzam się co do pierwszej części. Ale nie co do radosnego, pełnego optymizmu i napędzanego beztroską twórczością juniora! Taki nie czeka na detale tylko chce natychmiast kodzić!”.
Kolejne komentarze pokazują, że kodowanie, to tylko jedna strona medalu. Zacznę od wypowiedzi Adama: “[…] To jednocześnie oznacza, że dbanie o jakość tworzonego kodu zaczyna się już na etapie ustaleń i komunikacji wewnątrz zespołu i warto do tego podejść poważnie, bo to potem rzutuje na implementacje.”. Dodam do tego odpowiedź Piotra: “Na ogół im wyżej tym więcej dogadywania się i budowania relacji. Bardziej niż dogadywanie się wolałbym powiedzieć, że ważniejszy jest impakt na danym poziomie i czy potrafisz go zrobić. Gdzie junior myśli o funkcji w danym produkcie, Senior o produkcie, Staff o kilku produktach, Principal o grupie różnych produktów a Distinguished o branży w której jest.”.
Z powyższego wyłania się następujący obraz. Jak w każdym projekcie, który wiąże się z pracą zespołową bardzo ważne są relacje z członkami zespołu oraz komunikacja. Każdy członek zespołu ma wpływ na dany element projektu i każdy powinien brać odpowiedzialność za swoją cegiełkę, którą dodał do projektu. Często powtarzam moim uczniom, uczennicom: nie przywiązujemy się do kodu źródłowego, ale bierzemy za niego odpowiedzialność, bo jedyną stałą w kodzie jest zmiana.
Patrząc na wcześniejsze akapity wiemy już mniej więcej jaka jest rola programisty, programistki w projekcie informatycznym. Jak może być w samym projekcie pokazują dwa komentarze, które skrajnie różnią się od siebie. Jarek napisał: “Weźcie to zróbcie jakoś na szybko bo w sumie to jakoś tak wyszło że klient to wie że to dostanie w piątek. A testy to sobie napiszecie po godzinach albo może w poniedziałek między retro a planingiem”. Natomiast Sławomir napisał: “[…] U nas w projektach nie mamy żadnego daily, raz na tydzień jest spotkanie, a wszystko jest w JIRA i każdy wie co ma robić. Jak jest problem to programiści zgadują się na chat lub szybko zdzwaniają się. W takim zdrowym układzie jest to gdzieś 90% pisania kodu i 10% spotkań, rozmów itd.”. Samemu brałem udział w podobnie zorganizowanych i niezorganizowanych projektach, warto mieć doświadczenie w różnych projektach.
Na koniec komentarz Jana, który pracuje w startupie: “99% / 1% Pracuję jak wynalazca: w jednym fajnym startupie tworzę framework (służy do wyświetlania 3D, obsługi nietypowego formatu pliku itp), który jest używany w aplikacji w App Store. I teraz tak: 99% czasu pracuję sam ze swoim umysłem i ewentualnie kodem na ekranie. 1% to jest sprawdzenie bazy z ziomkami w startupie. Wyznaczamy z grubsza szlak na następne dwa miesiące w pół godziny po czym ja się zamykam i wracam ze zrobionymi fajnymi rzeczami. Każda droga jest właściwa. Ta jest moja.”. Pokazuje, to że można wybrać inną drogę, taką, która będzie dla nas odpowiednia.
Podsumowując wynik ankiety był dla mnie zaskoczeniem, ale również dostarczył wielu cennych informacji w komentarzach. Mam nadzieję, że powyższe omówienie ankiety pozwoli programistom, programistkom lepiej zrozumieć ich rolę w projekcie informatycznym jako całości.
Polski 
English 