Konkretny problem dla programistów polega na tym, jak drogie w praktyce jest przerwanie w porównaniu z niemal każdym innym rodzajem pracy. Trzymanie w głowie złożonej funkcji, całego stosu wywołań albo prawdopodobnej przyczyny podchwytliwego błędu to kruchy rodzaj koncentracji, a trzydziestosekundowe sprawdzenie telefonu nie kosztuje tylko trzydziestu sekund — może kosztować dziesięć czy piętnaście minut potrzebnych na odbudowanie tego modelu myślowego od zera, dlatego programiści często opisują utratę całej produktywnej godziny na coś, co z zewnątrz wyglądało jak para krótkich przerw. Badania nad przełączaniem kontekstu w pracy umysłowej konsekwentnie pokazują, że powrót do złożonego zadania po przerwaniu zajmuje znacząco dłużej niż samo przerwanie, a w programowaniu konkretnie — gdzie „kontekst" to cały model myślowy systemu, nie tylko wątek myśli — ta luka bywa gorsza niż w większości innych rodzajów pracy. To część powodu, dla którego tak wiele tekstów o kulturze inżynierii oprogramowania traktuje harmonogramy typu „maker" i długie, nieprzerwane bloki jako faktyczny wymóg produktywności, a nie miły dodatek — koszt fragmentacji w tego rodzaju pracy jest mierzalnie gorszy niż w rolach, gdzie zadania są z natury krótsze i łatwiej przerywalne.
Co pewnie już próbowałeś
Tryb Nie przeszkadzać podczas kompilacji i code review, słuchawki z redukcją szumów jako społeczny sygnał, żeby nie przeszkadzać, blokada stron do skakania po zakładkach Stack Overflow, która jakoś zawsze ma wyjątek na „tylko to jedno wyszukanie", i pewnie darmowa blokada aplikacji odinstalowana przy pierwszej okazji, gdy stanęła na drodze uzasadnionej potrzebie sprawdzenia dokumentacji albo wiadomości na firmowym Slacku w trakcie debugowania. Timery w stylu Pomodoro pomagają części programistów utrzymać tempo przez długą sesję, ale timer, który kończy się w środku debugowania, nie wie ani go nie obchodzi, że byłeś trzydzieści sekund od znalezienia błędu, a zrobienie przerwy mimo to, bo tak mówi timer, potrafi być równie destrukcyjne jak rozproszenie, któremu miał zapobiec. Część zespołów próbuje wspólnych „godzin skupienia" jako normy, co pomaga, gdy wszyscy naprawdę je szanują, ale norma bez żadnego mechanizmu egzekwowania zwykle się rozmywa, gdy tylko termin sprawia, że wyjątek wydaje się uzasadniony dla kogoś, gdziekolwiek w zespole.
Dlaczego ogólne porady o blokowaniu zawodzą akurat tutaj
„Blokuj media społecznościowe w godzinach pracy" pomija fakt, że rzeczywista lista rozpraszaczy programisty jest szersza i bliższa pracy niż u większości ludzi — fora, agregatory newsów jak Hacker News, powiadomienia z GitHuba, tuzin zakładek przeglądarki, które wszystkie wydają się mgliście uzasadnione jako „technicznie związane z pracą". Lista blokowanych aplikacji zbudowana dla przeciętnego pracownika biurowego nie przekłada się czysto na tę konkretną mieszankę, a zbudowana zbyt wąsko zostawia szeroko otwarte prawdziwe wycieki. Ma też tendencję do traktowania wszystkich przerwań jako równie złych, podczas gdy w praktyce szkoda skaluje się z tym, jak głęboki był stan umysłu w momencie przerwania — szybkie sprawdzenie podczas rutynowego code review kosztuje dużo mniej niż to samo sprawdzenie w środku tropienia race condition, a blokada uniwersalna dla wszystkich nie rozróżnia tych dwóch sytuacji. Narzędzie zbudowane wokół jednej, stałej kategorii „media społecznościowe" pomija też fakt, że dla wielu programistów pokusą wcale nie są media społecznościowe — tylko pozornie związana z pracą strona, którą łatwo w danej chwili usprawiedliwić i która równie skutecznie pożera godzinę.
Uczciwe dopasowanie
Blokada z bramką w postaci quizu dobrze się tu sprawdza, bo tarcie odpowiadania na prawdziwe pytanie to podobny rodzaj zaangażowania poznawczego co sama praca — nie oferuje łatwiejszej, bardziej biernej furtki ucieczki, tak jak robi to odliczający timer albo pięciosekundowe stuknięcie. A ponieważ listę blokowanych aplikacji można w pełni dostosować, można ją zbudować wokół konkretnych aplikacji i stron, które faktycznie pożerają czas danego programisty, zamiast generycznej kategorii „media społecznościowe", która pomija połowę prawdziwych wycieków. Ponieważ pytania rotują z ogólnej bazy wiedzy, a nie testują niczego związanego z samym kodem, odpowiadanie na nie nie zamienia się przypadkowo we własną formę prokrastynacji — częsty tryb zawodności w zgrywalizowanych narzędziach produktywności, które nagradzają zaangażowanie w samą blokadę zamiast zaangażowania w rzeczywistą pracę. Ta konfigurowalność ma tu większe znaczenie niż w większości innych zawodów, bo rzeczywista lista rozpraszaczy programisty rzadko pokrywa się z czyjąkolwiek inną, a narzędzie, którego nie da się dopasować do prawdziwej listy, kończy albo za luźne, żeby miało znaczenie, albo za surowe, żeby przetrwać.
Gdzie to nie jest dobre dopasowanie
Jeśli twoje faktyczne przerwania są uzasadnione — wiadomości na Slacku od współpracowników, wezwania z dyżuru on-call — żadna blokada w ogóle nie powinna ich dotykać, a zbudowanie listy zbyt szerokiej po prostu zostanie wyłączone przy pierwszej okazji, gdy zablokuje coś naprawdę pilnego. A przy zaplanowanym sprincie głębokiego kodowania z twardym terminem, surowsza, nienegocjowalna blokada, jak Cold Turkey, może sprawdzić się lepiej niż powtarzane tarcie, które z definicji zawsze da się w końcu obejść. Uczciwie trzeba też powiedzieć, że to nie rozwiązuje kultury przerywania na poziomie zespołu — jeśli prawdziwym problemem jest oczekiwanie natychmiastowej odpowiedzi na każdym kanale, to norma, którą zespół musi zająć się bezpośrednio, i żadne indywidualne narzędzie blokujące, jakkolwiek dobrze skonfigurowane, nie zmienia tego, czego faktycznie oczekuje menedżer czy zespół. Zadanie tego narzędzia jest wąskie i konkretne — podnieść koszt odruchowego, niskowartościowego sprawdzenia — i warto mieć jasność, że nigdy nie miało samo z siebie naprawić kultury czasu reakcji zespołu.