Jak programista widzi świat?

Drugim postem na swoim blogu postanowiłem wejść wszystkim programistom do ich głów i zrobić swoistą psychoanalizę postrzegania przez nich rzeczywistości.

Czemu nie? 🙂 Zrobię to na przykładzie fikcyjnych dialogów, fikcyjnych deweloperów na fikcyjnym spotkaniu.

Oczywiście nie mam ku temu żadnego wykształcenia. Jestem deweloperem jak wielu innych, obdarzonym umysłem ścisłym, patrzącym logicznie i racjonalnie na otaczający go programistyczny świat i problemy z jakimi zmagam się na co dzień. Ale czy na pewno, tak bardzo racjonalnie jak mi się wydaje?

Jak działa umysł?

Szybko. Ilość informacji, którą nasz mózg otrzymuje na wejściu jest ogromna. Gdyby chciał to wszystko przetwarzać i analizować wyniki jego pracy przestały by być efektywne. Podobno to kwestia ewolucji. Gdy coś zaszeleściło w prehistorycznych krzakach, nasz pra-pra-…-pradziadek (dajmy na to homo erectus) nie miał czasu na zastanawianie się “czy to aby nie tygrys?”. Aby przetrwać, lepiej dla niego było podjąć decyzję szybko, czyli po prostu schrzaniać gdzie pieprz rośnie. Może to kwestia ewolucji, może nie, ale musimy się pogodzić z tym, że nasz umysł opiera swoje działanie na skrótach myślowych. Właściwie powinniśmy mu być za to wdzięczni. To jest jego fantastyczna cecha.

W ciągu sekundy ludzki umysł otrzymuje około 11 milionów bitów informacji pochodzących z naszych zmysłów (źródło Britannica). Zakładając, że przeciętny człowiek potrafi przeczytać ze zrozumieniem 5 słów na sekundę, daje nam to prędkość świadomego przetwarzania informacji na poziomie 50 bitów/sekundę. Można zauważyć jaką niewiarygodną pracę wykonuje nasz mózg filtrując i kompresując informacje wejściowe do poziomu akceptowalnego przez świadomość.

Ta jego fantastyczna cecha ma jeden mały minusik. Wcześniej wspomniane skróty myślowe niestety prowadzą do błędów… tzw. błędów poznawczych.

Przejdźmy do przykładu.

Fikcyjna rozmowa fikcyjnych deweloperów – pełna błędów poznawczych

W moim fikcyjnym spotkaniu bierze udział grupa deweloperów. Każdy z nich jest innym człowiekiem, z innym bagażem doświadczeń, innym temperamentem. Patrząc na obrazek poniżej, to raczej startup niż korporacja 😉

A nasza rozmowa mogłaby się rozpocząć np. tak:

Mamy zamówienie na wykonanie nowego dużego sklepu internetowego… zamówienia, płatności, dostawa, magazyn.

Super! Zrobimy to w końcu na mikroserwisach! Użyjemy tej szyny komunikatów, o której wam ostatnio opowiadałem i deployujemy na Azurze.

Jak widać nasz Dev1 to dynamiczny programista, wie jakie są trendy w programowaniu. Teraz każdy deweloper, dbający o ostrość swojej piły, robi w mikroserwisach i w chmurze. A jeżeli już mowa o trendach, w psychologii poznawczej istnieje pojęcie tzw. zasady podczepienia, czy też mówiąc prostym językiem, owczego pędu.

Zasada podczepienia (ang. bandwagon effect) mówi, że ludzie często wierzą w pewne rzeczy lub robią je jedynie dlatego, że wiele innych osób tak robi. Najczęściej mówimy o tym zachowaniu w odniesieniu do polityki lub marketingu. Nie od dziś wiadomo, że my – konsumenci kupujemy częściej konkretne produkty tylko dlatego, że inni też tak robią. A my – programiści? Jak to wygląda w naszym świecie? Otwierasz facebook’a lub twitter’a a tam mikroseriwsy, serverless, DDD albo chmura 🙂 Idziesz na konferencję, meetup’a a tam… to samo 🙂 Śmiem twierdzić, że pojęcie mody i trendów jest tutaj bardzo mocno widoczne.

I co na to nasz mózg? I co na to mózg naszego Dev1?

Pozostawię to pytanie (jak i wiele innych) bez odpowiedzi, do przemyślenia przez każdego z Was. Wróćmy do rozmowy.

Nie wiem czy mikroserwisy są najlepszym pomysłem. Zobaczycie, na tych powiązaniach, dziesiątkach baz, debugowaniu tego wszystkich po prostu polegniemy. Zróbmy po staremu, tak jak wcześniejszą aplikację. Przynajmniej wiemy, że działało. A przy okazji starego projektu napisałem świetny system do zbierania metryk! Wykorzystamy go. Od strzała będziemy mieli zagregowane dane: czasy odpowiedzi, metryki systemu.. cud, miód.

Co ty gadasz ?! Mikroserwisy zapewniają lepszą skalowalność, mogą być rozwijane niezależnie i łatwiej wdrażane na produkcję. Ta aplikacja będzie duża i składała się z kilku modułów. Mikroserwisy pasują tutaj idealnie.

Nasz nowy bohater – Dev2 to bardzo racjonalny programista. Stawia na sprawdzone rozwiązania. Jak jest sprawdzone to będzie działać, a jak będzie działać to ‘mission accomplished’. Czyżby? A może jego umysł działa pod wpływem dwóch małych robaczków: efektu Ikea i efektu status quo.

Efekt Ikea – to błąd poznawczy, który sprawia, że większą wartość przypisujemy rzeczom, w wykonaniu których mieliśmy swój udział. Nazwę swą zawdzięcza oczywiście szwedzkiemu producentowi mebli i poczuciu satysfakcji, które ponoć ogarnia nas po złożeniu tych cudownych szafek i łóżek 🙂 Trud włożony w ich składanie zwiększa nasze przywiązanie do nich. Tak samo trud włożony w dewelopment danego kawałka aplikacji może zmienić nasz sposób jego postrzegania.

Efekt status quo – to z kolei tendencja do zachowania aktualnego stanu rzeczy. Podświadomie budzi w nas lęk przed zmianą. Zmiana traktowana jest przez nasz umysł jako strata, szkoda. I tu z kolei na scenę wchodzi kolejny błąd poznawczy – niechęć do straty. Pociąga on za sobą nadmierną ostrożność przy ryzykowaniu utraty czegoś, co się już posiada, np. wypracowanej i sprawdzonej architektury aplikacji, którą teraz będziemy stosować do każdego nowego projektu, żeby nie narażać się na wspomniane ryzyko.

Z drugiej strony Dev1 całkowicie zafiksował się na punkcie mikroserwisów. W końcu dobrego rozwiązania trzeba bronić do upadłego. A może to wpływ: efektu potwierdzenia?

Efekt potwierdzenia (ang. Confirmation bias) – to skłonność do wybierania tylko tych informacji i argumentów, które potwierdzają wcześniej przyjęte przekonania i pomijania tych, które im zaprzeczają. Wpływa na obniżenie skłonności do zmiany decyzji. Nawet gdy nasza decyzja jest obiektywnie błędna będziemy się starać szukać dowodu, że tak nie jest. Niejednoznaczne informacje interpretować w taki sposób aby nagiąć je do naszego stanowiska.

Może Dev1 wybiera tylko cechy nowego projektu, które faktycznie pasują do mikroserwisów? Może patrząc na mikroserwisy, podświadomie marginalizuje ich wady?

Dev2, a to Twoje zbieranie metryk ostatnio nie wywaliło się na produkcji?

W myślach: Jak wszystkie twoje aplikacje, zawsze musimy sprzątać po Tobie.

O takie uwagi bardzo łatwo podczas gorących dyskusji. Zwłaszcza gdy w naszej głowie hasa sobie tzw. efekt aktora-obserwatora. Co prawda system metryk faktycznie wywalił się ostatnio na produkcji, ale w historii firmy komponenty Dev1 też miały swoje problemy. Te jednak w głowie Dev1 były zawsze dziełem złego zrządzenia losu lub efektem złych założeń złego biznesu 🙂 Może tak, a może to właśnie efekt aktora-obserwatora?

Efekt aktora-obserwatora (ang. Actor-Observer Bias) – to asymetria w postrzeganiu działań w zależności czy są to nasze działania, lub działania w których bierzemy w nich udział, czy tylko je obserwujemy. Nasz umysł ma tendencję tłumaczyć cudze zachowania cechami danej osoby, natomiast podobne nasze zachowania tłumaczyć wpływem czynników zewnętrznych. Jak często pojawia Ci się np. w głowie myśl.. ale on to długo pisze, ja bym to napisał 2 razy szybciej. Jak można być tak mało wydajnym programistą?! A może właśnie wtedy trzeba popatrzeć na szerszy kontekst

Nie mamy doświadczenia w mikroserwisach. Czy to nam nie zajmie za dużo czasu? Zdążymy z terminami?

Samą architekturę postawimy w 2 tygodnie ! A potem już kopiuj/wklej i implementacja logiki biznesowej tak jakbyśmy pisali po staremu.

Taak.. patrząc z boku to od razu wygląda jak złudzenie.. złudzenie planowania.

Złudzenie planowania (ang. Planning fallacy) – jest tendencją do niedoceniania czasu, ryzyka, kosztów potrzebnych na ukończenie zadania. Często padamy ofiarą tego błędu, znając historyczne dane, które mogą przeczyć naszym założeniom. Powodem jest nadmierny optymizm, opieranie założeń na scenariuszu, w którym wszystko przebiega bezproblemowo, bez nieprzewidzianych trudności. Tylko, czy tak wygląda praca programisty?

Zróbmy te mikroserwisy ! Oglądałem świetne video o tym jak to zaimplementować. Po spotkaniu siądę i szybko zrobię Proof of Concept!

Dev3 musi działać. Jego jestestwo jest podyktowane ilością napisanego kodu. Nie widzi zagrożeń wynikających z podjętej decyzji, ale widzi już otwarte IDE, w którym zakłada nowy projekt. Może w jego głowie ukrył się mały robaczek o nazwie: action-oriented bias

Action oriented bias – powoduje powstanie w naszych głowach presji działania. Ta presja wywołuje w nas nadmierny optymizm co do otoczenia w jakim działamy. Sprawia, że pomijamy wpływ środowiska i zdarzeń losowych na efekty naszych działań.

Dev4, a Ty co o tym sądzisz?

Tak, zróbmy mikroserwisy.

W myślach:A może jeszcze za wcześnie na wybór architektury, może należałoby skupić się na wymaganiach, na potrzebie klienta. Ale co ja wiem, chłopaki wiedzą co robią.

Ciekawe podejście pojawiło się w głowie naszego Dev4. Niestety nie zostało ono wyartykułowane. Może stało się tak, dlatego, że umysł Dev4 został zmanipulowany przez efekt Dunninga-Krugera?

Efekt Dunninga-Krugera – jest błędem poznawczym, który sprawia, że osoby o niskich kwalifikacjach w danej dziedzinie mają tendencję do przeceniania swoich umiejętności. Z drugiej strony zaś, osoby wysoko wykwalifikowane mocno zaniżają swoja ocenę. Może to przejawiać się brakiem pewności siebie. Co z kolei może prowadzić do konformizmu społecznego, czyli chęci podporządkowania się poglądom obowiązującym w danej grupie społecznej.

Czy każde nasze zachowanie powinniśmy tłumaczyć nieracjonalnością naszego umysłu? Podsumowanie.

Lista błędów poznawczych jest dużo dłuższa. Ja wybrałem te, z którymi sam walczę w swojej głowie (na prawdę to napisałem?;). Jednym z błędów, o którym nie napisałem, jest efekt ślepej plamki, czyli niezauważania błędów we własnej ocenie rzeczywistości. A z drugiej strony, nie trzeba wiele wysiłku, żeby każde nasze zachowanie wytłumaczyć jakimś błędem poznawczym. I jak tu żyć?

Myślę, że to kwestia szczerości, z samym sobą, przeanalizowania bez emocji naszych zachowań z przeszłości. Zastanowienia się, dlaczego zachowaliśmy się tak a nie inaczej. Na ile to zachowanie było nieracjonalne i jakie były jego skutki. Skupmy się na faktach. Spytajmy się innych osób jak wyglądamy w ich oczach. Gdy będziemy świadomi naszej tendencji do ulegania błędom poznawczym będziemy mogli z nią walczyć.

Ale o tym kolejnym razem.

Jeżeli podobał Ci się ten post, proszę napisz mi o tym. Będzie mi też super miło jeżeli udostępnisz go swoim znajomym.. programistom, nieprogramistom.. wujkowi, cioci 🙂 Każdemu, komu może on dać wartość.

Please follow and like us:

błędy poznawcze, cognitive biases, soft

Maciej Etgens

View all posts by Maciej Etgens →

newest oldest most voted

dotnetomaniak.pl

Jak programista widzi świat? | Maciej Etgens

Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl

Guest

Chaos

Dobrze sie czyta i sporo ciekawych informacji !

czarnooch

Pierwsze wrażenia: chopie skąd masz tyle wolnego czasu na pisanie takiego elaboratu??? 😉 Dobra robota! W pewnym momencie zacząłem się zastanawiać z którym z tych fikcyjnych programistów się utożsamiasz, bo chyba nie opisałeś tak wspaniałego fikcyjnego spotkania, fikcyjnych deweloperów (programistów) bez swojego udziału. Na koniec zadziwiła mnie liczba błędów jakie ludzie opisali o sobie samych. Ich mózgi stworzyły opisy błędów jakie oto ich mózgi generują Hehe Podsumowując zakończę stwierdzeniem, że z jednej strony uważam iż mózg jest niesamowicie prymitywnym tworem. Dostaje milony/miliardy informacji z czego zdecydowaną większość “wyrzuca do kosza” 😀 Z drugiej strony… czy mózg pracuje źle skoro rasa… Read more »

Author

Dzięki Matt. Skąd mam tyle wolnego czasu? Normalnie między pracą, rodziną, pisaniem po godzinach aplikacji i utrzymywaniem 2 innych 🙂 Myślę, że jestem po części każdym z tych programistów, chociaż coraz mocniej z tym walczę!