Da Senior Developer al CTO: il cambiamento di mestiere di cui nessuno parla Tutti adorano raccontare il passaggio da Senior Developer a CTO come un’evoluzione naturale. Leadership visionaria, strategia, innovazione, visione a lungo termine. Parole eleganti, rassicuranti, che non raccontano la parte scomoda: quando diventi CTO smetti di fare il lavoro per cui hai studiato per anni. Non è una promozione. È un cambio di mestiere. E quasi nessuno ti prepara a questo shock.

Quando ho capito di essere diventato un micromanager (e perché è stato il mio turning point) Ricordo perfettamente la scena. Era un giovedì mattina qualunque, uno di quelli in cui l’agenda è una lista di fuochi da spegnere e il caffè non è mai abbastanza. Il mio team stava lavorando a una nuova integrazione e dovevamo rispettare una scadenza serrata. Io ero in call, con le cuffie mezze storte e una mano sulla tastiera, mentre rileggevo per la terza volta una PR che avevo già corretto cinque giorni prima.

Gestione degli incidenti in produzione: la mia checklist mentale Quando qualcosa va storto in produzione, serve metodo, lucidità e soprattutto collaborazione. Nel tempo ho sviluppato una checklist mentale che mi permette di muovermi in modo ordinato, evitando reazioni impulsive e lavorando in tandem con il team più adatto alla situazione. In questo articolo condivido il mio approccio alla gestione degli incidenti, organizzato in blocchi logici che possono essere applicati in qualsiasi contesto tecnico.

Come valuto un Developer Senior (oltre la tecnica) Quando valuto un developer senior, la competenza tecnica è solo una delle variabili – e spesso non la più importante. Un senior developer, per definizione, è una figura che deve saper incidere sul team, sui processi, sull’azienda. Per questo, il mio metodo di valutazione mette al centro aspetti che vanno ben oltre il codice. Soft Skill: il vero moltiplicatore di valore Le soft skill sono la base di tutto.

Log, metriche, trace: come penso all’osservabilità di un sistema distribuito Come tastare il polso del sistema e capire cosa succede e dove. Misurare è controllare, il tempo investito nell’implementazione dei log non è mai sprecato ma il migliore degli investimenti. Differenza tra l’analisi di un problema su un monolite e su un sistema distribuito Nel mondo monolitico l’analisi di un problema è quasi sempre un percorso lineare e prevedibile: un solo codice, un solo ambiente, un solo punto di osservazione.

Guidare il team attraverso un refactoring massivo senza uccidere la delivery Navigare nel tempestoso mare del refactoring senza far naufragare uptime e delivery. Cercare di rimanere dentro i tempi dello sprint senza bucare le scadenze mentre si fa deep refactoring e allo stesso tempo si rilasciano nuove feature è come camminare sul ghiaccio: ogni passo può essere quello giusto… o quello che fa crepare tutto. Il refactoring massivo ha una caratteristica crudele: il valore del lavoro non è visibile fino alla fine, mentre i costi sono percepiti immediatamente.