Il problema specifico per i programmatori è quanto sia costosa un'interruzione rispetto a quasi ogni altro tipo di lavoro. Tenere in testa una funzione complessa, un'intera call stack, o la probabile causa di un bug ostinato è un tipo di concentrazione fragile, e un'occhiata al telefono di trenta secondi non costa solo trenta secondi — può costare i dieci o quindici minuti necessari a ricostruire quel modello mentale dal nulla, il che è il motivo per cui i programmatori descrivono spesso di aver perso un'intera ora produttiva per quello che, visto dall'esterno, sembrava un paio di brevi pause. La ricerca sul cambio di contesto nel lavoro intellettuale trova costantemente che riprendere un compito complesso dopo un'interruzione richiede significativamente più tempo dell'interruzione stessa, e per la programmazione in particolare — dove il «contesto» è un intero modello mentale di un sistema, non solo un filo di pensiero — quel divario tende a essere peggiore che nella maggior parte degli altri tipi di lavoro. Questo è in parte il motivo per cui tanti scritti sulla cultura dell'ingegneria del software trattano i «maker schedule» e i lunghi blocchi ininterrotti come un vero requisito di produttività piuttosto che un semplice bonus — il costo della frammentazione in questo tipo di lavoro è misurabilmente peggiore che in ruoli dove i compiti sono per natura più brevi e più interrompibili.
Cosa hai probabilmente già provato
Non disturbare durante le compilazioni e le revisioni del codice, cuffie con cancellazione del rumore come segnale sociale per non essere disturbato, un blocco per i siti web per evitare i salti su Stack Overflow che in qualche modo include sempre un'eccezione per «solo questa ricerca», e probabilmente un blocca-app gratuito disinstallato la prima volta che ha interferito con la legittima necessità di controllare la documentazione o un messaggio Slack di lavoro nel mezzo di un debug. I timer in stile Pomodoro aiutano alcuni sviluppatori a scandire una lunga sessione, ma un timer che finisce nel mezzo di un debug non sa e non gli interessa che eri a trenta secondi dal trovare il bug, e prendersi comunque la pausa perché lo dice il timer può essere altrettanto dirompente della distrazione che era pensato per prevenire. Alcuni team provano «ore di concentrazione» condivise come norma, il che aiuta quando tutti le rispettano davvero, ma una norma senza alcun meccanismo di applicazione tende a erodersi la prima volta che una scadenza fa sembrare giustificata un'eccezione, per qualcuno, da qualche parte nel team.
Perché i consigli generici sul blocco falliscono proprio qui
«Blocca i social durante le ore di lavoro» perde di vista che il menù reale di distrazioni di un programmatore è più ampio e più affine al lavoro di quello della maggior parte delle persone — forum, aggregatori di notizie come Hacker News, notifiche GitHub, una dozzina di schede del browser tutte vagamente giustificabili come «tecnicamente legate al lavoro». Una lista di blocco costruita per un impiegato generico non si sovrappone in modo pulito a quel mix specifico, e una costruita troppo strettamente lascia le vere falle spalancate. Tende anche a trattare tutte le interruzioni come ugualmente dannose, quando in pratica il danno scala con quanto profondo era lo stato mentale nel momento dell'interruzione — un controllo veloce durante una revisione del codice di routine costa molto meno dello stesso controllo nel mezzo del rincorrere una race condition, e un blocco unico per tutti non distingue tra i due. Uno strumento costruito attorno a un'unica categoria fissa «social media» perde anche il fatto che per molti sviluppatori la tentazione non è affatto il social media — è un sito ostensibilmente legato al lavoro, facile da giustificare sul momento e altrettanto efficace nel mangiarsi un'ora.
L'adattamento onesto
Un blocco filtrato da un quiz si adatta bene qui perché l'attrito di rispondere a una domanda vera è un tipo di impegno cognitivo simile al lavoro stesso — non offre una via di fuga più facile e passiva come farebbe un timer a conto alla rovescia o un tocco di cinque secondi. E poiché la lista di blocco è completamente personalizzabile, può essere costruita attorno alle app e ai siti specifici che davvero mangiano il tempo di un dato sviluppatore, invece di una generica categoria «social media» che si perde metà delle vere falle. Poiché le domande ruotano su un ampio patrimonio di cultura generale invece di testare qualcosa sul codice stesso, rispondere non diventa accidentalmente una forma propria di procrastinazione — una modalità di fallimento comune negli strumenti di produttività gamificati che premiano l'impegno col blocco invece dell'impegno col lavoro vero. Quella personalizzabilità conta qui più che nella maggior parte delle altre professioni, perché la lista reale delle distrazioni di uno sviluppatore raramente coincide con quella di chiunque altro, e uno strumento che non può essere modellato sulla lista vera finisce per essere troppo permissivo per contare o troppo rigido per sopravvivere.
Dove non è l'adattamento giusto
Se le tue interruzioni reali sono legittime — messaggi Slack dei colleghi, chiamate da una rotazione di reperibilità — nessun blocco dovrebbe toccarle affatto, e costruire una lista di blocco troppo ampia porterà solo a disattivarla la prima volta che blocca qualcosa di davvero urgente. E per uno sprint di programmazione pianificato, ad alta concentrazione, con una scadenza rigida, un blocco più duro e senza possibilità di negoziare come Cold Turkey può servire meglio dell'attrito ripetuto, che per costruzione si può sempre superare alla fine. È anche onesto dire che questo non risolve la cultura dell'interruzione a livello di team — se il vero problema è un'aspettativa di risposta immediata su ogni canale, è una norma che il team deve affrontare direttamente, e nessuno strumento di blocco individuale, per quanto ben configurato, cambia ciò che un responsabile o un team si aspetta davvero. Il compito dello strumento è mirato e specifico — alzare il costo del controllo riflessivo e a basso valore — e vale la pena essere lucidi sul fatto che non è mai stato pensato per risolvere da solo la cultura dei tempi di risposta di un team.