Questo mese, su Ironistic.com, è comparso un articolo che mi ha fatto rodere dall’invidia perché, più per sfogo che per altro, da tempo ne avrei voluto scrivere io: The Cost of Distractions on Developers! di Tom Lydon. Posto che la maggior parte del lavoro è già fatta oltre alla traduzione mi limiterò, quindi, ad aggiungere i miei commenti, tecnici e personali…
Chiunque lavori in un ambiente od in ufficio multitasking ha a che fare con distrazioni quotidiane, e gli sviluppatori non fanno eccezione. È noto che le distrazioni siano tra i fattori che contribuiscono maggiormente ad una riduzione delle prestazioni degli sviluppatori
Il tipo di lavoro degli Sviluppatori/Programmatori differisce dalla maggioranza di quelli esperibili in un ufficio: è il solo tipo di lavoro che, nonostante la sua prevalente non criticità – non si tratta né di medicina d’urgenza1 né di sostenere un attacco aereo alla guida di un velivolo! –, richiede un’attenzione davvero prolungata – dozzine di minuti, non minuti –, peraltro su niente di tangibile, bensì sulla correttezza del proprio “progetto mentale” di ciò che deve essere realizzato; la attività di mera scrittura del codice rappresenta solamente la successiva traduzione di quel progetto in qualcosa di eseguibile dal computer, tant’è che solo a quel punto abbondano i presidii che possono alleviare il labor del programmatore (interfacce grafiche, tool vari, librerie, etc..)..
Per comprendere al meglio come funziona il lavoro del programmatore paragonato a quelli dei suoi vicini, a iniziare dai venditori ed i manager, l’autore suggerisce – ed io non posso che condividere, sghignazzando per quanto è vero – di leggere: Programmers, Teach Non-Geeks The True Cost of Interruptions.
Blogged: Programmers, Teach Non-Geeks The True Cost of Interruptions http://t.co/y4ueLIIOLv #dev
— Erik Dietrich (@daedtech) January 17, 2014
— Erik Dietrich (@daedtech) 17 Gennaio 2014
Persino il neurochirurgo ha dei tessuti da guardare, mentre il pilota dopo pochissimi minuti o è uscito vittorioso dal duello – e può inserire il pilota automatico – oppure si è eiettato – e dunque non guida più nulla – od infine è morto, semplicemente. Il vero programmatore, invece, prima, mentre e dopo che ha cominciato a digitare, deve mantenere l’attenzione su qualcosa di intangibile e dunque ancor più complesso e sfuggente…
Quando a me capita di venir interrotto da quelle che io chiamo “richieste di interazione“2 mentre sto progettando la sensazione, di primo acchito, è analoga all’avere udito uno specchio/vetro infrangersi, per poi accorgermi che il delicatissimo castello di carte che avevo costruito nelle ultime decine di minuti è stato demolito da un flebile soffio di fiato. Sembrerà letterario ma è proprio così, e colleghi di tutto il mondo danno di eventi come questo descrizioni abbastanza sovrapponibili alla mia…
Questo perché, neuropsicologicamente parlando, accade la medesima cosa: il ricco ma ugualmente precario dialogo fra strutture cerebrali della memoria a lungo termine e di quella a breve termine, raggiunto attraverso minuti e minuti di crescente concentrazione, viene colto, appunto, in tutta la sua precarietà. Il trauma, benché temporaneo, ancorché non più grave dell’aver sentito una puntina del giradischi scivolare sul vinile – tuttavia della musica che ci stava coinvolgendo o semplicemente rilassando… –, è assicurato.
Le distrazioni non solo ritardano il completamento delle attività ed aumentano il numero di bug… [di errori, ndr] …ma possono pure portare ad un aumento dello stress e dei livelli di frustrazione, che possono a loro volta portare ad ulteriori ritardi… ed in alcuni casi al burnout
Tutt’altro che casualmente la ricerca scientifica sulle interruzioni (cd. “Interruption Science“) individua sovente fra i programmatori (et simila) il proprio campione di studio: per questi ultimi le conseguenze delle interruzioni e delle distrazioni appaiono da sempre come amplificate. E non c’è modo migliore di studiare un fenomeno del partire dai casi in cui questo si dimostra più potente per poi applicare rilievi e conoscenze acquisite relative ai suoi meccanismi alle situazioni meno borderline. Va da sé, quindi, che tutto questo discorso vale per i programmatori sempre – tant’è che una patologica frequenza delle interruzioni è co-fattore tipico dello Stress Lavoro-Correlato (cfr. Basoglu et al., 2009; Fonner & Roloff, 2012) – mentre per gli altri tipi di lavori varrà verosimilmente tanto quanto sono esposti ad analoghe richieste cognitive.
Il tempo medio perso è di 23 minuti per le interruzione più gravi, secondo il Wall Street Journal. Oltretutto i programmatori possono richiedere 10-15 minuti per ricominciare l’elaborazione del codice dopo la ripresa del lavoro a valle di un’interruzione. Per Game Developer Magazine un programmatore nella media dispone verosimilmente soltanto di una singola ininterrotta sessione di due ore in un giorno
L’ultima affermazione è quella operativamente più rilevante, in quanto se ne deduce che il vero tempo di qualità in una giornata di lavoro tipo di un programmatore sia limitato a meno della sua metà — quantomeno in un contesto co-localizzato; la parte restante, in quanto costellata di interruzioni, andrebbe considerata come marginalità rispetto alla prestazione principale richiesta. Sono, tuttavia, le prime due ad offrire una descrizione di quali siano gli effetti delle interruzioni sullo svolgimento di task cognitivamente complessi:
- Ogni interruzione provoca una perdita di tempo di durata superiore all’interruzione stessa, il che significa pure che se il numero di interruzioni nell’arco della giornata lavorativa raggiunge una massa critica sufficiente la stessa giornata è da considerarsi persa – almeno relativamente alla prestazione originariamente prevista, in questo caso la programmazione;
- Ciò in quanto ritornare semplicemente alla prestazione non è sufficiente: è necessario pure che vi sia il ritorno allo stato attentivo precedente rispetto all’evento all’origine dell’interruzione, il che richiede tanto tempo quanta è la complessità del compito da svolgere.
Gli sviluppatori perdono più tempo a tornare al compito rispetto alla norma dei lavoratori, e tanto più a lungo sono stati lontani dal compito, maggiore è il tempo necessario per ritornarvi
Sempre per una questione di memoria se l’evento interruttivo eccede una certa durata – non si tratta più di una banale notifica (arrivo di un SMS o di un’email, lo squillo del telefono, etc.) ma di un’interruzione più lunga (e.g. un colloquio, una riunione, etc.) –, anche il (normale ed automatico) tentativo di trattenere fra i pensieri – in una sorta di complesso reharsal… – il progetto mentale fallisce e si rende necessario ricominciare tutto daccapo – tant’è che il post successivamente espone vari espedienti per organizzare dettagliatamente il lavoro così da limitare al minimo i danni di tali eventualità..
La programmazione è più una forma mentis che un’abilità di scrittura. La mente va concentrata del tutto sul compito corrente, va pianificato e prefigurato il prodotto finale ed i risultati desiderati di ciascun metodo e funzione all’unisono con la scrittura del codice ed il testing
Personalmente non condivido siffatta profonda distinzione tra programmazione ed abilità di scrittura. In entrambi i casi sussiste, infatti, una complessa fase prodromica, propedeutica di tipo ideativo — sono anni che combatto, da un lato coi miei clienti e dall’altro coi miei discenti e collaboratori, per far passare il duplice concetto, trito e ritrito fra chi si occupa di pianificazione di progetti informatici, per cui, tanto più tardi nello svolgimento ci si accorge di una carenza analitico-progettuale, tanto più ampie ne saranno le conseguenze, temporali e pertanto economiche, e che, quindi, vale assolutamente la pena prolungare l’analisi, anche se ad un osservatore ingenuo potrebbe sembrare una assenza di produzione — ed il fatto, innegabile, che questa fase sia più impegnativa nella programmazione di certo non rende povera di complessità la progettazione di sequenze di proposizioni, magari assai articolate in subordinate, la costruzione di paragrafi logicamente sostenibili ed in genere la scrittura finalizzata ad un risultato, ad esempio divulgativo.
È, altresì, esperienza famigliare per qualsiasi programmatore, così come per qualsiasi scrittore, che le interruzioni verbali (con un contenuto verbale) provochino un disturbo superiore rispetto a quelle esclusivamente informative (i.e. il singolo “ciao” del collega od il breve trillo del cellulare all’arrivo di un messaggio), spesso derubricate a notifica neppure prima inter pares. Questo accade verosimilmente perché in entrambi i tipi di attività le prime, andando ad interessare lo stesso tipo di memoria, verbale (Siegmund et al., 2014), già occupata, causano un conflitto modale, e più precisamente una interferenza verbale (Semenza, 1983): il “progetto linguistico” – trattasi pur sempre, infatti, di lingue o linguaggi, con una propria struttura e terminologia… – in uscita deve lasciare post al “prodotto linguistico” in entrata (da analizzare).
Tutti ironizzano sul fatto che gli sviluppatori siano dei nottambuli, ma c’è qualche verità in questo. Nel corso degli anni di sviluppo, ho imparato a gestire le interruzioni per necessità. Nei miei primi anni ho trascorso molte tarde notti scrivendo codice, semplicemente perché era il miglior periodo del giorno senza interruzioni che potevo trovare.
Tom Lydon about how distractions manipulate a programmer’s productivity. Read yourself! http://t.co/j03r3mISeI
— Ironistic (@IronisticWeb) July 2, 2014
Non c’è soltanto qualche verità
in tale affermazione: è tutta vera e per la maggioranza dei programmatori, specie quelli impegnati nel realizzare qualcosa di (soggettivamente) complesso. In una siffatta situazione spesso la notte è il solo intervallo di tempo nel quale siano disponibili le ore di tranquillità necessarie a capitalizzare la concentrazione indispensabile ad affrontare l’attività. Soprattutto se questa è inerente più la risoluzione di un problema attraverso una ristrutturazione cognitiva (il cd. “Effetto Eureka“) che la mera esecuzione, algoritmica, di una sequenza di compiti.
Ovviamente c’è un’alternativa al lavoro notturno, per i programmatori così come per tanti altri lavori intellettuali. La remotizzazione – in questo caso il vero e proprio isolamento – del lavoratore, ad esempio, può minimizzare il tasso di interruzioni non programmate, connaturate alla situazione co-localizzata, senza il costo economico o psicosociale (e.g. le invidie dei colleghi) del conferimento di un locale isolato, un ufficio individuale, nella sede aziendale. Questo almeno fino a quando, per esempio, non ci sarà un qualche automatismo – Microsoft ha iniziato anni fa a pensare a qualcosa del genere… – in grado, magari, di contingentare tecnologicamente le interruzioni in base a delle rilevazioni biometriche dello “stato mentale” attuale del lavoratore.
La prima – e più semplice… – delle soluzioni adottabili è quella di una remotizzazione part-time (verticale), in cui al lavoratore-programmatore è concesso di lavorare più giorni a settimana fuori dall’ufficio – a casa od in qualunque altro luogo nel quale poter evitare superflue “richieste d’interazione” dirette –, concentrando negli 1-2 restanti giorni tutte le attività mondane e la programmazione di routine da svolgere, invece. in sede. Starà nella determinazione del programmatore, infine, filtrare opportunamente eventuali distrazioni provenienti da remoto (telefonate, messaggi istantanei, contatti in telepresenza, etc.), ovverosia dall’ufficio, così come spiegare ai propri congiunti, sperabilmente più ammansibili dei colleghi, il dramma delle interruzioni…
