Una delle specializzazioni più sovraffollate da idioti è quella dei manager che gestiscono programmatori. Non tutti, ma quelli che non sono mai stati programmatori in vita loro. Quelli che pensano di poter "aumentare" l'efficienza (o incrementare "l'efficienza"?) con metodi presi dai libri. Senza nemmeno prendersi la briga di leggere quei libri — c'è sempre qualche video, dopotutto.
Quelli che non hanno mai scritto codice. Quelli per cui vengono realizzati film di Hollywood sui programmatori — beh, quelli in cui si controlla la posta elettronica dalla riga di comando. Quelli per cui non c'è nulla di interessante al di fuori delle metriche, delle scadenze e della propria busta paga.
Quelli di cui è fatto la maggior parte.
Ma sono idioti per un'altra ragione. Vogliono l'efficienza, o perlomeno la produttività (dai, manager, cerca su Google qual è la differenza), senza comprendere né l'uno né l'altro. Senza afferrare il succo, il processo di ottenimento del risultato, le perdite che avvengono all'interno di questo processo, i costi per lo sviluppo. Insomma, lavorando con un programmatore, come se fosse una scatola nera.
Si sono fiondati nella gestione dei programmatori esattamente per un motivo: qui c'è hype, denaro, mercato e un sacco di altri idioti come loro. C'è spazio per nascondersi.
Se ci fosse hype nella produzione di assemblaggi meccanici, ci andrebbero di corsa. Universali scarsi. Non mi sorprenderebbe se il tipo che vende alberi di Natale nel nostro quartiere a dicembre fosse un manager IT in ferie.
Insomma, se avete l'opportunità, cacciate questi ragazzi via. Non preoccupatevi, troveranno un lavoro. Nessuno di loro, mai, farà nulla di decente finché non diventerà programmatori. Perché non comprende la sostanza, il meccanismo, la logica del processo che gestisce.
Basta, ho terminato di parlare dei manager. Ora parliamo al sodo, per i programmatori. Come aumentare l'efficienza dello sviluppo imparando a scrivere codice di qualità.
Per aumentare l'efficienza, è necessario risolvere più rapidamente i problemi, senza perdere qualità. Per risolvere i problemi più rapidamente, bisogna saper scrivere codice di qualità fin da subito. E "di qualità", "scrivere", e "subito". Spiegherò con una metafora.
Scrivere codice di qualità è come parlare fluentemente una lingua straniera. Quando non conosci la lingua, perdi un sacco di tempo a formulare i tuoi pensieri.
Se devi dire qualcosa rapidamente, semplicemente attacchi alcune parole, spesso non quelle che servono, dimentichi gli articoli, l'ordine corretto delle parole, per non parlare dei tempi verbali e della scarsa pronuncia.
Se c'è tempo per formulare una risposta, si dovrà aprire un dizionario o un traduttore online, e spendere un sacco di tempo per formulare i propri pensieri. La sensazione, però, sarà comunque sgradevole: dici la risposta e non sai se sia giusta o meno. È lo stesso con il codice: sembra scritto bene, sembra funzionare, ma è di qualità oppure no – chissà.
Così si ottiene una doppia perdita di tempo. Servono tempo per pensare alla risposta, e tempo per formulare quella risposta – e non è poco.
Se invece si ha la competenza di scrivere codice di qualità, si può formulare la risposta immediatamente, non appena è matura nella mente, senza spendere ulteriore tempo per la traduzione.
La competenza di scrivere codice di qualità aiuta nella progettazione dell'architettura. Semplicemente non si prenderanno in considerazione nella mente opzioni sbagliate, irrealizzabili o poco pratiche.
In sintesi: la competenza di scrivere codice di qualità accelera notevolmente la risoluzione dei problemi.
Ma non è tutto. Grazie ai manager inesperti, c'è un problema: in effetti non abbiamo motivi per scrivere codice di qualità. I manager non guardano il codice, i clienti non guardano il codice. Ci mostriamo il codice di rado, solo a volte, in alcuni progetti, dove c'è un "revisore" del codice o un rifattorizzazione periodica.
Così, nella maggior parte dei casi, codice scadente finisce in produzione o al cliente. Per la persona che ha scritto quel codice scadente si forma una connessione neurale stabile: scrivere codice scadente non è solo permesso, ma è necessario – viene accettato e, anzi, ci pagano anche per questo.
Di conseguenza, la competenza di scrivere codice di qualità non ha affatto possibilità di svilupparsi. Il codice scritto da un ipotetico dipendente non viene mai controllato da nessuno. L'unico motivo per cui può imparare a programmare decentemente è la motivazione interna.
Ma questa motivazione interna è in contrasto con i piani e le richieste di efficienza e produttività. Questo contrasto non si risolve chiaramente a favore del codice di qualità, poiché per il codice scadente non vengono nemmeno ripresi. Ma per il mancato raggiungimento del piano, invece, sì.
Come procedere? Vedo e propongo due strade, che possono essere combinate.
La prima è mostrare il proprio codice a qualcuno all'interno dell'azienda. Non reattivamente (quando richiesto / costretti), ma proattivamente (ehi, guarda il mio codice, per favore). Qui l'importante è non aggiungere zuccheri, non cercare di mascherare le critiche al codice in forme educate. Se il codice fa schifo, lo diciamo così: il codice fa schifo. Con spiegazioni, naturalmente, e raccomandazioni su come migliorarlo.
Ma anche questo percorso ha i suoi limiti. La sua applicabilità dipende dal punto in cui è avvenuto il contatto. Se il lavoro è già andato in produzione e si è scoperto che il codice fa schifo, riscriverlo non ha più senso. Anzi, il motivo — anche le metriche scenderanno. I manager si faranno avanti e opprimeranno con richieste di efficienza. E nemmeno provare a spiegare loro che il codice di merda tornerà certamente sotto forma di bug — finirai nei guai. Si può solo prendere l'impegno di non farlo più.
Se però il lavoro non è ancora stato consegnato, o è appena iniziato, allora criticare il codice (o il suo progetto, l'idea) può avere un senso pratico — la persona potrebbe farlo bene.
La seconda strada, la più interessante, è dedicarsi allo sviluppo open source nel tempo libero. L'obiettivo è: far sì che un sacco di programmatori, proprio programmatori, vedano il tuo codice e diano un giudizio. All'interno dell'azienda a tutti manca il tempo. E ai programmatori di tutto il mondo non è poi così difficile trovare qualcosa da fare, e se scrivi qualcosa di utile dal punto di vista pratico, sicuramente daranno un'occhiata.
La cosa principale, dal mio punto di vista, è scrivere codice nel tempo libero, perché non ci sarà contraddizione tra la qualità del codice e la velocità di consegna del risultato. Puoi dedicarti alla tua creazione per un anno. Non avrai pressioni da scadenze, requisiti, soldi o superiori. Libertà totale e creatività.
Solo nella libera creatività capirai e sentirai cosa significhi avere un codice fantastico, vedrai la bellezza dei linguaggi di programmazione e delle tecnologie, assaporerai il piacere delle sfide aziendali. E imparerai a scrivere codice di qualità.
Certo, ciò richiederà un investimento di tempo personale. Come del resto qualsiasi altro tipo di sviluppo. Consideralo non come una spesa, ma come un investimento — in te stesso.
Fonte: habr.com
