Cose che ho smesso di fare negli ultimi quindici anni di lavoro

Mi sono accorto che le cose più difficili da imparare non sono quasi mai tecniche.

Sono le cose che devi disimparare.

E la parte strana è che, mentre le disimpari, ti sembra di perdere qualcosa. Status, controllo, identità. Poi, se va bene, ti rendi conto che stavi solo lasciando andare un’abitudine che ti teneva fermo.

Questi sono appunti sparsi su alcune cose che ho smesso di fare. Ci ho messo quindici anni, più o meno. E su alcune, se devo essere sincero, non ho ancora finito.

Ho smesso di scrivere codice per dimostrare che sono ancora tecnico #

C’è stato un periodo, subito dopo un passaggio importante della mia carriera, in cui il mio modo di legittimarmi davanti al team era sempre lo stesso: aprivo l’IDE e andavo a prendermi il bug più brutto della settimana.

Lo facevo spesso la sera, da solo. La mattina dopo il commit era lì, con il mio nome sopra. Dentro di me lo chiamavo leadership. In realtà era insicurezza.

Perché il messaggio implicito era devastante, anche se non lo dicevo mai ad alta voce. Il messaggio era: non mi fido di voi. E ce n’era un altro, ancora più tossico: i problemi si risolvono di notte, in solitaria, senza chiedere aiuto.

Senza volerlo, stavo insegnando che il gesto eroico vale più del processo. Che la bravura è una performance individuale. Che la fatica è una medaglia.

Poi ho fatto un altro giro di giostra. Ho sostituito il codice con le specifiche. Documenti così precisi che il team, o un agente ai, potessero implementarli con supervisione minima. Per un po’ mi è sembrata la soluzione “adulta”. Ma anche quella fase è passata.

Oggi il mio lavoro, quando lo faccio bene, è un altro. È decidere cosa costruiamo, per chi, e perché adesso. È architettura di portfolio, non di codice. È partnership, hiring, posizionamento. È capire dove deve puntare l’azienda tra diciotto mesi, e quali scelte di oggi rendono quella direzione più probabile.

Questa distanza dal codice, a volte, fa male. Non perché voglia tornare a programmare ogni giorno. È più sottile. È la sensazione che la legittimità di un tecnico che non tocca più il codice quotidianamente sia una cosa fragile, che va ricostruita su basi diverse.

Non più sulla qualità di quello che scrivi, ma sulla qualità delle decisioni che prendi e delle persone che scegli.

E poi c’è una frase che mi torna in mente spesso, e che mi aiuta a non ricadere nel vecchio riflesso: ogni riga che scrivo io è una riga che qualcun altro non scrive. Ogni ora che passo nell’IDE è un’ora in cui nessuno sta guardando dove stiamo andando.

Ho smesso di inseguire lo stack giusto #

Per anni ho avuto quel riflesso pavloviano da developer. Esce un framework nuovo, devi valutarlo. Esce un linguaggio nuovo, devi almeno provarci.

Sotto sotto, credo che il sottotesto fosse questo: esiste una scelta tecnologica “giusta” che ti mette dalla parte dei vincitori. Dei cool kids. Delle conferenze giuste. Degli articoli su Hacker News.

Poi ho fatto una cosa impopolare, almeno per come mi ero abituato a pensare: ho scelto un framework. Uno. E ci sono rimasto.

Non perché sia il migliore in assoluto. Ma perché mi permette di consegnare valore con poche persone su più progetti, senza impazzire. Perché ha una filosofia che regge i vincoli reali di un’azienda italiana. Convenzione su configurazione, batterie incluse, documentazione maniacale. Non i vincoli immaginari di una startup della Bay Area che vive di slide e runway.

La verità scomoda è che tante scelte tecnologiche “coraggiose”, nelle PMI, non sono coraggio. Sono vanità. Scegliere Rust per un gestionale che useranno quaranta persone non è ingegneria. È narcisismo con un compilatore.

A un certo punto ho smesso di cercare lo stack giusto e ho iniziato a cercare lo stack onesto. Quello che non mente sulla complessità che introduce. Quello che puoi mantenere quando i senior se ne vanno, quando il budget si stringe, quando il cliente cambia idea tre volte.

Ho smesso di proteggere il team dal business #

Questo è stato il passaggio più difficile.

Per anni ho fatto da scudo. Il cliente chiede una modifica folle? La filtro io. Il commerciale vende qualcosa che non esiste? Gestisco io. Arriva un documento incomprensibile? Lo traduco io e passo al team solo la parte tecnica, pulita, digeribile.

Pensavo di essere un buon leader. E invece, probabilmente, stavo creando degli invalidi.

Sviluppatori bravissimi, sì, ma scollegati. Non sapevano davvero perché stessero costruendo quello che stavano costruendo. Non sapevano leggere un requisito di business. Non avevano mai parlato con un cliente. E quando incontravano un’ambiguità, invece di alzare il telefono, aprivano un ticket e aspettavano che qualcuno risolvesse.

Il cambio, per noi, è stato costruire un percorso interno che abbiamo chiamato “da developer a product owner”. Non per trasformare tutti in PM. Più che altro per togliere il filtro.

Per dire una cosa semplice, anche se un po’ scomoda: il casino è anche vostro. Il cliente confuso è anche vostro. Il requisito ambiguo è anche vostro.

E, soprattutto, anche la soddisfazione di consegnare qualcosa che funziona davvero per qualcuno è vostra.

Pensavo sarebbe stato impopolare. Mi sbagliavo. Mi hanno stupito. Forse aspettavano solo che gli dessimo il permesso di uscire dalla bolla.

Ho smesso di dire “tanto è pubblico” parlando di compliance #

Per anni la mia posizione sulla compliance è stata quella tipica del settore IT italiano. Il minimo indispensabile, fatto all’ultimo momento possibile, trattato come un costo e mai come un investimento.

GDPR? Un banner sui cookie e una privacy policy copiata. Accessibilità? “Ci pensiamo dopo.” Sicurezza? “Non siamo un target.”

Poi ho iniziato a leggere davvero alcune normative europee. Non gli articoli su quelle normative, proprio i testi. E lì mi si sono chiarite due cose.

La prima: il legislatore europeo, per una volta, non sta scherzando. Le sanzioni sono reali, le timeline sono strette, e la catena di responsabilità arriva fino al fornitore del componente software. Cioè noi.

La seconda, più importante: in un mercato dove tutti aspettano l’ultimo momento, chi si muove prima ha un vantaggio competitivo enorme. Non perché è più bravo. Perché è l’unico che può dire al cliente “sì, siamo pronti” quando il cliente, in panico, inizierà a chiederlo.

A un certo punto ho smesso di trattare la compliance come un obbligo. Ho iniziato a trattarla come un prodotto.

E mi chiedo spesso perché ci abbiamo messo così tanto a capirlo. Forse perché è più comodo pensare che siano solo scartoffie, finché non diventa improvvisamente un problema con una scadenza.

Ho smesso di assumere per competenze tecniche #

Questa è recente e, se devo essere sincero, ancora un po’ dolorosa.

Ho passato settimane a cercare una figura importante. Candidati con CV eccellenti. Anni di esperienza. Stack solidi. Referenze buone. Ne ho bocciati diversi, non perché non fossero bravi, ma perché usavano l’AI come usavano Stack Overflow dieci anni fa. Come un oracolo.

Quello che cercavo, e che faccio ancora fatica a spiegare ai recruiter, è diverso. Cercavo qualcuno che sapesse scrivere una specifica dichiarativa così precisa che un agente AI potesse implementarla con supervisione minima.

Non un prompt engineer. Un pensatore di sistemi che usa l’AI come runtime, non come stampella.

La differenza sembra sottile, ma non lo è. È la differenza tra chi dice “ho chiesto a ChatGPT di scrivermi il codice” e chi mantiene un file claude.md nel repository con convenzioni architetturali, pattern, vincoli di dominio. È la differenza tra conversazione e specifica. Tra artigianato e ingegneria.

Ho smesso di assumere developer che sanno programmare. Ho iniziato a cercare developer che sanno specificare e che poi verificano quello che l’AI ha prodotto con lo stesso rigore con cui verificherebbero il codice di un junior.

Il mercato italiano non mi sembra ancora pronto per questa distinzione, purtroppo. Ma ho la sensazione che lo sarà presto. E chi non ci arriva in tempo rischia di ritrovarsi con team che “producono” tanto, ma capiscono poco.

Ho smesso di parlare italiano al lavoro #

Sembra una cosa piccola. Non lo è.

Quando è arrivato un nuovo junior non italiano, bravissimo, ci siamo trovati davanti a una scelta. Continuare a lavorare in italiano tra di noi e usare l’inglese solo con lui, creando di fatto un team a due velocità. Oppure fare lo switch completo.

Abbiamo scelto lo switch completo. Tutto in inglese. Jira in inglese. Chat in inglese. Daily in inglese. Retro in inglese. Per tutti.

Non l’ho fatto solo per lui. L’ho fatto per noi.

Perché un’azienda di poche persone in una città italiana che lavora solo in italiano è un’azienda che probabilmente resterà di poche persone in quella città. Non c’è niente di male, davvero. Solo che non è quello che volevamo.

L’inglese, alla fine, non è una lingua. È un’infrastruttura. Come Git, come la CI/CD, come la documentazione. O ce l’hai, o sei tagliato fuori.

È stato scomodo. Qualcuno ha faticato. Ma oggi, quando leggo descrizioni delle pull request, messaggi, email, penso che ne sia valsa la pena.

Ho smesso di credere che il buon codice parli da solo #

Questa è forse la bugia più pericolosa dell’ingegneria del software. L’idea romantica che, se il codice è pulito, testato, ben strutturato, allora il suo valore è evidente. Che il merito tecnico si difenda da solo.

Non funziona così.

Il buon codice che nessuno capisce è indistinguibile dal codice mediocre. Il refactoring che nessuno racconta diventa un costo, non un investimento. La migrazione architetturale senza un business case scritto sembra un capriccio dell’ufficio tecnico.

Ho imparato, tardi, che metà del lavoro di un tech leader è narrare.

Spiegare al board perché una migrazione non è un vezzo ma una riduzione del rischio. Spiegare al cliente perché i test automatizzati che ha pagato sono la ragione per cui dorme tranquillo. Spiegare al team perché la CI/CD non è burocrazia ma libertà e comodità.

Se non sai raccontare il valore di quello che costruisci, qualcun altro lo racconterà al posto tuo. E lo racconterà male.

La cosa che non ho ancora smesso di fare #

Se voglio essere onesto fino in fondo, c’è una cosa che dovrei smettere di fare e non ci riesco ancora.

Lavorare come se fossi l’unico che tiene insieme i pezzi.

Ancora troppe cose passano da me. Non perché il team non sia capace, anzi, ma perché non ho ancora costruito i sistemi che mi rendano superfluo in ognuno degli ambiti in cui operiamo.

Ed è questo che mi spaventa di più.

Perché ogni passaggio precedente aveva un sostituto chiaro. Smettere di scrivere codice? Le specifiche. Smettere di scrivere specifiche? La strategia. Smettere di fare code review? Un team lead. Ma smettere di essere il punto di convergenza di tutto è diverso.

Il sostituto è la fiducia nei sistemi. E i sistemi, se devo dirla tutta, li devo ancora finire di costruire.

Ne riparleremo.