Flow w programowaniu

Słowem “Flow” określamy taki stan świadomości, w którym “czas płynie”, jesteśmy “zanurzeni” w chwili obecnej, pracujemy na najwyższych obrotach przy odczuwając największą możliwą satysfakcję praktycznie bezwysiłkowo. (więcej…) Każdy z nas prawdopodobnie doświadczył podobnego stanu, pracując, tworząc lub bawiąc się. Bycie w tym stanie świadomości powoduje również, że jesteś bardzo produktywny i spełniony zarazem. Powstaje pytanie, jak wchodzić w stan flow “na żądanie”? Wtedy kiedy najbardziej potrzebujesz, lub po prostu wtedy gdy chcesz się świetnie czuć? Jest wiele czynników pomagających pojawieniu się “Flow’. Skupię się na tych (zwanych czynnikami psychologicznymi), które często wywołują ten stan podczas programowania. Dlaczego akurat na tych? Bo dość łatwo samemu można zadbać by poniższe warunki zaistniały i wprowadziły Cię we “Flow”.

1. Klarowne cele – siadając przy komputerze musisz mieć cel, musisz wiedzieć co za chwilę zaprogramujesz. Im bardziej klarowny cel, tym większy wpływ tego czynnika na twój “Flow”. Przez klarowność rozumiem tutaj język programowania, IDE, znajomość środowiska, skrótów klawiaturowych, rozmieszczenie plików w projekcie, kompilator, dane wejściowe, specyfikacja końcowa, czyli jak najwięcej czynników, które doprecyzują nam ten cel. Bardzo dobre jest również napisanie testów automatycznych (w formie np. unit-testów), które w formalny sposób doprecyzują Ci cel i spowodują, że stanie się klarowny. (często konkursy programistyczne definiują zestaw danych, po których program zostanie zaakceptowany, więc tak zdefiniowany cel jest bardzo klarowny, daje Ci pewność tego, jakie warunki muszą zaistnieć, by cel został uznany za zaakceptowany).
2. Natychmiastowy feedback – inaczej też czas pomiędzy przyczyną a skutkiem, czas pomiędzy dopisaniem linii kodu a rekompilacją programu (i otrzymaniem wyników testów). Im krótszy czas, tym większy wpływ tego czynnika na “Flow”. Zauważ, że kompilator daje całkiem niezły feedback, IDE potrafią podkreślać, błędy w trakcie pisania, bardziej skomplikowane błędy kompilator wykryje w kilka sekund, a przy dobrym pokryciu testami dostaniesz tę informację zwrotną w kilkanaście sekund. Taki feedback bardzo pomaga, dlatego unit-testy dają dodatkowe “punkty do produktywności”, a nie tylko pozwalają utrzymać kod w dobrym stanie. Klarowny cel mówi Ci o tym co robimy, a feedback daje info jaki postęp zrobiliśmy (np. 100 testów przechodzi, 20 nie działa). Również z tego powodu nasza wydajność spada gdy czas kompilacji jest zbyt długi.
3. Stosunek trudności wyzwania do umiejętności (“The challenge / skill ratio”) – ten czynnik mówi o tym, jak trudne jest dla Ciebie postawione zadanie, w stosunku do tego co już umiesz. I tutaj jest inaczej, niż w poprzednich. Zbyt duży stosunek trudności do umiejętności spowoduje, że zaczniesz odczuwać stres a później nawet strach. Zbyt mały spowoduje, że czujesz znudzenie i robisz rzeczy mechanicznie/bezmyślnie (i ewentualnie rozmyślasz jak napisać skrypt, który by robił to za Ciebie…). Optymalizacja tego czynnika polega na wybieraniu odpowiedniego “kanału“, w którym “Flow” będzie najintensywniejszy. Czyli balansowanie pomiędzy nudą a stresem, zadanie musi być na tyle trudne, by Cię rozwijało i ekscytowało, ale nie aż tak trudne, żebyś czuł się zrezygnowany. Podczas programowania mamy wiele sposobów jak poruszać oboma krańcami tego kanału, by trzymać ten czynnik na wysokim poziomie. Weź np. proste zadanie napisać funkcję obliczającą kolejne liczby fibonaciego.  Zbyt łatwe? Utrudnij trochę, napisz wersję liniową, napisz wersję logarytmiczną, napisz wersję obliczającą do licz z milionem cyfr, dołóż ograniczenie na wielkość alokowanej pamięci, lub ilość znaków w programie. Może dołożysz jeszcze zakaz korzystania z innych bibliotek i dodasz wymaganie konkretnego języka, oraz zakaz googlowania? Robiąc to znajdziesz właściwy punkt, w którym zwiększą się szanse na flow. W ten sposób ruszasz jedną ze ścian tego kanału. Jak to zrobić w drugą stronę? Wyzwanie jest zdecydowanie za trudne? Możesz zastosować “chunking” czyli podział zadania na mniejsze kawałki. Możesz napisać najpierw prototyp, lub kilka, wyodrębnić kod, który już umiesz napisać do klas pomocniczych, znaleźć kogoś kto robił podobną rzecz i spytać go, zadać otwarte pytanie w internecie itd. Spytać siebie o to, jakie przyjmujesz założenia i czy możesz się na początek pozbyć niektórych z nich. Umiejętne przesuwanie ścian tego kanału spowoduje, że stan flow będzie dużo łatwiejszy do osiągnięcia.

Po więcej na temat samego “Flow” zajrzyj do książki “Bold” Peter Diamandis, Steven Kotler, na strony 88-94. (Amazon…)