Come Riconoscere un Buon Programmatore

Mi càpita abbastanza spesso che mi venga chiesto di valutare un programmatore (o, per essere più precisi, un ingegnere del software) e quindi mi càpita spesso di leggere articoli su questo tema. Francamente, gli articoli che ho letto finora sono quasi tutti dei veri mucchi di cazzate. Tutti, tranne uno:

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

In questo articolo di Daniel Tenner c’è molta più sana informazione e molto più buon senso che in interi bancali di “fuffa” prodotta dagli analisti del settore. Vi consiglio caldamente di leggerlo.

Tra le altre cose, Tenner fornisce una mezza dozzina di indicatori che permettono di capire se la persona che vi sta di fronte è un “buon programmatore” o meno. Per quanto mi riguarda, arriverei persino a dire che (mutatis mutandis) questi indicatori possono aiutarvi a capire se la persona che vi trovate di fronte è una persona intelligente o meno, al di là della professione che svolge.

In breve…

Questi che seguono sono gli indicatori in questione. Li ho tradotti in italiano dal sito che ho già citato, senza aggiungere e senza togliere nulla.

Indicatori positivi

  1. Hanno una evidente passione per la tecnologia.
  2. Vivono la programmazione come un hobby.
  3. Se incoraggiati, vi parleranno di un qualunque argomento tecnico fino a sfinirvi.
  4. Spesso possono vantare numerosi progetti personali (alcuni dei quali spesso sono di una certa rilevanza) che hanno sviluppato nel corso degli anni.
  5. Studiano nuove tecnologie per conto proprio.
  6. Hanno una opinione precisa riguardo a quali siano le tecnologie più adatte per questa o quella applicazione.
  7. Sono molto a disagio di fronte all’idea di lavorare con qualche tecnologia che non ritengano adatta allo scopo.
  8. Chiaramente intelligenti, possono sostenere una conversazione su una grande quantità di argomenti diversi tra loro.
  9. Hanno iniziato a programmare molto tempo prima di arrivare all’università od al lavoro.
  10. Portano avanti qualche grosso progetto personale che non appare sul curriculum.
  11. Conoscono una grande quantità di tecnologie non correlate tra loro e non è detto che questa loro conoscenza risulti dal curriculum.

Indicatori negativi

  1. Vivono la programmazione come lavoro.
  2. Non amano avventurarsi in discussioni tecniche sui prodotti e le tecnologie, come quelle che si svolgono spesso davanti alle vetrine dei negozi, nemmeno se vengono incoraggiati a farlo.
  3. Studiano nuove tecnologie grazie ai corsi aziendali.
  4. Vi dicono che sono a loro agio con qualunque tecnologia voi decidiate di usare. Per loro, tutte le tecnologie sono buone.
  5. Non sembrano particolarmente svegli.
  6. Hanno iniziato a programmare all’università.
  7. Tutta la loro esperienza di programmatori è diligentemente elencata nel curriculum.
  8. Si specializzano in una o due tecnologie (per esempio java server-side) e non hanno nessuna esperienza al di fuori di quei settori.

Se desiderate approfondire l’argomento, qui di seguito trovate una mia personalissima analisi di alcuni di questi indicatori (non tutti). Prima, però, credo che sia necessario chiarire un punto fondamentale.

Manovali e Consulenti

Nella stragrande maggioranza dei casi, il ruolo dell’imprenditore e quello del lavoratore sono chiaramente distinti e facilmente riconoscibili. L’imprenditore (un tempo noto come “capitalista”) ci mette l’idea ed i soldi ed i lavoratori (qualunque sia il loro livello di istruzione ed il loro ruolo aziendale) si limitano a svolgere il lavoro di realizzazione materiale dell’opera. L’ingegnere progetta il ponte e gli operai lo costruiscono. L’idea di costruire il ponte, dove costruirlo e come costruirlo sono decisioni che deve comunque prendere l’imprenditore, anche se viene consigliato dai suoi tecnici. Nell’industria tradizionale, persino l’ingegnere di più alto livello spesso ha un’autonomia decisionale molto limitata.

Il mondo del software NON funziona così.

Il software è un unico, immenso, complicatissimo aggregato di DECISIONI, scolpite nel codice che viene eseguito. Non esiste una fase di “produzione” del software, distinta da quella di progettazione. Non è tecnicamente possibile progettare un programma a tavolino con un livello di dettaglio sufficiente a deresponsabilizzare gli “operai” nella stessa misura a cui si è abituati nell’industria tradizionale. Se si arrivasse ad un progetto così dettagliato, quel progetto sarebbe il programma stesso, finito e pronto a funzionare. Nel mondo del software, le fasi classiche dell’ingegneria (R&D, Design, Testing, Production , Distribution e Maintenance) risultano quasi sempre così tanto sovrapposte le une alle altre da dare vita ad un unica fase.

Questa banale constatazione è alla base del successo delle varie metodologie di sviluppo “agile”, dove non esiste, di fatto, una reale cesura tra le fasi di progettazione, di implementazione, di testing e di distribuzione. Ogni cosa viene gestita e realizzata dalle stesse due o tre persone che lavorano gomito a gomito sullo stesso frammento di codice, “iterando” su di esso infinite volte, fino a giungere ad un risultato soddisfacente. Si tratta, in pratica, di un processo di sviluppo per approssimazioni successive, o persino per tentativi ed errori, nel quale la fase di R&D e quella di produzione sono completamente fuse tra loro. Si impara cosa si deve produrre mentre lo si produce, sulla base dei risultati intermedi.

Durante questa unica, gigantesca, fase di “sviluppo”, suddivisa in una serie infinita di iterazioni, vengono essere prese infinite decisioni, piccole e grandi, che non hanno a che fare solo con dei dettagli tecnici. Si tratta di decisioni che riguardano anche l’interazione con l’utente, il posizionamento del prodotto sul mercato, il meccanismo di distribuzione ed i criteri di qualità e di assistenza al cliente. In altri termini, le persone che implementano il codice devono necessariamente prendere una enorme quantità di decisioni che nell’industria tradizionale sarebbero affidate all’imprenditore ed ai suoi consulenti di più alto livello.

Questo vuol dire che, come imprenditori, NON avrete bisogno di ingegneri e di operai che diano vita alle vostre idee. Avrete bisogno di consulenti che siano in grado di condividere le vostre responsabilità decisionali, le vostre idee e la vostra passione. Non avrete bisogno di manovali che si presentano sul luogo di lavoro alle 8 e se ne vanno alle 17, qualunque cosa sia successa nel frattempo. Avrete bisogno di compagni di ventura che siano pronti (e determinati) a seguirvi all’inferno se sarà necessario. Che ci crediate o no, lo sviluppo software assomiglia molto di più ad una guerra che ad un’impresa ingegneristica e, come tutte le guerre, richiede dei leader molto più carismatici di quelli che potreste trovare nell’open office di una compagnia di assicurazioni.

La ragione per cui molti progetti software falliscono è proprio questa: l’imprenditore che ha dato vita all’idea e l’ha finanziata non è stato in grado di raccogliere attorno a sé persone adeguatamente competenti e motivate e/o non ha saputo delegare loro le responsabilità decisionali necessarie. Quasi sempre, la ragione di questo fallimento è la mancanza di leadership dell’imprenditore. Come potete facilmente capire, nessun “compagno di ventura” competente e motivato sarà disposto a seguire all’inferno un leader (un imprenditore) che non sia almeno intelligente, competente e visionario quanto lui. Non sarà nemmeno disposto a seguire all’inferno una persona che non sia disposta a condividere gli onori e le responsabilità dell’impresa, oltre alla fatica ed agli oneri.

In altri termini, l’industria del software è una delle rarissime industrie dove non è tecnicamente possibile imporre le proprie decisioni, la propria persona e la propria autorità ai propri dipendenti. Se non siete in grado di capire questo, francamente è meglio che vi dedichiate ad altro.

Autoformazione e passione per l’apprendimento

Quasi tutte le discipline di una certa complessità possono essere imparate ma NON possono essere insegnate.

Vi sembra assurdo? Pensate per un attimo al vostro hobby preferito, od all’attività che amate di più. Potrebbe essere la pesca o la navigazione a vela, non ha importanza. Come avete imparato? E, domanda molto più impegnativa, come insegnereste questa vostra disciplina a vostro figlio?

Come potete vedere, basta un attimo di riflessione per capire che dietro qualunque disciplina di una certa complessità c’è un 10% di “insegnamento”, cioè di fatica che ha fatto qualche professore durante le lezioni, e c’è poi un 90%“apprendimento”, cioè di fatica che deve necessariamente fare l’allievo, da solo, chino sui libri o nel silenzio di un laboratorio.

Questo vale per qualunque disciplina che meriti un corso di laurea universitario, come la medicina o, appunto, l’informatica.

Cosa ancora più grave, questo aspetto della trasmissione del sapere diventa ingestibile quando si è costretti a fare i conti con il tempo ed i soldi. Naturalmente, è sempre possibile organizzare un corso di lezioni e di esperienze di laboratorio che accetti all’ingresso un ragazzino di 15 anni, completamente “amorfo” e, dieci anni dopo, restituisca in uscita un provetto medico od un provetto programmatore di 25 anni, pronto per il mercato del lavoro. Per farlo, però, sarebbe necessario che l’allievo vivesse per quei dieci anni sempre all’interno della struttura accademica, 24 ore al giorno, 365 giorni all’anno, e che fosse disposto a pagare i migliori professori per questo loro impegno. Diciamo che un corso del genere (che effettivamente esiste, in USA ed in altri paesi) potrebbe costare tra i 100.000 ed i 200.000 € complessivi.

Quale genitore, anche disponendo di questa cifra, sarebbe disposto ad investirla su un ragazzino di 15 anni che potrebbe benissimo scoprire a metà corso di voler fare tutt’altro nella vita? Chi potrebbe mai convincere i migliori professori a farsi carico di questi allievi a rischio di abbandono? Chi potrebbe mai dare le garanzie necessarie sulla motivazione dell’allievo?

L’Oriente ha affrontato questo problema alla radice. I ragazzini che vogliono imparare qualcosa fanno la coda per anni per essere ammessi in un monastero buddista o zen, come il mitico Shaolin. Una volta ammessi, si trasformano in vero monaci. Vivono all’interno del monastero, lavorano per il monastero e studiano 24 ore al giorno, 365 giorni all’anno. In altri termini, votano la propria intera esistenza all’attività che li interessa. Diventano una cosa sola con il loro lavoro.

In Occidente, però, queste cose non si possono fare, almeno non per creare un programmatore. Per questo è inevitabile che ci sia una pesantissima selezione naturale: solo quei programmatori che sanno darsi da soli la formazione necessaria riescono ad entrare nell’Olimpo. Gli altri, al massimo, imparano il Visual Basic.

Per questa stessa ragione, è necessario iniziare molto, molto presto a programmare per poter arrivare ad un livello accettabile. Di fatto, se vostro figlio non ha già scritto il primo programma funzionante (a linea di comando, senza interfaccia grafica) alle medie, è meglio che alle superiori ed all’università si tenga accuratamente alla larga dall’informatica. Per una ragione analoga, se vostro figlio non si è dimostrato in grado di leggere un manuale od un libro di programmazione in INGLESE prima del secondo anno delle superiori, è meglio che si dedichi ad altro.

Intelligenza

Da quanto ho appena detto, ne consegue direttamente che non tutti possono affrontare questo mestiere. La pura e semplice programmazione (“coding”) richiede già un vasto e complesso insieme di competenze tecniche (saper maneggiare il PC, conoscere l’inglese, etc.) e di capacità personali (astrazione, organizzazione nello studio, etc.). Purtroppo, però, il coding è solo la parte “manuale” di un’attività professionale molto più complessa che richiede ben altre competenze e ben altre capacità. Ad esempio, è necessario avere “visione del futuro” e sapersi scegliere i “percorsi di carriera” e le tecnologie più promettenti.

In altri termini, un buon programmatore deve per forza di cose essere una persona “intelligente” (o “sveglia”, se preferite). Deve essere in grado di apprendere velocemente ma soprattutto, deve essere capace di decidere cosa studiare.

Varietà di conoscenze e di esperienze

La forza motrice delle persone intelligenti è quasi sempre la curiosità. Per le ragioni che ho già spiegato, i programmatori sono solitamente persone molto intelligenti e quindi c’è da aspettarsi che siano curiosi, molto curiosi.

In realtà, non avete idea di quanto riescano ad esserlo.

Ho conosciuto molti programmatori di medio livello che nel corso dell’anno precedente hanno studiato ed utilizzato da 6 a 12 nuove tecnologie completamente prive di correlazione l’una con l’altra. C’è chi si lascia affascinare per una quindicina di giorni da Flex, per un week-end da LUA, per un mese da Tapestry e poi compra una macchina fotografica digitale e passa un paio di week-end studiando Adobe Illustrator. Magari durante le vacanze estive prova a farsi il suo linguaggio di programmazione personale con Lex eYacc o con Antlr e durante le vacanze invernali si diletta di processing audio con Audacity. Altri sono più variegati. C’è chi ha la moto e si occupa personalmente della manutenzione e chi segue corsi di volo. Un mio collega si è costruito un ULM in garage.

Insomma, in questo ambiente è normale avere a che fare con persone che dominano con una certa sicurezza molti diversi ambiti dell’ingegneria del software, dell’ingegneria in genere e, più in generale ancora, della conoscenza intesa in senso lato. Questa varietà di interessi e di conoscenze è sia un prerequisito che un effetto collaterale di questa professione. Sarebbe difficile capire il “dominio applicativo” di molti programmi che si è chiamati a scrivere senza avere una esperienza così vasta e variegata del mondo circostante e, d’altra parte, sarebbe difficile trattenersi dallo studiare le cose con cui si entra in contatto. In fondo, questa ricchezza di stimoli è ciò che rende unica questa professione.

Conclusioni

È tutto. Spero che l’articolo originale in inglese di Daniel Tenner e questo mio piccolo contributo vi possano aiutare a capire meglio questo ambiente e la strana fauna che lo popola.

Alessandro Bottoni

Comments
10 Responses to “Come Riconoscere un Buon Programmatore”
  1. henomis scrive:

    Molto, molto interessante. Concordo pienamente sui vari aspetti ed aggiungerei fra gli indicatori positivi:
    12. Non fa uso di buzzword (“profescional”, “enterpraise”, ecc.) ;)

    Grazie per la traduzione.

  2. Gua78 scrive:

    Salte parole e basta!

  3. psykopear scrive:

    Bell’articolo, era un pò che non tornavo su questo blog, felice che tu abbia riniziato a scrivere con una certa frequenza

  4. Maurizio scrive:

    Ottimo articolo. Io aggiungerei tra le caratteristiche a favore la curiosità.
    Ovviamente non la curiosità per le sole cose tecniche, ma riguardo al funzionamento di tutte le cose, i meccanismi, i processi e le organizzazioni.
    Quella curiosità che ti spinge da piccolo a smontare le sveglie per capire come si muovono le lancette (non importa se poi, quando le rimonti, avanza qualche pezzo ;-) )

    Bene o male, un programmatore tende a lavorare per risolvere i problemi degli altri, e se non è curioso di capire come funzionano questi problemi, non può essere in grado di mapparli correttamente in un sistema informatico.

    Maurizio

  5. Fabrizio scrive:

    Parole sante, purtroppo spesso chi è deputato a fare colloqui a un programmatore non è a sua volta un buon programmatore.
    Lavoro nel campo dal 1986, ho cambiato più volte lavoro e i buoni programmatori che ho incontrato stanno in una mano.

  6. Giuseppe Lanzi scrive:

    Mi fa piacere il pingback rapidissimo, volevo segnalare il mio post ma la riunione della mattina mi ha preso un po’ troppo tempo.
    Generalmente sono d’accordo e aggiungerei anche un paio di requisiti: capacità al lavoro di squadra e buon senso. Non credo invece che un programmatore con tutte quelle caratteristiche sia soltanto “buono”, e non credo che per essere bravo occorra necessariamente averle tutte.

  7. Roger Giuffre scrive:

    Esistono anche le categorie di bravi sviluppatori che avendo capito l’andazzo , cominciano a rompersi i maroni di lavorare solo per il business altrui…..

Trackbacks
Check out what others are saying...
  1. […] è capitato di leggere un articolo di Alessandro Bottoni intitolato Come riconoscere un buon programmatore, e ho trovato qualcosa su cui riflettere. L’articolo è ispirato a sua volta da How to […]

  2. […] Come riconoscere un buon programmatore […]



Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: