Nie lubię TEGO projektu!
Pracujesz już w branży programistycznej? Miałeś taki moment kiedy pomyślałeś „nie lubię tego projektu”? Albo byłeś jakoś podświadomie zdenerwowany faktem, że musisz pracować w jakimś projekcie? Bo dzisiaj tego dotyczy mój tekst.
Ten wpis jest krótkim przemyśleniem i chętnie bym ten temat rozwinął głębiej. Jednak teraz chcę w Tobie zaszczepić po prostu pewną myśl, nad którą chciałbym żebyś się zastanowił i dał znać czy się zgadzasz czy jednak uważasz, że jest kompletnie inaczej.
To nie tak jak myślisz
Przechodząc więc do sedna. Zacząłem się zastanawiać dlaczego nie lubimy swoich projektów. Co się dzieje, że pewnego dnia siadamy w pracy za biurkiem, patrzymy na kod i myślimy sobie „k***a, mam dość, czas zmienić pracę”?
I to co zauważyłem to fakt, że jak się człowiek nad tym zastanowi to w żadnym wypadku problemem nie jest kod. Kiedy pomyślę o najgorszym kodzie jaki widziałem. I o projektach z tym kodem, które największe zniechęcenie we mnie wywoływały to patrząc na to z perspektywy czasu przestaję postrzegać ten kod jako problem. Wręcz zauważyłem, że wychodząc z takiego projektu po kilku tygodniach mam taką myśl „kurde, ale by fajnie było go znowu mieć w rękach i spróbować to zmienić, a tam dodać taką jedną rzecz”.
Teraz pomyśl czy miałeś podobnie?
A teraz zastanówmy się głośno nad tym. Czy to przypadkiem nie jest tak, że my nieraz wręcz chcemy maczać palce w tym słabym kodzie. Chcemy poczuć tą satysfakcję kiedy rozplątaliśmy jakiś zawiły zlepek klas. Tylko nie mogliśmy tego zrobić.
I moim zdaniem główne powody są dwa.
Łapy przy sobie
Z pierwszym powodem na pewno się utożsamisz i od razu pomyślisz „faktycznie!”. Bo skoro wychodząc ze znienawidzonego projektu masz zaraz ochotę znowu złapać za jego kod to czemu nie zrobiłeś tego wcześniej? Bo był nad Tobą klient albo szef, który kazał Ci przestać myśleć o jakiejkolwiek zmianie czegoś albo pobawieniu się kawałkiem kodu. Tłamsił twoją chęć znalezienia przyjemności w tym co robisz. Bo nie wiem jak Ty ale ja mogę trzepać tygodniami takie same zadania polegające na przesuwaniu przycisku z lewej na prawą i z prawej na lewą. Ważne żeby pomiędzy nimi było wyzwanie. Najlepiej takie, które sam znalazłem. Zobaczyłem, że coś można usprawnić albo jakiegoś nietypowego buga naprawić i udało mi się to zrobić.
A potem klient mówi, że na nic nie ma czasu. Do tego zalewa nas zadaniami, które są bez sensu ale nie mamy prawa głosu. Albo powtarzane jest, że poprawki czy testy to się zrobi „później”. Tylko to później nie następuje miesiącami.
I jeżeli atmosfera pracy jest taka, że pracujemy jak w fabryce i codziennie patrzymy na ten kawałek, który nas kuje w oko i nic z tym nie możemy zrobić to wzrasta frustracja. Wzrasta poczucie, że nie mamy kontroli nad kodem, z którym pracujemy. A wystarczyłby jeden dodatkowy task wzięty do sprintu. Gdzie trzeba by pomyśleć i wykorzystać swoją wiedzę.
Nie mam pojęcia
Właśnie – wiedza. To drugi taki punkt moim zdaniem. Nie aż tak oczywisty. Bo ta frustracja związana z projektem może też wynikać z faktu, że projekt albo jakieś zadania w nim nas przerastają. Nie chodzi mi tutaj o sytuację gdzie trzeba douczyć się jakiejś biblioteki. Bo to może być fajne. Bardziej mam na myśli moment kiedy zostałeś wrzucony do projektu, którego skala wymaga doświadczenia, którego nie zdążyłeś zebrać. Że np. będąc juniorami nie macie kogo zapytać jak podejść do problemu.
Na początku jest ten zryw ambicji „dam radę!”. Ale po czasie on cichnie. I zaczyna wygrywać poczucie, że nie nadajemy się do tego. Sam tak miałem. Byłem w projekcie gdzie narzucony mi zestaw zadań przerastał moje doświadczenie i możliwość szybkiego douczania się. Czułem, że nie dam rady. I nie chodziło o kod. Bo jak napisałem słaby to chciałem go uczynić lepszym. Ale to wymagało czasu i pewne rozwiązania poznałem dopiero po paru latach. W tamtym momencie to było za wiele.
Zgadzasz się ze mną? Też sądzisz, że tak naprawdę mimo, że mówimy, że projekt jest słaby bo ma słaby kod to tak naprawdę nie on jest problemem, który nas denerwuje? A może uważasz, że to zupełnie nie tak i to właśnie słaby kod jest tym najgorszym punktem, który zmusza do zmiany projektu? Podziel się swoją opinią w komentarzu.
Patrzysz oczami pracownika, który może zmienić projekt przez zmianę pracy.
Ja od ponad 10 lat rozwijam/utrzymuje jeden program. Taki wybór ścieżki zawodowej (wlasna firma/produkt). Mam wpływ na wszystko: technologie, testy itd.
Przez te lata jest taka sinusoida, czasem doslownie „żygam” tym co robię, czasem jest super fajnie, jak powstaje nowy moduł/funkcjonalność. Jak w życiu pełna paleta barw.
Tak, piszę z perspektywy pracownika. Kiedy robisz swój produkt to jednak jesteś bardziej producentem/właścicielem, a nie po prostu programistą.
Jednak nadal sądzę, że część z tych rzeczy się propaguje na autorskie rozwiązania. Bo kiedy one stają się dla nas uciążliwe – kiedy klienci cisną i nie ma czasu na usprawnienia albo kiedy doszliśmy do ściany z wiedzą. I przez to utrzymanie takich projektów staje się coraz bardziej męczące.
Jedyna różnica jest taka, że nie możemy zmienić projektu tak łatwo.
może i pracuję w słabym projekcie, ale go szanuję, bo ten projekt płaci moje rachunki.