Episode Details

Traduzione e lettura in italiano di Matteo Faieta dall’essay originale di Paul Graham "Holding a Program in One's Head" [Agosto 2007].

Un buon programmatore, quando lavora intensamente sul proprio codice, riesce a tenerlo a mente come un matematico tiene a mente un problema su cui sta lavorando. I matematici non rispondono alle domande facendo calcoli su carta come si insegna agli studenti. Lavorano molto nella loro testa: cercano di comprendere lo spazio del problema così bene da potercisi muovere attorno, proprio come si cammina a memoria della casa in cui siete cresciuti. Nel migliore dei casi, con la programmazione è la stessa cosa. O meglio, la programmazione funziona allo stesso modo: avete tutto il programma nella vostra mente, e potete manipolarlo a piacimento.

Questo è particolarmente prezioso all’inizio di un progetto, perché ciò che conta davvero è poter cambiare ciò che state facendo. Non solo risolvere il problema in modo diverso, ma cambiarne direttamente la natura.

Il codice è la comprensione del problema che si sta esplorando. Quindi è solo quando avete il codice in mente che capite davvero il problema.

Non è facile tenere un programma nella propria mente. Se si lascia un progetto per qualche mese, possono volerci giorni per capirlo di nuovo quando ci si ritorna. Anche quando si lavora attivamente su un programma, può essere necessaria mezz’ora per caricarlo in testa quando si inizia a lavorare ogni giorno. E questo nel migliore dei casi. I programmatori ordinari, che lavorano in normali uffici, non entrano mai in questo stato. Oppure, per dirlo più chiaramente, i programmatori ordinari che lavorano in normali uffici non capiscono veramente i problemi che stanno risolvendo.

Anche i migliori programmatori non sempre hanno in testa l’intero programma su cui stanno lavorando. Ma ci sono cose che potete fare per aiutarvi:

* Evitare le distrazioni. Le distrazioni sono dannose per molti tipi di lavoro, ma soprattutto per la programmazione, perché i programmatori tendono a lavorare al limite dei dettagli che possono gestire.

La pericolosità di una distrazione non dipende dalla sua durata, ma dall’effetto che ha sulla mente. Un programmatore può uscire dall’ufficio per un panino senza perdere il filo, ma la distrazione sbagliata può azzerare la mente in 30 secondi.

Stranamente, le distrazioni programmate possono essere peggiori delle impreviste. Se sapete di avere una riunione tra un’ora, non iniziate nemmeno a lavorare su qualcosa di complesso.

* Lavorare per lunghi periodi. Ogni volta che si inizia a lavorare su un programma c’è un costo fisso. È più efficiente lavorare in poche sessioni lunghe piuttosto che in molte brevi. Naturalmente arriverà un momento in cui si diventa stupidi per stanchezza. Questo varia da persona a persona. Ho sentito di persone che hanno hackerato per 36 ore di fila; io il massimo che sono riuscito a fare è di circa 18 ore, e io lavoro al meglio in slot di non più di 12 ore.

L’ideale non è il limite che si può sopportare fisicamente. Spezzare un progetto ha un vantaggio e un costo. A volte, quando si torna a un problema dopo una pausa, si scopre che la mente inconscia ha lasciato una risposta in attesa.

* Usare linguaggi sintetici. I linguaggi di programmazione più potenti rendono i programmi più brevi. E i programmatori sembrano pensare ai programmi, almeno in parte, nel linguaggio che usano per scriverli. Più il linguaggio è sintetico, più il programma è breve e più è facile da caricare e da ricordare.

È possibile amplificare l’effetto di un linguaggio potente utilizzando uno stile chiamato programmazione bottom-up, in cui si scrivono programmi in più livelli, quelli inferiori fungono da linguaggi di programmazione per quelli superiori. Se lo si fa bene, va tenuto in mente solo il livello più alto.

* Continuare a riscrivere il programma.