Costruire per capire

Ho un criterio semplice per sapere se ho capito una cosa: riesco a costruirla? Non a ripeterla, non a riassumerla. A costruirla — come modello, come codice, come figura, come capitolo che regge una bibliografia.

Quando leggo che l’allenamento aumenta il contenuto mitocondriale del muscolo, la frase è vera ma inerte. Quando provo a scriverla come sistema di equazioni, scopro subito cosa non so: quanto è veloce il segnale acuto rispetto alla trascrizione? Il segnale si somma tra sedute vicine o si resetta? Cosa succede se smetto? Il modello mi costringe a fare domande che la lettura passiva non fa emergere. È così che è nato il modello di biogenesi mitocondriale.

Il ciclo

1. Leggere — fonti primarie quando posso, review quando servono per orientarmi. Annoto il livello di evidenza di ogni affermazione, non solo l’affermazione.
2. Costruire — un modello, un’app, una figura, un capitolo. La forma dipende dalla domanda: una dinamica nel tempo diventa un sistema di ODE; un’abitudine da misurare diventa una PWA; un argomento lungo diventa una serie come IPERTROFIA.
3. Verificare — contro la letteratura, contro i dati, contro me stesso. Per il software questo significa un loop di QA che non si ferma alla prima versione che “funziona”.

Poi si ricomincia, perché la verifica quasi sempre riapre la lettura.

Perché funziona

• Rende visibili i buchi. Un testo può essere vago; un modello no. Ogni parametro senza fonte è un buco dichiarato.
• Separa ciò che so da ciò che stimo. Costruendo devo decidere, e ogni decisione va etichettata: è un dato, una stima, una congettura? È la disciplina di So, stimo, speculo, non so.
• Lascia un artefatto. Quello che ho capito non resta solo nella mia testa: resta in un repository, in un PDF, in un’app che posso riaprire tra sei mesi e criticare.

Il rischio

Costruire è seducente: un modello elegante può sembrare vero solo perché è elegante. L’antidoto è trattare ogni costruzione come un’ipotesi con il suo intervallo di incertezza, non come una risposta.