Questo è quello che un bravo programmatore fa istintivamente, secondo Paul Graham. Mi sono appena letto il suo ultimo articolo, o meglio la sua ultima perla di saggezza. Senza ombra di dubbio Paul è una delle persone con le idee più innovative, ed in un certo senso ribelli, nel campo dello sviluppo software e devo dire che c’è sempre da imparare quando si legge uno dei suoi articoli.

In sostanza Paul non dice nulla di completamente nuovo. In realtà porta alla luce qualcosa che ogni bravo programmatore sa già intuitivamente, ovvero che per risolvere un problema devi avere tutto il problema in testa.
Il problema sarebbe il programma che deve fare quello che il programmatore vuole e la sua soluzione sarebbe la trascrizione del programma stesso in un linguaggio interpretabile dalla macchina.

Ma come si fa ad avere tutto un programma in testa? Come si fa a entrare “nella zona”?

Sono sempre stato convinto (ed altri colleghi e amici me lo confermano) che esista uno stato mentale (che alcuni chiamano la zona o il flusso) in cui programmare diventa un atto puramente intuitivo, non si pensa al codice che si vuole scrivere come una serie di istruzioni ma si pensa a quello che si vuole ottenere e magicamente il codice fluisce dalla mente alla macchina attraverso le proprie mani e la tastiera.

Il problema sollevato da Paul Graham è che per entrare in questo stato mentale e sfruttarlo al meglio sono necessarie una serie di condizioni:

1. Eliminare le distrazioni

   La mente dev’essere focalizzata sul problema quindi ogni distrazione va eliminata. Spesso è molto difficile isolarsi, soprattutto nei tipici luoghi di lavoro: sentire persone che parlano ad alta voce, telefonate (odio gli open space) o semplicemente essere interrotti con domande che ti costringono a distogliere l’attenzione da quello che stai facendo.
   In realtà essere focalizzati sul problema non significa necessariamente starsene davanti al PC a programmare. Fortunatamente la nostra mente è talmente sofisticata da riuscire a continuare a pensare a quell’algoritmo a cui stavamo pensando la mattina anche mentre ci mangiamo un panino al bar all’ora di pranzo.
   Il punto è che vanno evitate quelle interruzioni che costringono a ragionare su qualcos’altro, creando così un context switch mentale che può richiedere ore per farci ritrovare la concentrazione persa.
   Infine, oltre alle distrazioni non programmate, è bene anche evitare il più possibile le distrazioni programmate. Quale programmatore si mette a lavoro su un problema complesso quando sa che un’ora dopo deve andare in riunione? Meglio quindi fare le riunioni la mattina e rimanere concentrati per il resto della giornata.

2. Programmare ininterrottamente

   Ovvero è più produttiva una serie di hacking run seguita da un periodo di “ricarica delle batterie” piuttosto che seguire un orario di lavoro prestabilito.
   Questo deriva dal fatto che ci vuole un po’ di tempo per entrare ed uscire dalla “zona”. Personalmente quando faccio una sessione di coding “spinta”, poi trovo molto difficile uscirne, anche se sono fisicamente stanchissimo il mio cervello continua ad elaborare (anche tramite le brain waves sarebbe possibile rendere più veloce questo passaggio).

3. Usare linguaggi sintetici

   Lo spazio di attenzione nel nostro cervello è limitato visto che sfortunatamente la mente umana non riesce ancora a fare un uso cosciente dell’enorme capacità d’immagazinamento a sua disposizione. Quindi un modo per “risparmiare spazio” è quello di aumentare il livello di astrazione usando linguaggi più sintetici e potenti.
   Prendiamo ad esempio un’applicazione web per gestire un blog. Pensa alla sua implementazione in C o in Java o in PHP o Ruby (on Rails). In quali di questi linguaggi riesci ad avere una visione dell’applicazione più chiara e completa?
   Inoltre Paul suggerisce che il processo di astrazione possa avvenire anche a livello applicativo, non soltanto tramite il linguaggio. Con un approccio bottom-up ci si crea un insieme di macroblocchi (una sorta di domain specific language) con i quali poi costruire l’applicazione (ed è proprio questo il motivo per cui vengono usati i framework software).

4. Riscrivere i programmi

   Da buon geek sono sempre stato un sostenitore della programmazione evolutiva, che non ha niente a che fare con gli algoritmi evolutivi ma descrive soltanto l’approccio alla programmazione di tipo iterativo. Questo tipo di coding comporta una riscrittura frequente del codice per aggiungere nuove funzionalità, fare bug fixing o semplice refactoring.
   Riscrivere il codice più volte ha due vantaggi: il primo è che la qualità del codice non può far altro che migliorare (anche se non è sempre così) ed il secondo è permette di acquisire familiarità con il codice, chiarificandone la funzione nella nostra mente.

5. Scrivere codice leggibile

   Un programmatore può avere vari stili di scrittura del codice a seconda del suo stato mentale e del motivo per cui lo sta scrivendo.
   Se sto scrivendo un prototipo per verificare che l’idea che ho avuto un’ora prima ha un qualche senso, cercherò di risparmiare tempo scrivendo codice conciso ed immediato, lasciando eventualmente ad una sessione di refactoring successiva l’onere di rendere il programma più leggibile.
   Se invece sto scrivendo del codice che probabilmente dovrà leggere qualcun’altro o dovrò riprendere in mano tra un lasso di tempo indefinito, cercherò di rendere chiaro quello che sto facendo magari con l’aiuto di qualche commento.
   Per inciso, molti pensano che per scrivere codice leggibile basti mettere dei commenti qua e là. Niente di più sbagliato. Il codice deve essere leggibile perchè il suo scopo deve essere chiaro a chi lo legge. L’algoritmo implementato deve essere evidente leggendo il codice dell’implementazione.

6. Lavorare soli o in piccoli gruppi

   Dopo molti anni in una grande azienda posso dire la mia sul fatto di lavorare in grossi team di sviluppo: è un gran casino! Specialmente se i membri del team sono distribuiti su tre fusi orari diversi.
   Il problema di lavorare in team è che si creano delle dipendenze, che dal punto di vista del programmatore sono come dei buchi neri nella sua visione dell’applicazione. Il suo orizzonte di conoscienza finisce dove finisce il suo codice e se ha bisogno di vedere più in là allora nascono i problemi e si rischia lo stallo.
   La soluzione è quella di lavorare in piccoli gruppi suddividendo l’applicazione in parti disaccoppiate tra di loro. In questo modo si eliminano le dipendenze all’interno del gruppo massimizzandone l’agilità.

7. Evitare che più persone lavorino sullo stesso codice

   Anche all’interno di un singolo gruppo possono nascere delle dipendenze. Evitare quindi che più programmatori lavorino sulla stessa funzionalità. Ogni programmatore ha il proprio stile implementativo e cercare di capire il codice altrui non è sempre un impresa facile, specialmente se il codice non è per niente leggibile.
   Sarebbe come se due pittori cercassero di dipingere un ritratto sulla stessa tela, ognuno col proprio stile.

8. Iniziare dalle cose semplici

   Il modo migliore per riuscire ad avere un programma complesso in testa è quello di prenderne familiarità lentamente. Cercare di pensare subito all’applicazione in tutta la sua complessità sarebbe come pensare di scalare una montagna guardandone la cima, invece che pensare ad un lungo cammino è meglio pensare a tanti piccoli cammini meno intimidatori.
   Allo stesso modo è bene iniziare a pensare all’applicazione come un insieme di black box che “fanno qualcosa” senza pensare al “come”, per poi approfondirne la conoscenza aumentando il livello di dettaglio. Come allo stesso modo si costruisce una casa partendo dalle fondamenta e dalle impalcature, fino ad arrivare ai dettagli come il colore delle mattonelle o il tipo di maniglie per le porte.

Penso che sia molto difficile applicare tutte queste regole, almeno nel caso in cui si faccia il programmatore “per lavoro” e sicuramente nel caso in cui si faccia parte di una grossa azienda che probabilmente è abituata a procedure standard che non si sposano molto con il concetto di geek o di hacker.

Il target dell’articolo di Paul Graham è sicuramente quello delle startup (visto che ne finanzia molte), dove si è più liberi ed è più facile seguire queste regole, ma sono sicuro che in futuro gli stessi concetti inizieranno ad essere applicati anche da chi lavora per aziende un po’ più grandi visto che sarà l’unico modo per mantenersi competitivi da un punto di vista tecnologico (specialmente nel campo del world wide web).