Salta al contenuto principale
Il blog si è trasferito. Questa è una pagina non più aggiornata. Grazie!
  1. Blog/

Forma, qualità e funzione: la ricerca del punto debole

·372 parole·2 minuti

Ho programmato codice per tanti anni, poi ho smesso, come con le sigarette. Ora fumo qualche sigaro di tanto in tanto, e quando ne capita l’occasione mi faccio di bash scripting. Non ne sento la dipendenza ma sporadicamente un costrutto, un array o un if concatenato aiutano a migliorare il mio stato psico-fisico, a soddisfare la mia assuefazione nerd. Una tiratina di shell e via, la dose giusta per non ricadere nell’abitudine. Un po’ di confusione, poi mi sento meglio di prima.

Quando mi avvelenavo in  Monokai l’alterazione mi portava in uno stato sensoriale in grado di aiutarmi a puntare solamente a due obiettivi e a scansare qualsiasi altro elemento di realtà: il miglioramento formale, qualitativo e funzionale del codice che scrivevo e la riduzione al minimo di bug. Era una fissazione. Non ne uscivo. Era un complesso che si è trasformato in una caratteristica di lavoro e di cura della mia produttività. Forma, funzione, qualità e correzione degli errori. Il regalo della mia ex vita da editor-dipendente.

E allora succede ancora oggi, nonostante usi un font a spaziatura variabile e un documento di testo bianco come la neve, che la fisima prevalga sul raziocinio, che la ricerca di errori di progettazione o di produzione prevalga sulla parata delle conseguenze positive del nostro apporto al business di un partner. Succede che in tempo di bilanci, di attività svolte, di risultati ottenuti, di approcci migliorati, di vantaggi conseguiti, di propositi da raggiungere, succede che l’analisi dei pro viene soggiogata dalla denuncia dei contro, dal punto debole, dal tallone da rivestire, magari con una suola in metallo antitaglio.

Ci riflettevo in questo periodo di report: è funzionale ad un lavoro di consulenza narcotizzarsi con i soli benefici che ha fruttato un rapporto di partnership o è necessario, in trasparenza e franchezza, stordirsi anche dei difetti di produzione, chiunque ne sia il responsabile — anche e soprattutto quando il responsabile è il cliente?

Si può anche andare in overdose di reputazione, ma non si potranno mai raggiungere traguardi formali, qualitativi e funzionali di un progetto se, in maniera chiara, comprensibile e lucida non si analizzano tutti i lati negativi, anche quando il comando che ti manda in crash il sistema lo ha bucato il cliente.