Imparare dagli Errori del Programmatore

Un buon programmatore evolve mentre lavora ed impara a sapersi comportare nei confronti dei problemi anche quando si accorge di aver sbagliato. Altro aspetto è invece cercare di risolvere il problema sbagliato, perché male spiegato o male interpretato. Ad esempio se un cliente chiede di fare una modifica al programma, è sbagliato cercare di risolvere quel problema senza prima aver chiesto il perché del voler fare quella modifica. Una volta mi è successa una cosa incredibile, ma che mi ha tenuto al telefono con il cliente per un’intera mattinata: il problema era quello di stampare un modulo che il nostro programma gestionale si rifiutava di fare, dava continuamente errore. Non riuscivo a capire cosa mai era successo, mentre da altri clienti e sulla mia copia funzionava a dovere. A fine mattinata mi è venuto in mente di chiedere se magari mancasse la carta o si fosse inceppata e, per caso, chiesi se qualche lucina fosse rossa o arancione. La risposta fu: “Non vedo lucine accese”, chiesi se la stampante fosse accesa e mi venne detto che non lo sapeva, allora chiesi di pigiare sul pulsante di accensione e magicamente la stampa venne compiuta senza problemi di sorta. Questo semplice episodio cosa spiega: comportarsi a seconda della persona che abbiamo di fronte ed al suo grado di conoscenza dell’argomento, più questo valore è basso più fare domande semplici. Ad esempio al momento cerco di evitare come la peste delle personalizzazioni richieste ai miei software fatte da persone che conoscono poco o non conoscono affatto l’informatica, dalla mia esperienza ho dedotto che non conviene, né dal punto di vista economico, né dal punto di vista della salute.
Un errore comune è cercare di eliminare i sintomi e non il vero problema. Ad esempio se una routine ci ritorna un valore doppio rispetto a quello giusto, ci viene più facile e si fa prima a dividere il risultato per 2, invece di perdere molto tempo per aggiustare la routine. Comportamenti di questo genere, oltre a non essere professionali, comportano sicuramente un danno al software e certamente in futuro si andrà decisamente incontro ad altri errori dello stesso tipo e dovremmo sempre ricordarci di dividere per due il risultato della routine incriminata. Mai rilasciare software che riteniamo non maturo, meglio rinviare la data di uscita, ci si guadagna di più in reputazione.
Occorre saper gestire i rischi che si possono avere in un progetto e non farsi mai tentare dal dire “Speriamo che me la cavo”. Ad esempio se abbiamo creato un bel programma che stampa su tutte le stampanti ad aghi, occorre sempre provare cosa succede su delle stampanti a getto d’inchiostro, forse si tratta di un esempio banale, ma rende bene l’idea. Da molte avventure del passato ho capito che non è sempre, se una cosa va bene con una macchina anche con altre macchine simili andrà certamente bene, ora faccio provare i miei software prima dell’acquisto e mai dopo, sia per mantenere una buona reputazione presso i clienti, sia per non avere problemi per il futuro.
Naturalmente l’esperienza è impossibile insegnarla, occorre farla sulla propia pelle, ma credo che, a chi si appresta ad avviare un’attività di consulenza o programmazione informatica aziendale, possano servire alcuni miei esempi degli errori che ho commesso in passato e che mi sono ripromesso di non commettere più. Se volete potete farmi delle domande riguardo a questi argomenti ed io cercherò di dirvi come mi sono comportato e soprattutto il risultato ottenuto in questi lunghi 15 anni di lavoro di programmatore.