1. Di cosa ti occupi?
In termini tecnici, la mia competenza “verticale” è la programmazione (o “Software Engineering”). Sono specializzato in applicazioni web distribuite, tecnologie open-source e in sistemi basati su Linux. A questo affianco competenze sui processi produttivi dal taglio piuttosto tecnico, attraverso ad esempio il coaching. In altre parole mi occupo di costruire e mantenere in funzione il software (e i processi) attraverso cui le aziende realizzano i loro profitti. La peculiarità è che lo faccio con una serie di tecniche e processi che hanno presupposti economici adatti a funzionare sia nel breve che nel lungo periodo.
In Italia la figura del “coach” non è molto diffusa, ma se dovessi fare un paragone, è qualcosa di simile all’allenatore di una squadra sportiva, come calcio o pallavolo. Non ha la responsabilità di una singola piccola azione o di un’atleta (quella è del preparatore atletico), ma del programma di gara e del processo intero.
Per realizzare software funzionante servono due cose (almeno): persone con un problema da risolvere e persone in grado di farlo attraverso l’informatica. Devo garantire che l’insieme generale di cose che fa un team risolva in modo economico e veloce il problema del cliente, allo stesso però tempo va garantito che non ci siano passi indietro o problemi futuri. I passi che portano l’idea ad essere un programma ai suoi utilizzatori finali si chiamano “processo produttivo”. Se realizziamo un edificio, ad esempio, faremo un progetto su carta, uno studio geologico, poi degli scavi per le fondamenta, innalzeremo i muri portanti e così via. Dal momento zero siamo in grado di vedere coi nostri occhi quello che accade. La fregatura del software (e del lavoro intellettuale in generale) è che finché il lavoro non è finito non esiste alcuna percezione di cosa sta accadendo ed è molto difficile comunicare con gli altri. Quindi servono una serie di tecniche adeguate a farlo. In questo c’è il procedere a piccolissimi passi, la possibilità di cambiare idea, creare dei meccanismi che consentano di imparare continuamente.
2. Come mai hai deciso di intraprendere la tua carriera?
Ti direi per passione. Mi sono avvicinato ai computer per gioco con l’aiuto degli “adulti” ai tempi della scuola materna, giocando ovviamente. Non so estrapolare un motivo o un momento preciso in cui ho preso una decisione, ti direi più che è stato un progressivo scoprire la propria passione. Poi alle elementari ho scoperto che i giochi si potevano anche costruire: bastava imparare la lingua del computer. Da lì non ho più mollato, ho solo dovuto “accettarlo” e perseverare. Non credo nel dualismo “segui la passione” versus “segui la razionalità”, specialmente nell’informatica. Ovviamente vale per tutti quei mestieri dove si deve studiare sempre, chi sceglie questo mestiere si “condanna” a studiare ogni giorno per tutta la sua carriera.
Dell’informatica mi ha sempre affascinato l’idea di poter costruire qualcosa di funzionante dal nulla, e con opportunità di impatto potenzialmente infinito sulla vita delle persone. Pensa a Wikipedia, Skype, eBay, Facebook, YouTube, Twitter, Whatsapp, Airbnb e via dicendo. Fino ad un paio di decadi fa non esisteva niente del genere. La vita delle persone era diversa, la società era diversa.
3. Come ti sei avvicinato a DevOps? E qual è la cosa che ti entusiasma di più riguardo DevOps?
Come dicevo nella risposta precedente mi sono avvicinato alla programmazione da piccolo. Poi quando avevo 12 anni ho iniziato a frequentare degli amici più grandi che avevano creato un Linux User Group. Gli “User Group” esistono ancora oggi, molti preferiscono chiamarli Meetup (dal nome della piattaforma, che ha dato un nome più altisonante al format), ma esistono. Un gruppo di conoscenti, amici o professionisti che si ritrova per piacere in un certo luogo con l’obiettivo di sperimentare, imparare o insegnare un determinato argomento (il nostro era appunto, Linux). Poi la passione si è progressivamente trasformata in studio e poi in professione. Comunque da lì ho scoperto Unix, ho imparato il suo modo di pensare (la Unix Way), sia dal lato del sistemista che quello del programmatore (partendo dal C). Quindi ho iniziato a imparare l’informatica come se le attività di “sviluppo” e quelle di “mantenimento in opera” fossero due campi di studio strettamente collegati. Forse la mia è stata una delle ultime generazioni a farlo. Quando ho percepito che questo cambiamento stava avvenendo, ho continuato a studiare concentrando le mie forze sui temi back-end e su Linux.
Con le ondate tecnologiche degli ultimi 20 anni il nostro mestiere è cambiato moltissimo, la disciplina si è espansa e sono apparse figure più specifiche. In particolare la disponibilità di infrastrutture è aumentata, così abbiamo iniziato ad applicare l’informatica ai mondo dei sistemi informatici – lusso che prima era riservato ai colossi (sto semplificando molto, ma l’idea è quella). Qualche decina di server si poteva anche gestire “a mano”, oppure si acquistava un server più potente raggiunti determinati limiti. Oggi è un approccio piuttosto fuori moda e un po’ antieconomico. Se da una parte creare applicazioni è diventato più semplice e i linguaggi hanno barriere di accesso inferiore, la complessità si è nascosta nello strato inferiore, quello delle infrastrutture. E così, a conti fatti, il sistemista di oggi è diventato un programmatore specializzato in sistemi operativi (quando costruisce le cloud) e software di tipo infrastrutturale (quando le usa).
Di tutto il compendio DevOps la cosa che mi entusiasma è vedere un team di professionisti che arriva a rilasciare il proprio lavoro software in piccoli pezzettini, magari centinaia al giorno e sempre migliori. Sembra una cosa scontata, ma spesso significa che quel team è riuscito a mettere in piedi un processo di apprendimento.
4. Cosa ti ha spinto a scrivere il tuo libro su DevOps?
Sono davvero molte, è una domanda che mi faccio ancora oggi. Ti menziono solo i primi due.
La prima è che volevo scrivere, mi piace scrivere e volevo mettermi alla prova, è un’abitudine che frequento fin da piccolo. Ho scritto diversi generi di testo nel tempo, legati al mondo della narrativa, dell’informazione, qualche volta dello spettacolo. Ma non avevo mai scritto un testo di divulgazione scientifica, niente meno un libro intero. Non ero mai andato oltre le 30-40 cartelle (pagine). Nel 2017 il GrUSP (una delle più grandi associazioni di sviluppatori software in Italia) stava cercando idee e autori per un nuovo libro (ne avevano già alle spalle diversi, scritti a più mani). Mi proposi. Volevo mettermi alla prova scrivendo un capitolo o due di un ipotetico manuale tecnico, codice sorgente. Mi sembrava un’impresa dalla difficoltà commisurata alle mie capacità. Solo che il discorso cadde nel dimenticatoio. Ma si ripresentò in un’altra forma nel 2019, quando ricevo una mail dal Presidente dell’associazione Francesco Fullone che mi mette direttamente in contatto con un editore. Non più una piccola casa editrice però, ma un editore tradizionale, un colosso che desiderava a catalogo un testo del genere. Avevano appena tentato un progetto a più mani, solo che i precedenti autori non hanno mai consegnato l’opera (per vari motivi che non menzino). A quel punto l’editore e Francesco cercavano un autore singolo, ma dal un background trasversale, così sono arrivati a me. Dopo che abbiamo discusso il timone del libro ero molto scettico, e non sapevo se ce l’avrei fatta. Scrivere un testo così da solo è una bella sfida. Sono oltre 300 pagine. Poi ho pensato che le occasioni sono occasioni. E mi sono buttato.
La seconda è che spero davvero possa essere utile a coloro che desiderano fare software per mestiere, o ci sono dentro per traverso. L’argomento proposto dall’editore mi piaceva moltissimo ed era vicino alla mia esperienza fatta fino ad allora. Un testo del genere rivolto al grande pubblico italiano mancava, così come l’organizzazione di un certo ventaglio di conoscenze di base relative al mestiere del programmatore. Mi auguro che anche solo una persona tra i lettori possa aver imparato qualcosa che gli serve a lavorare un po’ meglio di come faceva il giorno prima.
Non perdere la seconda parte dell’intervista a Fabio: Le 3 difficoltà più grandi per le organizzazioni che vogliono utilizzare DevOps
