Senior non è chi sa di più: è chi condivide

L’inizio in XPeppers

In XPeppers ho imparato cosa significa “sviluppatore senior”. Non chi accumula più conoscenza: lì la seniority si giocava su quattro dimensioni, e lo sviluppo software vero e proprio era quasi marginale, paritario rispetto alle altre tre.

• Sviluppo software: la tecnica era il prerequisito, non il traguardo. Qualità e cura del codice erano il minimo sindacale per sedersi al tavolo, non quello per cui venivi valutato.
• Abilitatore e mentore: un senior veniva misurato da quanto rendeva migliori gli altri. I nuovi arrivati crescevano lungo la Starway to Orione, il percorso di apprendimento interno a base di kata e coding dojo, e accompagnarli era responsabilità dei senior.
• Consulente evoluto ed empatico: niente torri d’avorio tecnologiche. Dai clienti si andava per capire il business prima di toccare la tastiera: ascolto attivo, ambito negoziato in modo iterativo e incrementale, e la disciplina di scegliere la soluzione più semplice per il problema attuale invece della più elegante in assoluto.
• Guida culturale: abbattere le barriere tra sviluppo ed esercizio, con la responsabilità condivisa del software in produzione. You build it, you run it.

Dentro il team, i senior si riconoscevano da come lavoravano, non da quanto sapevano. Tenevano la barra dritta: non evitavano le derive, perché quelle capitano ovunque, ma le riconoscevano e riportavano gli altri sulla strada corretta. Insegnavano semplicemente lavorando fianco a fianco: raccontavano i concetti che usavano quotidianamente e li applicavano insieme a te, continuamente. E cercavano sempre di trasmettere il perché delle cose, lasciando libertà e creatività sul come.

Un episodio me lo ricordo bene. Lavoravo in pair con Ivan, senior come me, su un’architettura CQRS ed Event Sourcing, e ci lamentavamo dei test: poco chiari, non raccontavano il comportamento dell’applicazione, e la fase di arrange per preparare lo stato delle entità era lunghissima e altrettanto oscura. Abbiamo iniziato a condividere le nostre conoscenze e a codificarle il prima possibile, senza avere chiara la forma finale del codice ma con il perché ben chiaro: rendere i test chiari, evidenti e semplici da scrivere, basandoli sui comportamenti reali dell’applicazione. Ivan ha portato l’idea di creare un DSL in Kotlin, io quella degli specification test: nel given la storia degli eventi passati che definisce lo stato attuale, nel when il comando sotto test, nel then la verifica del risultato tramite l’evento emesso. Io non avevo mai scritto un DSL e Ivan non conosceva quella tecnica di testing: eravamo mentori ed esperti su una parte e junior sull’altra, e quei principi li abbiamo applicati anche tra senior.

La pair rotation era quotidiana, quindi il giorno dopo ho cambiato coppia e sono andato avanti su quella strada con un’altra persona. Quel modo di scrivere i test è piaciuto a tutto il team, è stato adottato da tutti e lo abbiamo portato nei progetti successivi.

Dall’altra parte della cattedra

Da studente avevo collezionato abbastanza esperienze da sapere che docente non volevo essere. Quello che legge le slide senza aggiungere valore a quello che c’è scritto. I concetti da imparare a memoria, senza capire perché sono nati e quale utilità possano avere. La teoria che occupa quasi tutto lo spazio e la pratica ridotta a un ritaglio. Gli esercizi “accademici”, slegati dal mondo reale, invece di semplificazioni del mondo reale.

All’esame di Informatica I, all’università, la prima parte chiedeva nozioni teoriche come la definizione formale di un ciclo. La seconda di scrivere un programma in C con funzioni ricorsive. Su carta. Con la penna.

Per fortuna c’erano anche le eccezioni. Il professor Maurizio Decina, ad esempio, non divideva le lezioni in teoria ed esercitazione, pur insegnando Crittografia e Sicurezza, un corso tutt’altro che leggero sulla teoria. Spesso spiegava facendo esercizi e rendeva le lezioni interessanti con aneddoti e, a volte, veri e propri siparietti, per farci capire la necessità di quello che stavamo studiando. Tra i workshop seguiti da professionista, due mi sono rimasti addosso. Quello di Event Storming con Alberto Brandolini era estremamente dinamico: si stava in piedi, ci si muoveva per la stanza attaccando post-it e discutendo insieme. Brandolini faceva più da facilitatore che da istruttore. In quello di Impact Mapping, Gojko Adzic lavorava per connettere le persone a quello che raccontava, con esempi e problemi in cui ogni partecipante poteva immedesimarsi.

Tenere corsi di formazione e workshop è diventato presto una parte normale del mio lavoro, iniziata prima ancora del salto da libero professionista. Ho tenuto corsi come “Clean Code that Works”, “DevOps Mindset & Lean Product Development” e “From TDD to Continuous Delivery”. La docenza nei corsi post-diploma ITS e IFTS, negli stessi anni di XPeppers, è stata una sfida in più: creare un corso intero in cui nessuna lezione fosse noiosa, con una buona alternanza tra teoria e pratica. O meglio: raccontare la teoria facendo pratica. Nelle mie lezioni ho sempre dato agli studenti più tempo per mettere in pratica quello che spiegavo di quanto ne prendessi io per spiegarlo. E li facevo lavorare quasi sempre in coppia: dalle mie esperienze di studio e di lavoro mi ero convinto che esercitarsi in due è più efficace, più leggero e più divertente che farlo da soli. In cattedra ci sono salito solo in senso figurato. Quella vera, col suo rialzo, mi è sempre stata antipatica: elegge il docente a qualcosa di superiore.

Da entrambi i lati ho visto cosa danno i corsi e dove si fermano. Danno un vocabolario comune, modelli, ispirazione, la spinta iniziale. Sono un buon inizio. Ma restano generici rispetto alla tua realtà: chi ti spiega le cose se ne va a fine corso senza aver messo mano al tuo codice, senza aver visto come il tuo team prende decisioni, senza conoscere la tua organizzazione.

I punti di arrivo

Da quelle esperienze parallele, XPeppers e la cattedra, ho ricavato due punti di arrivo che porto ancora oggi nel mio lavoro: uno per l’aula, uno per i team. Non sono indipendenti, si rafforzano a vicenda. In aula porto i problemi veri incontrati nei team, al posto degli esercizi accademici. Nei team porto il modo di imparare dell’aula.

Il primo è un modo di fare formazione che ho trovato codificato in Training from the Back of the Room di Sharon Bowman: il docente si sposta dal centro dell’aula al suo bordo. La pratica prima della teoria, il lavoro in coppia, il docente che facilita invece di spiegare. Chi impara fa, discute, si spiega le cose a vicenda; chi insegna prepara il terreno e resta indietro. Oggi lo applico nei corsi, nei workshop e negli sprint, per le parti introduttive e di spiegazione.

Il secondo è il modello di senior che ho respirato in XPeppers. Quello che ho raccontato con l’episodio di Ivan non è un ricordo romantico: è ancora il mio modo di lavorare dentro i team, qualunque sia lo stack o l’azienda. L’applicazione più completa è stata viteSicure, dove con Luca Giovenzana ho costruito un team da zero facendo mentoring dentro il lavoro quotidiano. Il trasferimento riguardava la tecnica e la cultura prima ancora del dominio: qualità, cura del codice, buone pratiche. Quando il team è diventato autonomo, la mia presenza si è ridotta per scelta.

La forma più alta di seniority non è tenere un corso: è lavorare accanto a qualcuno. Pair programming, studio e guida mentre si affronta un problema vero: è lì che la crescita diventa duratura. Team e persone che imparano a ragionare da soli non hanno più bisogno di te. E questo, per me, è l’unico successo che conta.