Menu Zamknij

Czujesz Przywiązanie Do Swojego Kodu? To przestań!

Czy Twojego kodu również nie wolno dotykać?

Czas czytania: 5 min

Każdy programista jest ze stali i poza kawą nie potrzebuje nic, aby zamieniać marzenia w kod. Jednak czasami nawet taka wspaniała machina musi się poddać chorobie. W takich przypadkach, w szczególności w trakcie trwania nowego projektu, kolega czy koleżanka musi przejąć Twoją część kodu. Może to być moduł, a może cała aplikacja. Pracowałeś nad nim na tyle długo, że udało Ci się wytworzyć do niego przywiązanie.

Po chorobie wracasz do swoich zajęć i spoglądasz na swój dawny kod. Nie przypomina tego co zostawiłeś. Kilka dobrze przemyślanych koncepcji zostało zmodyfikowanych. Nieznaczenie, ale jednak. Dodatkowo wydaje się, że zmiennik nie pojął jak sobie to wyobrażałeś dalej. Przecież w tym wspaniałym kodzie, który zostawiłeś było wszystko jasne. I nagle czujesz złość i przypomina Ci się zdanie z filmu:

Look how they massacred my boy…

Ojciec Chrzestny

Brzmi znajomo? Czy nie raz tak samo myślałeś o swoim kodzie? Na pewno chociaż raz zdarzyło Ci się powiedzieć, może w myślach, a może na głos: „Ależ to elegancko zrobiłem! No świetnie mi poszło! I ktoś to musiał dotykać…”.

Dlaczego przywiązanie do swoich tworów jest tak silne?

W przeprowadzonym w 2011 roku eksperymencie poproszono grupę badanych, aby na podstawie instrukcji stworzyli żaby lub żurawie z origami. Wskazówki były dosyć skomplikowane, więc zadanie było stosunkowo trudne. Pod koniec pracy mogli odkupić stworzone przez siebie dzieła. Kwotę mieli zaproponować sami. W eksperymencie brała również udział druga grupa, której zadaniem było niezależna wycena papierowych zwierząt.

Instynkt przywiązania kontra żuraw z papieru

Wyniki były zaskakujące. Okazało się, że osoby, które stworzyły żaby czy żurawie z origami były skłonne zapłacić średnio 5 razy więcej za swoje działa niż wyceniały je osoby z drugiej grupy. Co więcej – w drugim eksperymencie, gdzie instrukcje były pozbawione kluczowych objaśnień, tendencje się powiększyły. Twórcy byli skłonni zapłacić więcej, a druga grupa wyceniała ich dzieła niżej niż w pierwszym eksperymencie (oczywiście dlatego, że z powodu braku odpowiedniej instrukcji origami były mocno nieudane).

Efekt Ikea

Autorzy eksperymentu nazwali powyższe obserwacje „efektem Ikea”. Własny wkład w pracę może sprawić, że jej wyniki są przez twórców wyolbrzymiane. Tendencja zwiększa się w miarę trudności wykonanej pracy. Ikea została wybrana z powodu sposobu, w jaki dostarczają swoje produkty, a więc do samodzielnego montażu. Jeden z autorów twierdzi, że fakt ten jest jednym z czynników, który spowodował taką popularność firmy. Praca nad składaniem mebli sprawia, że ludzie czują się z nimi mocniej przywiązani. A im bardziej skomplikowany jest mebel i im mniej doskonale wyszedł – tym bardziej!

Może i to łachmany, ale są mi drogie.

Molier

Instynkt dziecka

Gdy tworzymy coś własnymi rękami to nabiera to w nas mistycznych wartości. Tyle pracy. Tyle przemyśleń. A jeszcze, jak nie mieliśmy pomocy i to doskonale działa! Dla takich rzeczy mamy specjalne miejsce w sercu. Zdarza się, że ktoś nie podziela naszego entuzjazmu i ma uwagi do naszego dzieła. Zazwyczaj wtedy odczuwamy przynajmniej delikatne ukłucie.

Czy wynosimy zbytnie przywiązanie do własnych tworów z dzieciństwa?

Ale skąd to się bierze? Być może jest to w nas głęboko zakorzenione. Wszystkie niemowlęta i małe dzieci są bardzo egocentryczne. Z punktu widzenia przetrwania to oczywiście dobrze. Zaś z punktu widzenia życia w społeczeństwie i rozwoju już mniej. Z czasem to oczywiście przemija. Ale czy na pewno wyzbywamy się tej cechy do końca? Czy możemy jak dzieci zakrywać rękami oczy i myśleć, że otaczający świat i zdanie innych nie istnieje, a nasze wytwory są pozbawione wad?

Jak przywiązanie ma się do pracy programisty?

Przywiązanie do swojego kodu ma zarówno pozytywne, jak i negatywne strony.

W umiarkowanym przywiązaniu pozytywne jest z pewnością większe zaangażowanie w projekt. Może też świadczyć o tym, że programista na prawdę kocha to co robi. To z kolei sprawia, że jest wydajniejszy, pracowitszy i bardziej zadowolony z pracy. Dodatkowo może to oznaczać, że rozwiązanie jest dokładnie przemyślane i skrupulatnie przetestowane.

Wybierz pracę, którą kochasz, i nie przepracujesz ani jednego dnia więcej w Twoim życiu.

Konfucjusz

Na co jednak należy uważać, jeżeli chodzi o zbytnie przywiązanie do własnego kodu.

Nie jesteś swoim kodem

Doświadczony programista potrafi oddzielić kim jest od tego co tworzy. Umiejętność radzenia sobie z krytyką ma tutaj niebagatelne znaczenie. W przypadku, gdy ktoś niepochlebnie (ale konstruktywnie) opisuje rozwiązanie nad którym pracowałeś, warto zdać sobie sprawę, że komentuje kod, a nie twórcę. Zadaniem code review jest dbanie o wysoką jakoś kodu, a nie walka osobowości.

Krytyka służy rozwojowi. Z każdej sugestii należy wyciągać wnioski i stawać się lepszym w tym co się robi. Dobre sugestie należy wdrażać, o złym kodzie zapominać i dbać, aby w przyszłości kod był zwyczajnie dobry, a nie „mój”, „Twój” czy jeszcze kogoś innego.

Na temat przyjmowania krytyki napisałem również kilka słów w artykule o umiejętnościach, które zwiększają szansę na awans.

Nie taki kod dobry, jak go malują (a raczej malujesz)

Przywiązać można się również nie tyle do kodu, co do sposobu, w jaki implementowane są rozwiązania. Mam na myśli zarówno sposób postępowania z etapów wytwarzania oprogramowania, jak i dobór technologii, bibliotek czy języków.

Mózg ludzki lubi schematy. Gdy rozwiązanie jest już znane i sprawdzone to nie ma powodu, żeby je zmieniać, nieprawdaż? No… i tak i nie. Wszystko zależy od sytuacji. Warto jednak pozwolić sobie na myśl o zmianach. Nie należy przywiązywać się zbytnio do „utartych schematów”. Najważniejszy jest zdrowy balans pomiędzy rozwojem i utrzymaniem.

Praca zespołowa, a przywiązanie do kodu

Fakt, że inny pracownik nie widzi jak oczywiste jest dane rozwiązanie lub pisze kod całkiem inaczej niż sobie to wyobrażamy może prowadzić do irytacji. Warto się jednak zastanowić czy to odpowiednia droga. Moim zdaniem nie.

Zbytnie przywiązanie do własnego kodu w zespole nie działa

Zirytowanie w takim przypadku wynika ze złego nastawienia i braku zrozumienia mechanizmu pracy w zespole. Każdy programista ma inną wizję kodu i inne doświadczenia. Czasami doświadczony programista nie widzi rozwiązania, które jest oczywiste dla kolegi z mniejszym stażem.

Najlepsze zespoły składają się z ludzi, którzy się od siebie różnią i uzupełniają swoje braki. Daje to możliwość spojrzenia na problemy z różnych perspektyw i szybsze odnalezienie najbardziej optymalnej drogi.

Podsumowanie

Pomimo, że przywiązanie do kodu może mieć pozytywne podłoże to warto nabrać dystansu do własnych wytworów. Przyjmuj konstruktywną krytykę, poprawiaj swój warsztat, wciąż się ucz od innych i dbaj, aby każdego dnia Twój kod był lepszy. Tylko tyle i aż tyle.

W przypadku jakichkolwiek pytań – jeżeli coś wydało się ciekawe – jeżeli chcesz, abym coś rozwinął – proszę napisz lub zostaw komentarz! Chętnie odpowiem.