Le buone pratiche

Sono di ritorno da un corso della fondazione Software Carpentry, ospitato all’Università Milano Bicocca per due giorni. E’ successo tutto in tempi brevissimi, da quando ho saputo dell’esistenza del corso a quando ho pensato di partecipare e sono riuscito a ritagliare il tempo per andarci. E siccome è stato davvero un gran bel corso, voglio lasciare una traccia.

Mi leggi ancora? Se nel tuo lavoro quotidiano hai necessità di importare, elaborare, graficare ed analizzare dati sperimentali e ti stai chiedendo se davvero tu debba ripetere ossessivamente le stesse operazioni, come copiare numeri a colpi di mouse (o CTRL+C e CTRL+V) in fogli di calcolo che cambierai di continuo, quello che c’è scritto qui potrebbe esserti utile. Almeno per orientarti.

Perché? La ricerca scientifica si basa su qualità umane, professionali, un buon senso pratico e critico, un’etica rigorosa, ed infine… una buona conoscenza di tecniche e metodi. Nella sperimentazione (i teorici non me ne vogliano) bisogna impadronirsi di quelle tecniche sperimentali e numeriche che consentano di tirar fuori i dati sperimentali. Dati che poi importo in foglio di calc….NO! Come diceva il maestro Shifu in Kung-Fu Panda, saper scrivere bene un software (per assistere il lavoro del ricercatore nel suo tortuoso cammino verso la conoscenza) è tanto importante quanto disporre di strumenti di laboratorio affidabili, verificati. E tanta pace interiore. Ma se c’è una discreta cultura di buona manutenzione della strumentazione di laboratorio, non c’è altrettanta attenzione alla scrittura, manutenzione e validazione del software per l’inferenza sperimentale. Semplicemente, non gli si è data sufficente importanza e tocca arrrangiarsi alla meno peggio, perché le priorità sono sempre altre. Il prezzo da pagare? La re-invenzione della ruota, software che funziona per un po’ e che poi nessuno sa più come aggiornarlo (nemmeno lo stesso autore, che ha dimenticato perché ha fatto questo e come mai ha fatto quello), infinite directories con dati duplicati e nomi di files che evocano desiderio di concludere (come ultimo.doc, ultimo2.doc, ultimo2_correzioni.doc, ultimo2_correzioni-20180123.doc, ultimo2_correzioni-nuov.doc e via così…).

Si torna a scuola. Ed allora se questi strumenti il ricercatore non li ha, tocca aiutarlo. E qui ha contribuito la fondazione Software Carpentry, da quasi 20 anni, prima negli Stati Uniti e poi, a macchia d’olio, in tutto il mondo. Il manifesto della fondazione ed i suoi obiettivi sono ben riassunti in un articolo open access che si chiama Best Practices for Scientific Computing, ovvero le Buone Pratiche per il Calcolo Scientifico. Quando l’ho letto, è stato come fare una doccia gelata. Nonostante le mie buone intenzioni di migliorare ciò che faccio, mettendomi spesso in discussione, nello scrivere software per produrre ed elaborare i miei dati sperimentali io starei commettendo quasi tutti gli errori più comuni. E non solo io, ma la maggior parte delle persone con cui lavoro. E siccome ci lamentiamo sempre di più della mancanza di tempo, forse è arrivato il momento di porsi qualche domanda, e di cercare delle soluzioni.

I corsi della Software Carpentry si sono evoluti negli anni, da un modello di cinque giorni ad immersione totale (massacrante) ad un più snello modello di due giorni, meno stancante ma necessariamente meno completo. C’è una bella autocritica dei primi quindici anni di attività in un altro articolo: Software Carpentry: lessons learned. Il formato delle lezioni ed il loro contenuto è standard, disponibile pubblicamente sul loro portale, oltre che gratis (leggere bene la licenza d’uso). Cambiano solo i docenti, che pero’ devono prima aver seguito un corso di formazione. Può cambiare la combinazione dei moduli insegnati, ma il filo conduttore resta sempre dotare il ricercatore delle informazioni base su cui costruire il suo nuovo modo di lavorare.

Oltre ai docenti, in sala ci sono dei volontari che passano per le file dei banchi, pronti a soccorrere chi ha attaccato un post-it rosa, a segnalare che sta avendo un problema. Chi ha messo su un post-it verde sta invece segnalando che ha completato un esercizio e non ha riscontrato difficoltà. Alla fine della sessione del mattino e di quella del pomeriggio, sugli stessi post-it ci scrivi (in forma anonima) che cosa ti è piaciuto, di quella parte, e che cosa no. E già dopo poche ore ti accorgi che gli istruttori hanno aggiustato il tiro, segno che quei post-it li hanno letti già. Non male.

E cosa curiosa…chi ha frequentato questi corsi tende a restare coinvolto con la fondazione, dando una mano come volontario in un corso vicino casa, o diventando istruttore. Come mai? Loro spiegano così:

But why do people volunteer as instructors?

To make the world a better place. The two things we need to get through the next hundred years are more science and more courage; by helping scientists do more in less time, we are helping with the former.

To make their own lives better. Our instructors are often asked by their colleagues to help with computing problems. The more those colleagues know, the more interesting those requests are.

Riferimenti bibliografici.

Wilson G, Aruliah DA, Brown CT, Hong NPC, Davis M, Guy RT, et al. Best Practices for Scientific Computing. Eisen JA, editor. Plos Biol. Public Library of Science; 2014 Jan 7;12(1):e1001745. DOI: 10.1371/journal.pbio.1001745

Wilson G. Software Carpentry: lessons learned. F1000Research. 2016 Jan 28;3.

Messo il tag: git, programmazione, python

Posted in: Riflessioni