Idea principale

L'esperienza tecnica si costruisce in un ciclo breve: si prova, si sbaglia, si cerca, si capisce, si corregge, e di quella correzione resta qualcosa. Mezz'ora su un bug circoscritto, una giornata su un endpoint che non cede, un problema ripreso l'indomani — è questo giro largo che insegna a riconoscere i segnali deboli di un codice e a fiutare che una soluzione troppo facile nasconde un costo.

Non è il dolore a insegnare, è l'analizzabilità. Finché il difetto sta dentro un perimetro che si può aprire, leggere e ricondurre a una decisione, insegna qualcosa. Quando compare su un sistema che è cresciuto, i cui strati si sono accumulati, le cui decisioni sono implicite e i cui test magari confermano una lettura sbagliata del bisogno, non è più riconducibile a niente: non si sa più perché tutto crolla.

A quel punto si mette una pezza. Non si capisce meglio: si aggiunge un altro strato su un'architettura che non si è mai davvero abitata.

Perché è importante

Ridefinisce che cosa va protetto se si vuole che un team impari. Non la presenza di errori — ce ne saranno — ma la loro dimensione e il tempo che impiegano a manifestarsi, due grandezze su cui si può agire con la scomposizione del lavoro, i test e la frequenza dei rilasci in produzione.

Spiega anche perché un team può accumulare anni di incidenti senza crescere in competenza: i suoi errori arrivano sempre troppo tardi e troppo grandi per insegnare alcunché.

Sfumature e limiti

Certi errori tardivi insegnano benissimo, a patto che un dispositivo li renda analizzabili a posteriori: un post mortem serio, una cronologia ricostruita, una traccia operativa. L'analizzabilità si può quindi ristabilire, a un costo che non è più quello del momento.

E un ciclo troppo breve ha il suo difetto: insegna la mossa locale senza mai esporre agli effetti di sistema, che compaiono solo su larga scala.

Domande aperte

• Quale intervallo massimo tra una decisione tecnica e la sua prima conseguenza osservabile lascia ancora al ciclo il suo valore formativo?