Mózg człowieka pracuje w dwóch trybach – skupionym oraz rozproszonym. Gdy pracujemy w trybie rozproszonym nasz umysł przeskakuje z tematu na temat. W trybie skupionym koncentrujemy się na jednym zadaniu i staramy się je doprowadzić do końca. W tym tekście postaram się przedstawić problemy, które możemy napotkać w codziennej pracy programisty oraz sposoby na ich rozwiązanie wykorzystujące te dwa tryby.

Laserowe skupienie na kodzie

    Praca programisty wymusza na nas silne skupienie się na problemach, odcięcie od otaczających bodźców. Pisanie czy analiza kodu wymaga utrzymania w pamięci krótkotrwałej wielu zmiennych, pojęć i intencji. Trudno jest to robić, gdy nasza praca jest ciągle przerywana.

    Nauka programowania jest pod tym względem jeszcze bardziej wymagająca. Ucząc się przyswajamy zupełnie nowe pojęcia, szeregujemy je i porównujemy do pojęć, które już znamy. Brak wystarczającego skupienia sprawi, że nauka będzie nieefektywna, w mózgu nie wykształcą się odpowiednie ścieżki neuronowe i nic nie zapamiętamy.

    Istnieje wiele metod na poprawienie skupienia w pracy:

• Słuchanie muzyki, białego szumu lub zakładanie nauszników przeciwhałasowych i stoperów
• Blokowanie rozpraszających stron
• Wyznaczanie sobie godzin, w których korzystamy z komunikatora lub wchodzimy na maila, by nie robić tego cały czas
• Technika pomodoro (praca w interwałach 25 minut z krótką przerwą) lub deep work – praca przez cały czas w pełnym skupieniu.

    Gdy zaczynamy pracę z myślą – “dzisiaj będę bardzo skupiony” – jesteśmy na dobrej drodze do zmiany statusu wszystkich bieżących zadań na “gotowe do testowania” i ogólnie osiągnięcia programistycznego szczęścia. Pracując w ten sposób piszemy dużo kodu i łatwo wchodzimy w stan flow, w którym uzyskujemy iluzję dobrze wykonanej pracy. Okazuje się jednak, że nadmierne skupienie może być niewystarczające
(a nawet szkodliwe), gdy mierzymy się bardzo trudnymi problemami.

Kiedy myślenie skupione może przeszkadzać?

    Wielokrotnie spotykałem się z sytuacjami, gdy ja albo któryś z moich kolegów próbował sprawić, aby kod zaczął działać przez wielogodzinne, bezskuteczne siedzenie przed komputerem. Gdy tylko oderwał się na chwilę od pracy na przykład odchodząc od komputera umysł podsuwał mu “na tacy” rozwiązanie problemu.

Gdy odrywamy się od problemu jest on nadal analizowany w naszej podświadomości a rozwiązanie często przychodzi samo.

    Bardzo frustrującym doświadczeniem jest gdy nasz program nie działa. Walcząc w trybie skupienia często skupiamy się na jednej wybranej ścieżce naprawy błędu. Przykładowo – mamy skonfigurowany cały komponent, ale nie pobiera on danych. Próbujemy z tym walczyć na wszelkie sposoby, obarczamy winą komputer lub wielokrotnie restartujemy program. Zakładamy że jest coś nie tak z implementacją i zmieniamy losowe rzeczy. Podchodzi do nas kolega, który nigdy nie widział naszego kodu i od razu wskazuje nam błąd – zapomnieliśmy podłączyć moduł do reszty aplikacji. Druga osoba nie miała żadnych założeń odnośnie do naszego kodu, spojrzała na niego świeżym okiem, nie skupiała się na szczegółach.

    Pracując w zbyt skupiony sposób możemy nie zauważyć oczywistych błędów, które następnie ktoś wytknie nam podczas przeglądu kodu. Gdybyśmy oderwali się na chwilę od danego zadania po jego ukończeniu (na przykład robiąc review komuś innemu) i wrócili do swojego kodu, byłoby nam równie łatwo znaleźć błędy.

    Efekty nadmiernego skupienia się mogą być jeszcze gorsze. Napisany przez nas fragment kodu może działać, ale potem okazuje się trudny w rozwoju. Może być konieczne przepisanie go od nowa, bo na przykład zawiera wiele “hacków” powstałych dlatego, że bardzo zależało nam na ukończeniu zadania. Rozwiązanie problemu może być źródłem kolejnych problemów, na przykład błędów w implementacji, które poprawia się miesiącami. Zamiast przemyśleć problem, stosujemy “programowanie przez permutację” albo wklejamy kod z Internetu, bez dokładnego poznania jak on działa. W ten sposób narasta dług techniczny.

    Czasem takie siłowe próby rozwiązania problemów kończą się tworzeniem koła na nowo. Implementujemy rozwiązania, które zostały już stworzone przez inne osoby, jednak nie wiedzieliśmy o ich istnieniu, bo cały czas byliśmy w pełni skupieni na swojej wizji rozwiązania.

    Ten problem dotyka często programistów, którzy niechętnie konsultują swoje rozwiązania z kolegami, traktują kod i pracę przez pryzmat własnego ego. Jeśli napotykamy się na problem w implementacji lub widzimy, że powstający kod jest coraz brzydszy należy przemyśleć rozwiązanie wychodząc ze stanu skupienia. Podejście – “nieważne jak, ważne by działało” nie sprawdza się w projektach, które trzeba rozwijać i utrzymywać.

    Może okazać się, że stworzyliśmy funkcjonalność, która zupełnie nie odpowiada potrzebom klienta. Praca w całkowitym skupieniu jest wtedy jak szybkie wchodzenie po drabinie przystawionej do złej ściany.

    W niektórych rzadkich przypadkach błędy w aplikacji można rozwiązać jedynie dzięki poszukiwaniu źródła problemu poza kodem, co także wymaga wyjścia z trybu skupionej pracy i analizy. Przykładowo – formularze w aplikacji, przy której pracowałem przestały działać mimo tego, że nie było w nich żadnych zmian od momentu kiedy ostatnio działały. Okazało się, że błąd występuje jedynie w nowej wersji Chrome, w której pojawił się bug. Błąd był dobrze opisany na Githubie i aby go naprawić wystarczy zmienić wersję przeglądarki. Skupiona analiza kodu w takim przypadku by nic nie dała.

Proponowane rozwiązania

    Zadbajmy o to, by nasza praca nie polegała jedynie na upartym brnięciu w wymyślone naprędce rozwiązania. Skupiona praca nie pomoże nam, jeśli nie wiemy dokładnie co ma zostać stworzone lub jak ma działać. Następną przeszkodą może być próba zaimplementowania wszystkich rzeczy od razu, zwracając nadmierną uwagę na szczegóły. Być może Twój pomysł wymaga zmian architektonicznych co możesz przegapić, gdy dążysz tylko do zamknięcia zadania.

    Dobrą praktyką jest częste konsultowanie swoich rozwiązań z innymi członkami teamu, otwartość na ich sugestie i pomysły. Pomocne może być oddawanie kodu do review etapami.

    Jeśli napotykamy na trudniejsze zadanie i zaczynamy odczuwać frustrację podczas bezowocnej implementacji dobrym rozwiązaniem może być programowanie w parach. Podczas takiej pracy od razu wyłapujemy błędy proponowane przez kolegę z zespołu i uczymy się nowych rzeczy. Taka praca uniemożliwia wręcz wchodzenie w stan flow.

    Gdy w naszym kodzie jest dużo błędów prostych do wykrycia podczas review, warto przed oddaniem kodu do sprawdzenia oderwać się od niego na chwilę i następnie wrócić do niego z bardziej krytycznym podejściem. Dzięki temu zaoszczędzimy czas osoby przeglądającej kod.

    Niektóre metody pracy, jak na przykład technika Pomodoro, wymuszają na nas pracę w pełnym skupieniu przerywaną krótkim, obowiązkowym odpoczynkiem, podczas którego warto wstać od komputera
i rozprostować ciało.

    Podsumowując – gdy czujesz, że efekt Twoich prac zmierza w złą stronę, oderwij się na chwilę – po powrocie do kodu dostrzeżesz znacznie więcej.

Inspiracje

Cal Newport, Deep Work

Barbara Oakley, Głowa do liczb

Steve McConnell, Kod doskonały

Mihály Csíkszentmihályi, Przepływ