Codice di qualità e arte della programmazione
Per lo Sviluppatore Senior John Cooley, la programmazione è cosa semplice. Ma produrre un codice di buona pratica è un’arte, e raggiungerlo è un viaggio che dura tutta la vita. Ci siamo seduti con lui presso la sede di Engineering Industries eXcellence per saperne di più sul suo lavoro e su cosa significa sviluppo del software di produzione in Engineering.
D: In sintesi, raccontaci cosa fai.
R: Il mio ruolo tradizionalmente è quello di sviluppatore backend. Ho una specializzazione di nicchia nell’integrazione di sistema, in particolare integrazione ERP in MES. Probabilmente faccio il miglior lavoro e mi diverto al massimo ogni volta che cerco di tradurre un insieme di dati da un sistema all'altro e mi immagino le somiglianze e le differenze tra di loro.
Questo è ciò che so fare, ma ogni progetto è diverso dagli altri. E una gran parte del mio lavoro è quella di riuscire ad inserirmi in una situazione dove non ho conoscenze pregresse, per poi dover cercare e utilizzare le risorse esistenti per trovare una buona soluzione. Un altro grande requisito del lavoro è certo livello di fiducia e mancanza di paura quando lavoro su qualcosa di altamente specializzato o tecnico che non ho mai visto o toccato prima. Non so se tutto questo si possa facilmente racchiudere in un titolo di lavoro.
D: Perché programmare? Come sei arrivato al mondo virtuale dei codici?
R: La mia prima esperienza con la programmazione risale all'età di circa 14 anni. Era l'epoca precedente MySpace, perciò se volevi avere una presenza sul web dovevi avere il tuo sito web personale. Come giovane adolescente, avevo un'opinione più che gonfiata della mia arte personale in cui ero molto appassionato. Perciò decisi di imparare il sistema HTML per poter costruire il mio sito personale. Da allora, ho continuato a insegnare a me stesso a codificare. Ho iniziato con le tabelle e i frame HTML e sono passato poi alla programmazione dei server con PERL e PHP. Tutto come autodidatta. Mi divertivo un sacco.
Quando iniziai il college volevo studiare biologia. A metà del primo semestre del mio anno di matricola mi resi conto che amavo studiare la biologia ma che non mi sarebbe piaciuto occuparmene. In quel momento mi accorsi che la biologia non era per me, stavo già facendo funzionare un server dalla mia stanza, che ospitava le mie pagine web personali e pensai che forse quella poteva essere la strada giusta per me. Inizialmente dovetti decidere tra ingegneria elettronica e scienze informatiche. Mi interessavano entrambe. Con l’ingegneria elettronica si può fare qualsiasi cosa. Nel senso che si può costruire il proprio computer se lo si desidera, ma questo avrebbe richiesto un tempo interminabile e sarebbe stato inutile dal punto di vista funzionale. Alla fin fine le scienze informatiche mi piacevano di più perché avevo una migliore propensione a questo tipo di impegno. Ho trovato un ambiente in cui potevo dare frutti e non mi sono mai voltato indietro.
D: Ogni sviluppatore ha un sistema in cui crede. Qual è il tuo?
R: Nel senso più stretto, programmare è davvero semplice e credo che lo possa fare chiunque. Ma la vera difficoltà nella programmazione, che è un viaggio che dura tutta la vita, è produrre un buon codice. Ci sono talmente tanti libri che potrebbero riempire un'intera biblioteca che parlano di cosa è e cosa non è un buon codice. Per me il concetto di “buon codice” è come il concetto taoista dell'illuminazione; chi lo sa se può essere davvero raggiunto in tutta la vita o in tutta la carriera...
D: E quindi, come si produce un “buon codice”?
R: Non credo che la programmazione sia una scienza rigida. In essa vi è un lato assolutamente artistico e creativo. Penso sempre che la programmazione sia metà arte e metà scienza.
Nei primi tempi della programmazione, all'incirca negli anni ‘60 e ‘70, un buon indice di abilità nella programmazione era correlato direttamente all’esperienza e alla conoscenza della matematica e a quanto una persona fosse abile in matematica. Oggi, utilizzando i paradigmi più moderni come la programmazione orientata all'oggetto, un indice maggiore di successo è l'abilità a pensare in modo astratto, a creare gerarchie tra i concetti e a comprendere davvero quali somiglianze e differenze vi siano tra loro, a categorizzare le cose in modo che possano adattarsi al programma. Tutto questo è più semplice se si parla di un oggetto fisico, ma è molto più difficile farlo con un concetto astratto.
Un programmatore è sempre impegnato a scrivere e a progettare software che renderanno il lavoro più semplice piuttosto che più difficile nel futuro. Si può scrivere qualcosa di estremamente astratto e generico, una serie di strumenti che possono essere applicati a qualsiasi cosa, ma il risultato sarà enorme, contorto e complicato. Costerà un sacco di fatica applicarlo ad ogni esigenza individuale. Oppure si può scrivere qualcosa di più specializzato, ma a quel punto si corre il rischio di non soddisfare una nuova richiesta e di dover ritirare, riscrivere e ristrutturare il programma. Alla fine, il lavoro e l'obiettivo dovranno sempre essere quelli di trovare un equilibrio tra queste due situazioni.
D: Come ti assicuri di continuare a crescere come sviluppatore?
R: Specialmente all'inizio della carriera, a prescindere da quale approccio si adotti, inevitabilmente le cose andranno male. Ma si impara dalla propria esperienza e si cerca di adeguare le mosse successive. Si creano controlli ed equilibri in modo organico attraverso i propri errori. Ogni successo e ogni fallimento crea una nuova serie di strumenti da utilizzare e una nuova serie di insidie da evitare. Fondamentalmente si ricorda ciò che fa soffrire. E la prossima volta che si scrive, si terrà conto delle lezioni passate apprese e le si applicherà. Maggiore è l'esperienza, più serve a crescere e a diventare uno sviluppatore migliore. È quella che spinge uno strumento che funziona.
D: Come aiuti i clienti?
R: Non esiste un'unità di misura che vada bene per tutti i progetti, come non esiste un progetto che soddisfi tutti i requisiti. Se esistesse un simile Santo Graal della programmazione, non esisterebbero centinaia di strutture e di linguaggi. Ci sarebbe un libro con una risposta. E in tal caso, non vi sarebbe alcun bisogno di un lavoro come il mio! Buona parte del mio lavoro è quello di applicare le mie abilità, l'esperienza, la conoscenza e le informazioni disponibili all'esterno e di sfruttarle per cercare di immaginare come tutto questo si possa adattare a ciò che il cliente che mi sta di fronte mi dice di volere.
D: Parlaci del lavoro presso Engineering e del tuo team.
La cosa migliore del lavoro in Engineering per me è che ogni cosa è diversa su ogni singolo progetto. Lavoro qui da 3 anni, ma mi sembra di avere cambiato 8 diversi lavori durante questo periodo. Ogni progetto di cui ci si occupa qui è generalmente con un'azienda completamente nuova e con una serie completamente nuova di clienti. Molto tempo significa anche un nuovo team di dipendenti Engineering che non ho mai avuto l'occasione di conoscere e con cui non ho mai lavorato prima. Ogni cliente è una tabula rasa, un altro puzzle da comporre. Si deve sempre stare all'erta. Non è mai monotono. È eccitante, una sfida, e offre l'opportunità di continuare a imparare e a crescere nel proprio lavoro. Non sarebbe possibile in nessun altro modo.
Incontra John Cooley
Dove sei nato/cresciuto: Lake Forest, Illinois
La tua istruzione: Laurea in Scienze Informatiche presso Bradley University
Il tuo titolo: Consulente Analista Senior
Il tuo ruolo in Engineering: Manufacturing Operations
La sede del tuo ufficio: Chicago, IL, USA
Da quanto lavori in Engineering: più di 3 anni
Le tue aree di competenza: sviluppo software e applicazioni, integrazione dei sistemi di produzione, progettazione dei sistemi
