Idea principale

Una competenza che l'uso corrente non sollecita più non si mantiene da sola. Uno sviluppatore che chiede a un assistente di leggere, spiegare e correggere al posto suo conserva l'abilità di guidare lo strumento e perde a poco a poco quella di leggere un codice sconosciuto, di portare avanti una diagnosi o di semplificare un'architettura.

Il rimedio non è rinunciare allo strumento, ma creare situazioni in cui non è disponibile: dojo senza assistente, esercizi con l'assistente limitato, revisioni in cui il codice bisogna spiegarlo da sé, momenti presi apposta per leggere, capire e semplificare. Altrove la stessa logica è accettata senza discussioni — la calcolatrice è utile, ma non svolgere mai un'operazione da soli crea dipendenza; nello sport si aggiungono pesi e resistenza perché è la resistenza a sviluppare i muscoli.

Non è nostalgia dello sviluppatore che deve soffrire per meritarsi il mestiere, e l'obiettivo non è rallentare ovunque. È rallentare nel punto giusto: produrre molto velocemente per una parte del tempo, e blindare del tempo lungo — una giornata di miglioramento continuo, revisioni di architettura, ADR, refactoring lenti, post mortem sulle generazioni venute male — per capire quello che è stato prodotto.

Perché è importante

Copre una mancanza che nessuna regola di produzione affronta: le contromisure che proteggono la qualità del sistema non proteggono la capacità di chi lo tiene in piedi. Un team può applicare una disciplina di merge impeccabile e lasciar spegnere la competenza che gli permetterebbe di giudicare ciò che integra.

Offre anche una lettura di un problema che precede gli strumenti: molti sviluppatori restavano già con la testa china sul lavoro, a produrre senza prendere la distanza che fa crescere in competenza. L'accelerazione aggrava questo vizio se riempie con altra produzione tutto lo spazio che ha liberato, e lo corregge se serve a distinguere il tempo del fare dal tempo del capire.

Sfumature e limiti

La difficoltà aggiunta deve somigliare a quella del mestiere reale. Un esercizio artificiale allena la scioltezza sull'esercizio, non la competenza a cui si mira — e un vincolo scelto male costa tempo senza formare nulla.

E alcune competenze rese inutili meritano di sparire: nessuno si allena a scrivere assembly per restare lucido sul proprio codice. Distinguere ciò che va mantenuto da ciò che si può abbandonare è una scelta aperta, che questa idea non risolve.

Domande aperte

• Da quale segnale un team si accorge che una competenza si è spenta, quando la sua produzione quotidiana non la sollecitava più da tempo e sembrava normale?