I programmatori 10x sono un argomento caldo da discutere nell’industria del software al giorno d’oggi, così ho pensato che sarebbe stata una buona idea condividere il mio punto di vista al riguardo.
In tutta onestà non conosco la definizione esatta di un programmatore 10x, ma presumo che si riferisca a programmatori iper produttivi (che potrebbe non corrispondere esattamente a 10 volte la produttività, ma a un livello significativo vicino o più di 10 volte).
Sulla base di alcuni successi che ho avuto mentre consegnavo pezzi di software ultra-grandi per startup e aziende, e l’esperienza di lavoro con alcuni sviluppatori di alto livello, posso condividere alcune intuizioni su questo argomento.
Il programmatore 10x allora
Il software sviluppato 20-30 anni fa era molto più semplice rispetto al software moderno, per quanto riguarda la funzionalità, sicurezza, prestazioni e scalabilità. D’altra parte, solo una manciata di librerie o framework erano disponibili a quel tempo per implementare qualsiasi funzionalità.
Quindi, il software scritto 20-30 anni fa comportava una quantità significativa di sforzo nella programmazione.
Definire un programmatore 10x in quel contesto è relativamente facile. La differenza tra la quantità di sforzo di programmazione di base dato per implementare lo stesso set di funzionalità da programmatori 10x e normali.
L’ingegnere 10x ora
Prima di entrare in ulteriori dettagli, chiariamo una cosa: lo sviluppo del software è un processo complesso, e la programmazione è solo una delle aree per contribuire al software moderno.
A causa dell’aumento dell’uso del software, specialmente su Internet, sia da parte dei consumatori che delle organizzazioni, il software è molto complesso, e potrebbe essere una decisione folle costruire qualcosa da zero. Onestamente, a meno che non si tratti di una piattaforma o di un sistema operativo completamente nuovi, la programmazione di base richiesta per sviluppare un software moderno è meno intensa rispetto ai vecchi sforzi.
Mentre la conoscenza e lo sforzo di programmazione sono ancora molto importanti, la quantità di sforzo che è richiesta per costruire un grande software (senza bug, sicuro e vendibile) è in ingegneria.
Quindi, nel contesto odierno, un programmatore 10x può non portare molto valore nell’industria, ma un ingegnere 10x crea un impatto molto ampio nel processo di sviluppo.
Vorrei aggiungere i miei 3 centesimi qui.
1. Fanno il miglior uso degli strumenti
Lo sviluppo del software è un processo complesso, che coinvolge un sacco di diversi tipi di sforzo. Oltre alla codifica, comporta sforzi dalla documentazione del processo, alla formattazione dei dati, alla lettura dei dati di log, all’invio di rapporti, ai test automatici, ai test manuali, al debugging complesso, all’investigazione manuale dei problemi, e così via.
Un enorme sforzo può essere reso estremamente efficiente utilizzando il giusto set di strumenti e piattaforme (che sono appropriati al budget del cliente e ad altri vincoli).
Editori
La scrittura di software coinvolge uno o più editor, alcuni dei quali sono anche chiamati IDE (Integrated Development Environment). Gli IDE moderni, come Visual Studio o Eclipse, offrono una grande quantità di funzionalità per rendere gli sviluppatori produttivi, ma una quantità significativa di queste caratteristiche non sono conosciute dalla maggior parte degli sviluppatori.
Gli IDE più popolari hanno anche plugin commerciali e gratuiti (come Resharper), che permettono una produttività ancora maggiore degli sviluppatori.
Oltre agli IDE, anche altri editor come NotePad++, MarkdownPad, ecc. sono molto utili in un contesto rilevante.
Utility e servizi online
Utility e servizi online come la lettura o la ricerca di grandi file di log, debugger http come Fiddler, strumenti di compilazione e distribuzione, ecc.
Strumenti propri
Gli ingegneri 10x creano anche i propri set di strumenti per eseguire azioni ripetitive per le quali il software appropriato potrebbe non essere disponibile esternamente.
In molti casi, i proprietari di una casa di sviluppo software non sembrano essere interessati ad investire molto negli strumenti per gli sviluppatori, ma l’utilizzo del giusto set di strumenti permetterà una sorprendente quantità di produttività.
Per gli sviluppatori di software, che sono alcune delle persone più costose da assumere, vale la pena spendere soldi per gli strumenti giusti per loro.
Come capo di un team di sviluppatori .net, lo sviluppo di un template ASP.NET Core & Visual Studio starter seguendo le ultime pratiche di codifica .net ha aiutato il mio team ad aumentare la produttività complessiva di tre volte.
2. Non reinventano la ruota Non reinventano la ruota
L’industria del software è diventata molto matura negli ultimi tre decenni. Quasi tutti i problemi che gli sviluppatori cercano di risolvere con la codifica sono stati risolti e sono disponibili come API (sia come binari che come servizi web), alcuni dei quali sono commerciali, mentre altri sono gratuiti.
Inoltre, i framework open source forniscono anche una grande flessibilità per capire il comportamento sottostante delle API o la personalizzazione secondo le necessità degli utenti.
Prima di buttarsi nella programmazione, gli ingegneri di 10x si assicurano effettivamente che questo problema non sia stato risolto completamente (o parzialmente) prima o, se è così, non sono disponibili per essere utilizzati.
3. Scrivono (continuamente) codice ben ingegnerizzato
Scrivere un grande software richiede la definizione di una buona architettura che non solo segue buoni design pattern e principi, ma sfrutta anche le infrastrutture moderne. Produrre codice ben ingegnerizzato non solo permette di scrivere nuove funzionalità più velocemente, ma riduce anche i bug in modo significativo.
Ma una bella ingegneria richiede un miglioramento continuo.
Nella mia carriera professionale ho visto una quantità sorprendente di codice di bassa qualità in diversi progetti software, che aggiunge continuamente debito tecnico. Un semplice progetto iniziato 5 anni fa è pieno di codice brutto non ingegnerizzato e richiede più di 20 persone per gestire il ciclo di sviluppo (dove stanno spendendo l’80% del loro tempo a correggere i bug).
Una delle ragioni principali dietro questa terribile situazione, ho scoperto, è la “paura”.
Le organizzazioni, specialmente le entità aziendali, per lo più temono il cambiamento.
Lo sviluppo del software è una disciplina che cambia incredibilmente in fretta in termini di strumenti, framework e ingegneria, e richiede continui cambiamenti per arrivare al punto giusto.
Il cambiamento fa paura, ma non è così pericoloso come sembra, specialmente nell’industria del software (con i giusti set di strumenti e persone). Ma se non viene fatto come previsto, non ci vorrà molto tempo perché il progetto venga un giorno abbandonato del tutto.
Si può fare.