Paul Graham: il pifferaio magico dei nerd

Tenere un Programma nella Propria Mente // Holding a Program in One's Head

May 7, 2026·15 min
Episode Description from the Publisher

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. La riscrittura di un programma spesso produce un progetto più pulito. Ma i vantaggi ci sarebbero anche se non fosse così: per riscrivere un programma bisogna capirlo completamente; quindi, non c’è modo migliore di farselo entrare in testa.* Scrivere codice leggibile. Tutti i programmatori sanno che è bene scrivere codice leggibile. Ma voi stessi siete il lettore più importante. Soprattutto all’inizio, un prototipo è una conversazione con voi stessi. E quando si scrive per se stessi, le priorità sono diverse. Se state scrivendo per altre persone, potreste non voler rendere il codice troppo denso. Alcune parti di un programma possono essere più facili da leggere se si distribuiscono le cose, come un libro di testo introduttivo. Se invece state scrivendo del codice per ricaricarlo facilmente nella vostra testa, forse è meglio optare per la brevità.* Lavorare in piccoli gruppi. Quando manipolate un programma nella vostra testa, la vostra vi

Podzilla Summary coming soon

Sign up to get notified when the full AI-powered summary is ready.

Get Free Summaries →

Free forever for up to 3 podcasts. No credit card required.

Listen to This Episode

Get summaries like this every morning.

Free AI-powered recaps of Paul Graham: il pifferaio magico dei nerd and your other favorite podcasts, delivered to your inbox.

Get Free Summaries →

Free forever for up to 3 podcasts. No credit card required.