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 visione tende a fermarsi ai margini del codice che possedete. Le altre parti non si capiscono altrettanto bene e, soprattutto, non ci si può prendere delle libertà. Quindi, minore è il numero di programmatori, più un progetto può mutare completamente. Se c’è un solo programmatore, come spesso accade all’inizio, si possono fare riprogettazioni complete.

* Non far modificare lo stesso codice a più persone. Non si capisce mai il codice degli altri come il proprio. Non importa quanto accuratamente lo abbiate letto, lo avete solo letto, non scritto. Quindi, se un pezzo di codice è scritto da più autori, nessuno di loro lo capisce bene quanto un singolo autore.

E, naturalmente, non si può riprogettare in sicurezza qualcosa su cui stanno lavorando altre persone. Non si tratta solo di chiedere il permesso. Non ci si permette nemmeno di pensare a queste cose. Riprogettare il codice con più autori è come cambiare le leggi; riprogettare il codice che si controlla da soli è come vedere l’altra interpretazione di un’immagine ambigua.

Se volete far lavorare più persone a un progetto, dividetelo in componenti e affidate ciascuno a una persona.

* Iniziare in piccolo. Un programma diventa più facile da tenere a mente man mano che ci si familiarizza. Si può iniziare a trattare le parti come scatole nere quando si è sicuri di averle esplorate a fondo. Ma quando si inizia a lavorare su un progetto, si è costretti a vedere tutto. Se si inizia con un problema troppo grande, si rischia di non riuscire a comprenderlo del tutto. Quindi, se dovete scrivere un programma grande e complesso, il modo migliore per iniziare potrebbe non essere quello di scrivere una specifica, ma di scrivere un prototipo che risolva un sottoinsieme del problema. Qualunque siano i vantaggi della pianificazione, spesso sono superati da quelli della capacità di tenere un programma nella propria testa.

È sorprendente come spesso i programmatori riescano a raggiungere tutti gli otto punti per caso. Qualcuno ha un’idea per un nuovo progetto, ma poiché non è ufficialmente autorizzato, deve realizzarlo nelle ore libere, che si rivelano più produttive perché non ci sono distrazioni. Spinto dall’entusiasmo per il nuovo progetto, ci lavora per molte ore di seguito. Poiché inizialmente si tratta solo di un esperimento, invece di un linguaggio di “produzione” utilizza un semplice linguaggio di “scripting”, che in realtà è molto più potente. Riscrive completamente il programma più volte; ciò non sarebbe giustificabile per un progetto ufficiale, ma questo è un lavoro d’amore e vuole che sia perfetto. E poiché nessuno lo vedrà, tranne lui, omette qualsiasi commento, tranne le note a sé stesso. Lavora per forza in un piccolo gruppo, perché o non ha ancora parlato a nessun altro dell’idea, o sembra così poco promettente che nessun altro può lavorarci. Anche se c’è un gruppo, non possono esserci più persone che modificano lo stesso codice, perché cambia troppo velocemente per essere possibile. E il progetto inizia in piccolo perché all’inizio l’idea è piccola: ha solo un hack interessante che vuole provare.

Ancora più sorprendente è il numero di progetti ufficialmente approvati che riescono a fare tutte e otto le cose in modo sbagliato. In effetti, se si osserva il modo in cui il software viene scritto nella maggior parte delle organizzazioni, è quasi come se stessero deliberatamente cercando di fare le cose in modo sbagliato. In un certo senso, è così. Una delle qualità che definiscono le organizzazioni da quando esistono è quella di trattare gli individui come parti intercambiabili. Questo funziona bene per i compiti più parallelizzabili, come combattere le guerre. Per la maggior parte della storia si è potuto contare su un esercito ben addestrato di soldati professionisti in grado di battere un esercito di singoli guerrieri, per quanto valorosi. Ma avere idee non è molto parallelizzabile. E i programmi sono proprio questo: idee.

Non è solo vero che alle organizzazioni non piace l’idea di dipendere dal genio individuale, è una tautologia. È parte della definizione di organizzazione, non farlo. Per quanto riguarda il nostro attuale concetto di organizzazione, almeno.

Forse potremmo definire un nuovo tipo di organizzazione che combini gli sforzi degli individui senza richiedere che siano intercambiabili. Probabilmente il mercato è una forma di organizzazione di questo tipo, anche se forse è più corretto descriverlo come un caso degenerato, come ciò che si ottiene per default quando l’organizzazione non è possibile.

Probabilmente il meglio che potremo fare è una sorta di hack, come far funzionare le parti di programmazione di un’organizzazione in modo diverso dal resto. Forse la soluzione ottimale è che le grandi aziende non provino nemmeno a sviluppare idee in casa, ma semplicemente le acquistino. Ma a prescindere da quale sia la soluzione, il primo passo è rendersi conto che c’è un pr...