Gra w programowanie

Czy grałeś kiedyś w naprawdę wciągającą grę wideo? Pewnie tak. Kiedy jesteś zanurzony w grze, czas i świat dookoła przestaje istnieć. Jesteś skupiony i gotowy poświęcić wiele, by osiągnąć wyznaczone w grze cele. Mechanizm, któremu ulega gracz siedzący przed ekranem przez wiele godzin, jest naprawdę potężny i… użyteczny. Można go wykorzystać w wielu obszarach życia. Ten mechanizm został opisany jako Flow (Przepływ).

Flow

Stan, w którym jesteś naprawdę zanurzony w to, co robisz. W którym tracisz poczucie czasu, zapominasz o swoich codziennych problemach. Pomysł pochodzi z książki Flow: Psychologia optymalnego doświadczenia, której autorem jest Mihaly Csikszentmihalyi.

Opisuje on to zjawisko następująco:

Człowiek staje się tak zaangażowany w to, co robi, że aktywność staje się spontaniczna, prawie automatyczna. Przestaje być świadomy samego siebie jako osobnego bytu, czegoś oddzielnego od tego, co robi.

Istnieją 3 najważniejsze składniki pozwalające na osiągnięcie Flow: jasny cel, informacja zwrotna i odpowiednie wyzwanie. Dlaczego wspomniałem o grach wideo? Są one naprawdę dobre w stymulowaniu Przepływu:

1. Jasny cel. Rozgrywka narzuca Ci pewne zrozumiałe zadania do wykonania. Zabij potwora, znajdź pokemona, zdobądź miasto.
2. Natychmiastowa informacja zwrotna. Gdy uda Ci się zrealizować zadanie, zazwyczaj od razu dostajesz o tym informację oraz nagrody za osiągnięcia — przedmioty pozostawione przez potwora, punkty doświadczenia, pieniądze.
3. Wyzwanie dostosowane do kompetencji. Gry dopasowują swoją trudność do gracza, z upływem rozgrywki stawiane wobec Ciebie wyzwania są coraz większe.

Potraktuj pracę jako grę

Mechanizmy, które działają na nasz umysł, by utrzymać naszą uwagę przed monitorem, podczas grania w ulubioną grę, możesz wykorzystać w swojej pracy.

Jasny cel

W większości gier mamy do czynienia z czymś na kształt systemu misji. Musimy wykonać zadania, które powoli doprowadzą nas do realizacji głównego celu: podbicia świata czy pokonania największego wroga. Wykonywanie mniejszych zadań pozwala nam nie pogubić się w ogromie możliwości, cały czas mieć jakiś cel w zasięgu wzroku i móc się cieszyć z sukcesów od samego początku rozgrywki. Podobnie jest w przypadku pracy, gdzie idealnie jest mieć niewielkie zadania, których wykonanie to bardziej kwestia godzin, niż dni. Taki drobny podział pozwala na uchwycenie całości tego, co mamy do zrobienia i koncentrację na rozwiązaniu obecnego problemu, co sprzyja wejściu w stan Flow.

Problem w tym, że taki podział jest często utopią. W praktyce często to, nad czym pracujemy, jest bardzo duże, albo nie do końca na początku zdefiniowane. Można grzmieć na Product Ownera, który źle podzielił pracę zespołowi, a można próbować radzić sobie z tym samemu. Świetnie, jeśli user story lub zadanie, za które się zabieramy, jest już podzielone na mniejsze subtaski. Jednak nawet jeśli tak nie jest, warto podzielić je sobie samemu na własne potrzeby. Można stworzyć własną checklistę i odhaczać sobie poszczególne zadania.

Natychmiastowa informacja zwrotna

Pamiętasz sytuacje, gdy napisałeś fragment kodu i, żeby upewnić się czy działa, musiałeś przebudować i postawić na nowo całe środowisko testowe? Gdy musiałeś czekać kilka minut, patrząc tępo w ekran i czekając na efekt uruchomienia jakiegoś skryptu?

Jesteśmy niecierpliwi i jeśli musimy czekać więcej niż kilka sekund na ocenę naszych starań, to zabija naszą produktywność, bo od razu nasza uwaga zaczyna odpływać. Przypomnijmy sobie, jak działają gry — tam informacja o rezultatach naszych działań i ewentualna nagroda są natychmiastowe.

Dlatego właśnie uwielbiam TDD. Piszę linię kodu, odpalam przygotowany wcześniej zestaw testów… i natychmiastowy werdykt: działa albo nie. Od razu mogę wrócić do pracy i poprawić kod albo napisać następny test. Złapałem się nawet na tym, że zielona ikonka obok nazwy testu w IntelliJ-u działa na mnie jak nagroda. Zupełnie jak punkty doświadczenia po zabiciu potwora.

Zdarza mi się napisać z góry sporą liczbę testów, które dany fragment kodu ma przejść. Potem staram się po kolei spełniać kolejne wymagania i patrzę, jak wyniki testów stopniowo zmieniają kolor z czerwonego na zielony. Takie podejście potrafi być naprawdę satysfakcjonujące.

Wyzwanie

Spoglądam do backlogu, by wyjąć z niego nowe zadanie. Kolejne zadanie polegające na dodaniu checkboxa na UI-u, kolejne kopiuj-wklej… Cóż, to się zdarza i takie sytuacje skutecznie zabijają zapał do pracy.

Wyzwanie sprawia, że mam chęć do zmierzenia się z nim. Jeśli takiego wyzwania nie widzę, pozostaje bezmyślne klepanie, które nie jest przyjemne, więc odsuwam to od siebie tak długo, jak mogę.

Jednak dużo zależy od naszego podejścia. Niekiedy wyzwanie możemy sobie stworzyć sami. Można potraktować proste zadanie jako okazję, by dokonać dawno proszącego się refactoringu w klasie, w której mamy dokonać zmiany. Może istnieje przestrzeń do poprawy wydajności kodu?

Programiści mają tendencję do narzekania na brak czasu na refactoring. Takie zadania to idealna okazja, by wykonać je błyskawicznie i mieć trochę czasu na zmianę, do której od dawna się przymierzaliśmy. Nie tylko stajemy się w ten sposób lepszym programistą, ale tworzymy wyzwanie tam, gdzie pozornie go nie ma i sprawiamy, że praca staje się bardziej wciągająca.

Poszukiwania

Sposoby, które podałem działają doskonale na mnie. Możliwe, że w przypadku niektórych z Was skuteczniejsze okażą się inne techniki. Warto poszukać swoich własnych rozwiązań.

Zaprezentowane powyżej sposoby nie tylko pozwalają nam być bardziej produktywnymi pracownikami. Uważam wręcz, że to mniej ważna z korzyści. Dzięki podejściu do pracy jak do gry i wchodzeniu w stan Flow zwyczajnie czerpiemy więcej radości z pracy. Wymaga to trochę poświęcenia, jednak efekty są naprawdę satysfakcjonujące.

Przypomnijmy jeszcze raz, aby zwiększyć swoje szanse na osiągnięcie Flow:

• • Wyznacz sobie jasny cel i skup się tylko na nim
  • Zapewnij sobie szybką informację zwrotną
  • Dopasuj wyzwanie do swoich kompetencji

Zobacz też: 3 Skuteczne Podejścia do Pair Programming