C’è un certo fervore nell’aria, “quelli bravi” si accorgono sempre più che qualcosa sta per cambiare, che si può innovare e divertirsi invece di rimanere nella gabbia di una grande azienda.
E grazie a questo potente mezzo che è la rete, stanno nascendo nuovi modi di lavorare assieme, nuovi modi di collaborare, nuove forme di scambio.

L’aspetto che più mi piace di questo periodo di fervore è la comunità. In Italia si sta creando un network di elite interdisciplinare: programmatori, esperti d’informazione, bloggers, designers. Si comunica, ci si diverte, si lavora assieme e gli altri stanno a guardare, seguono.

Ed ecco il senso di questo post.
L’ultima volta che mi sono sentito parte di qualcosa del genere è stato negli anni ’90, quando Internet era per pochi e si comunicava con Fidonet, quando invece di Skype e degli instant messenger c’erano IRC e la netmail.

In quel periodo, principalmente in Europa, si diffuse il fenomeno della così detta “scena demo“, ovvero gruppi di appassionati di programmazione, grafica e musica che, sfruttando al massimo la loro creatività e le capacità dell’hardware di quei tempi, producevano software chiamati demo (in realtà vere e proprie opere d’arte) che dimostravano le loro abilità e la loro bravura.

In Italia questo fenomeno fu seguito da qualche decina di giovani appassionati e con tanta voglia di dimostrare al mondo le proprie capacità e di competere con i fratelli nordici.
A quel tempo comunicare non era facile come oggi, i cellulari erano una rarità e collegarsi a Internet o Fidonet costava una cifra. Così ogni occasione era buona per incontrarsi di persona, scambiare idee e codice, iniziare collaborazioni o creare su due piedi qualcosa di nuovo.

Quello che ricordo con più nostalgia è sicuramente l’unione che si era creata in questo gruppo di persone, si era tutti amici, indipendentemente dalla città d’origine, quando ci si trovava (allo SMAU, a casa di qualcuno o semplicemente in giro) c’era sempre di che imparare e di che insegnare, non ci si annoiava mai e ci si divertiva sempre.

Ed è proprio questo aspetto che mi fa sentire un po’ come in una nuova scena, sperando che continui e prosperi e che non muoia come la mitica scena demo degli anni ’90.

Per avere un idea di quello che è stato, ho trovato questo clip su YouTube girato al The Trip 98, uno dei pochissimi party che si sono tenuti in Italia ed organizzato dal team di cui facevo parte (DeathStar). La mia bella facciona appare al 1’47″:

Update: nei meandri del mio hard disk ho trovato il mio video report del Trip 1999 tenutosi al Palasport di Firenze dal 25 al 28 Marzo 1999:

È ormai di dominio pubblico la notizia che Google ha iniziato il suo assalto al mondo mobile attraverso il suo sistema operativo Android basato su Linux. Inoltre, per creare ancora più eccitazione intorno alla sua nuova creazione, Google ha indetto una competizione mondiale con un monte premi di 10 milioni di dollari. Wow! Notiziona! Appena l’ho letto mi sono scaricato subito l’SDK aspettando il weekend per dargli un occhiata approfondita.

Purtroppo, leggo oggi sul blog di Fabrizio Giudici che l’Italia e il Quebec sono gli unici paesi al mondo esclusi da questa competizione a causa di leggi troppo restrittive inerenti la gestione dei concorsi a premio!!!

Quasi quasi scrivo all’indignato speciale!

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).

You scored as a Agnosticismo

Il tuo risultato è… agnostico. Sei un agnostico. Sebbene è generalmente riconosciuto che gli agnostici non credono nell’estistenza di Dio nè nella sua non esistenza, è possibile per un agnostico essere anche deista o ateo. In realtà gli agnostici non conoscono nè pretendono di sapere se Dio esiste o no, ma possono ammettere che qualcun’altro lo sappia. Un agnostico intellettualmente onesto si schiererebbe su questa posizione, dato che non ha più prove per giustificare l’impossibilità di conoscere Dio di quante ne abbia della sua esistenza.

Agnosticismo 95%
Buddismo 70%
Paganesimo 60%
Satanismo 60%
Confucianesimo 55%
Ateismo 45%
Paranormale 45%
Islam 30%
Induismo 30%
Cristianesimo 20%
Ebraismo 0%

Se devo essere sincero, fra tutte, mi sento un po’ più buddista… e mi inquietano un po’ quei due 60% di paganesimo e satanismo…