Una visione disallineata: dare priorità ai peer rispetto agli utenti

Quante volte hai guardato il codice di qualcuno e hai dichiarato:

Non lo sto usando perché non sembra ben scritto.

E in questo caso, "sembra ben scritto" potrebbe sostituire:

• "guarda come lo scriverei"
• "sembra avere senso per me."

Certo, ci sono momenti in cui l’utilizzo di codice open source è rischioso. Lo sappiamo dai vari software e servizi che si presentano con vulnerabilità. Ma, almeno per questo post, trattali come l’eccezione, non la regola.

Ciò significa che non ci resta che guardare qualcosa che potremmo usare ma che scegliamo di non usare perché non sembra essere scritto in un modo che pensiamo debba essere scritto.

Dare priorità ai peer rispetto agli utenti

Lo sviluppo è complicato perché ci sono diversi compromessi che noi, o un altro sviluppatore, dobbiamo fare ogni volta che stanno costruendo qualcosa.

Guardando dentro e fuori

Dobbiamo considerare:

• vincoli di tempo e di budget,
• quale paradigma ci aiuterà a fornire un solido entro detti vincoli,
• la soluzione finale risolve davvero il problema principale,
• ci saranno costi di manutenzione associati al modo in cui abbiamo messo insieme qualcosa?

E l’elenco potrebbe continuare.

Considerare i vari aspetti dello sviluppo e discutere le filosofie di come qualcosa dovrebbe essere costruito non è affatto raro nel nostro settore

Ma richiede anche molto tempo e potrebbe rivelarsi un esercizio che produce un risultato netto zero perché non ne deriva nulla. (Sì, spesso può essere un’esperienza di apprendimento, ma non sempre.)

Foto di José Alejandro Cuffia su Unsplash

Guardando fuori dentro

In pratica però:

• Il paradigma utilizzato per creare la soluzione ha un impatto sull’utilizzo del software?
• Il software in questione risolve il problema?
• Se non potessi vedere come è stato assemblato il progetto, quale conclusione trarresti sul software?

E l’ultimo punto potrebbe essere il più critico per quanto riguarda il software open source.

Ho lavorato nel settore abbastanza a lungo da sapere che spesso le persone desiderano una soluzione funzionale che risolva i loro problemi e danno per scontato che sia costruita in modo sicuro.

Gli sviluppatori, d’altra parte, esamineranno il codice più della soluzione che fornisce e del problema che risolve.

Se sei uno sviluppatore, c’è assolutamente un tempo e un luogo per entrambi. Ma se lasci che quest’ultimo ti impedisca di spedire il primo, allora potresti non ottenere mai qualcosa che gli altri possano usare perché sei troppo preoccupato per ciò che potrebbero pensare i tuoi colleghi.

E quando stai risolvendo un problema per altre persone, dovrebbero essere loro a contare più dei tuoi coetanei.