Una delle professioni più sovraccariche di idioti è quella dei manager che gestiscono programmatori. Non tutti, ma quelli che non sono stati programmatori in vita loro. Quelli che pensano di poter "aumentare" l'efficienza (o aumentare "l'efficacia"?) con metodi presi dai libri. Senza neanche prendersi la briga di leggere quei libri, perché ci sono i video, dopo tutto.
Coloro che non hanno mai scritto codice. Quelli per cui si girano film hollywoodiani sui programmatori — beh, quelli in cui si guarda la posta elettronica tramite la riga di comando. Quelli a cui non interessa nulla, tranne che dei risultati, delle scadenze e del proprio stipendio.
Quelli di cui parla la maggior parte.
Ma sono idioti per un altro motivo. Vogliono efficienza, o almeno produttività (dai, manager, cerca su Google qual è la differenza), senza capire né l'uno né l'altro. Non comprendendo affatto la sostanza, il processo di ottenimento del risultato, le perdite che avvengono in questo processo, i costi per lo sviluppo. In breve, lavorano con il programmatore come se fosse una scatola nera.
Sono accorsi alla gestione dei programmatori per una sola ragione: qui ci sono hype, soldi, mercato e un sacco di idioti come loro. Ci sono posti dove nascondersi.
Se ci fosse entusiasmo nella produzione meccanica, ci andrebbero. Universali scarsi. Non mi sorprenderebbe che il tizio che vende alberi di Natale nel nostro quartiere a dicembre sia un manager IT in ferie.
Insomma, se c'è la possibilità, scacciate quei ragazzi. Non preoccupatevi, troveranno un lavoro. Nessuno di loro farà mai nulla di decente finché non diventerà programmatore. Perché non capisce la sostanza, il meccanismo, la logica del processo che gestisce.
Basta parlare di manager. Ora veniamo al punto, per i programmatori. Come aumentare l'efficienza dello sviluppo imparando a scrivere codice di qualità.
Per aumentare l'efficienza, bisogna risolvere i problemi più rapidamente senza perdere qualità. Per risolvere i problemi più rapidamente, è necessario saper scrivere codice di qualità fin da subito. E "qualità", "scrivere", e "subito". Spiegherò con una metafora.
Scrivere codice di qualità è come parlare correttamente una lingua straniera. Quando non conosci la lingua, perdi un sacco di tempo per formulare i tuoi pensieri.
Se devi dire qualcosa in fretta, attacchi delle parole a caso, spesso non quelle giuste, dimenticando articoli, l'ordine corretto delle parole, per non parlare dei tempi verbali e di una pronuncia scadente.
Se hai tempo per formulare una risposta, dovrai aprire un dizionario o un traduttore online, spendendo molto tempo per esprimere i tuoi pensieri. La sensazione, comunque, sarà spiacevole: rispondi e non sai se è corretto o meno. Lo stesso vale per il codice: sembra scritto bene, sembra funzionare, ma chissà se sia di buona qualità.
Risulta quindi una doppia perdita di tempo. Ci vuole tempo per pensare a una risposta. Anche formolarla richiede tempo — e non poco.
Se invece possiedi la competenza nella scrittura di codice di qualità, puoi formulare la risposta non appena essa è chiara nella tua mente, senza spendere ulteriore tempo per la traduzione.
La competenza nella scrittura di codice di qualità aiuta nella progettazione dell'architettura. Non penserai nemmeno a opzioni sbagliate, irrealizzabili o mal concepite.
In sintesi: la capacità di scrivere codice di qualità accelera notevolmente la risoluzione dei problemi.
E non è tutto. Grazie ai cosiddetti manager, c'è un problema: non abbiamo motivo di scrivere codice di qualità. Né il manager né il cliente guardano il codice. Ci mostriamo il codice solo raramente, solo in alcuni progetti dove è stato nominato un "verificatore" del codice o durante un rifactoring periodico.
Quindi, nella maggior parte dei casi, codice brutto finisce in produzione o viene consegnato al cliente. La persona che ha scritto codice brutto sviluppa una connessione neurale stabile: non solo è possibile scrivere codice brutto, ma è anche necessario – viene accettato e, in più, vengono pagati per questo.
Alla fine, non c'è alcuna possibilità che la capacità di scrivere codice di qualità si sviluppi. Il codice scritto da un dipendente qualsiasi non viene controllato da nessuno e mai. L'unico motivo per cui potrebbe imparare a programmare correttamente è la motivazione interna.
Ma questa motivazione interna è in contrasto con i piani e le esigenze di efficacia e produttività. Questo contrasto non viene risolto a favore di un codice di qualità, dato che nessuno viene rimproverato per scrivere codice scadente. E per il mancato raggiungimento degli obiettivi, invece, eccome.
Cosa fare? Vedo e propongo due vie, che possono essere combinate.
La prima è mostrare il proprio codice a qualcuno all'interno dell'azienda. Non in modo reattivo (quando viene richiesto/impedito), ma proattivamente (ehi, guarda il mio codice, per favore). Qui la cosa principale è non addolcire la critica, non cercare di mascherarla con forme cortesi. Se il codice fa schifo, lo diciamo chiaramente: il codice fa schifo. Ovviamente con spiegazioni e suggerimenti su come migliorarlo.
Ma anche questo approccio ha le sue limitazioni. La sua applicabilità dipende dal momento in cui si è verificato il contatto. Se il lavoro è già in produzione e si scopre che il codice è di scarsa qualità, non ha senso modificarlo. Anzi, ci sarebbero anche motivi validi per non farlo: le metriche ne risentirebbero. I manager arriverebbero e bombarderebbero di richieste relative all'efficienza. E non provare nemmeno a spiegare che un codice di qualità scadente porterà sicuramente a bug — sarà a tuo svantaggio. L'unica cosa che puoi fare è impegnarti a non ripetere più questa situazione.
Se il lavoro non è ancora stato consegnato, o è appena iniziato, criticare il codice (o il progetto, l'idea) può avere un reale senso pratico – la persona farà un buon lavoro.
Il secondo approccio, il più efficace, è dedicarsi allo sviluppo open source nel tempo libero. La vera sfida è far sì che un numero consistente di programmatori, proprio programmatori, veda il tuo codice e esprima il proprio parere. All'interno dell'azienda nessuno ha tempo. Ma i programmatori di tutto il mondo non hanno nulla da fare, e se scrivi qualcosa di utile dal punto di vista pratico, sicuramente saranno curiosi di dare un'occhiata.
La cosa principale, a mio avviso, è scrivere codice durante il tempo libero, perché non ci sarà contrasto tra la qualità del codice e la velocità di consegna. Puoi lavorare al tuo progetto per un anno. Non sarai schiacciato da scadenze, requisiti, soldi o capi. Completa libertà e creatività.
Solo nella creatività libera puoi comprendere e sentire cosa significhi un codice fantastico, vedere la bellezza dei linguaggi di programmazione e delle tecnologie, e percepire il fascino delle sfide aziendali. E imparerai a scrivere codice di qualità.
Naturalmente, questo richiederà un investimento di tempo personale. Come qualsiasi altra forma di crescita. Consideralo non come una spesa, ma come un investimento in te stesso.
Fonte: habr.com
