Negare che l’ingegnere informatico sia un programmatore è uno dei miei sport preferiti dopo il calcio, il calcetto a 5 e la lettura di saggi difficili da leggere: una cosa che ho sempre sostenuto con forza anche a costo di essere tacciato di “negazionismo”. Non che non possa farlo per necessità, ovviamente, ma non è la mansione per cui dovrebbe essere pagato. Questo vale soprattutto – ed è bene specificarlo prima che mi si fiondino addosso frotte di professionisti risentiti – per il caso in cui l’ingegnere lavori a partita IVA (qualora faccia il dipendente c’è poco da discutere in merito, probabilmente, dato che fai quello che serve e tanto basta, incluse mansioni che non sarebbero nemmeno le tue).

Nella realtà in cui viviamo, in effetti, dire che l’ingegnere informatico è una figura professionale diversa da quella del programmatore sembra quasi una follia, un controsenso, e si scontra con il fintotontismo di molti commerciali e di alcuni imprenditori (o presunti tali, in alcuni casi) che ti guardano straniti, come se avessi bestemmiato in chiesa.

Da quando faccio questo mestiere, in effetti, mi chiedono un parere, promettono paghe profumatissime (che poi non sempre arrivano, in effetti), e alla fine mi ritrovo spesso a dovermi sbattere tra righe di codice scritte da altri che non funzionano, a contatto con ex dipendenti di turno col dente avvelenato – che se osi chiedere come abbiano fatto X ti si rivoltano contro, rendendo la figura dell’ingegnere più simile, ironicamente, a quella di uno psicologo aziendale. Questi scenari sono purtroppo figli di incapacità cronica di comunicare, ma sono anche dovuti al fatto che i budget erano talmente miseri da provocare frustrazioni a chiunque avesse avuto a che fare con quel progetto.

Rage against the code monkeys

Buona parte delle realtà aziendali che ho conosciuto pensava – ed è lecito, per certa misura – di avere idee buone, ottime, eccellenti o straordinarie (raramente rivedibili o da affinare): e per concretizzare questa idea, dicevano, gli servono le competenze di qualcuno “bravo col computer”. Queste realtà stanno cercando quelle che, nel gergo informatico, vengono chiamate code monkeys (scimmie da codice): semplicemente, gente che scrive codice su indicazioni del cliente. Questo approccio, a parte essere poco convenzionale e formalmente poco valido, è disastroso nel lungo periodo: il cliente non possiede i formalismi che dovrebbe avere un project manager, non c’è alcun filtro tra cliente e scimmia da codice, si assume in altri termini che se le cose vanno bene è merito del cliente e se, malauguratamente, andassero male è colpa della scimmietta che ha programmato.

La critica che sto esprimendo è sostanziale, in altri termini: non è solo questione di puntiglio, È questione che tu mica un ingegnere devo programmare basta l’aspetto legato alla qualità del software su cui l’ingegnere comunque è generalmente competente verrà totalmente offuscato, magari nomi dei direttori commerciali e boss che privilegiano la soddisfazione del cliente e tendono ad appiattirsi sulle sue richieste. Anche quando le richieste non hanno senso o sono poco efficienti, questo è il punto chiave da comprendere.

È forse lo scenario più comune in assoluto, nella mia piccola esperienza, ed è la “molla” che mi ha spinto con più forza a rinnegare il mio ruolo di programmatore “puro” inteso in questi termini. Nelle consulenze che faccio, infatti, non mi limito a stare lì ad accontentare il cliente (che è una ulteriore arma a doppio taglio, come dicevo anche qualche tempo fa); ragiono con lui sulle cose, per dirla da piccolo megalomane in erba offro la mia vision, per usare un termine parecchio in voga – e “offro” è un modo garbato per dire che “impongo“. Se non lo facesso, sarei una code monkey come ce ne sono troppe, e l’ecosistema informatico ne risentirebbe (abbiamo problemi di surriscaldamento globale anche nell’IT, e ci sono negazionisti belli convinti anche in questa sede).

Purtroppo, in molti casi, manca proprio l’umiltà di mettere in discussione le proprie idee e consentire ad un consulente di migliorarle. Questo, secondo me, è il vero problema.

Se lavori sul web, questo vale in misura sostanziale

Come saprete ho un ruolo consolidato di SEO tecnico freelance, e fatico molto ad affermare la mia insolita posizione. Con alcuni clienti con cui sono in buonissimi rapporti, peraltro, non c’è problema: a forza di ribadirlo e di spiegarlo, hanno capito e condividono la mia posizione. Poi sulla SEO (che ormai fanno tutti, pure all’uscita del supermercato te la propongono) si aprirebbe un discorso indefinito e senza limiti, e vale la pena approfondire. La SEO è per buona parte tecnica (anche piuttosto avanzata: devi saperne di PHP, Javascript, MySQL, tempi di caricamento delle pagine, funzionamento della nuova Search Console, codici restituiti dal server, errori lato client e lato server, interpretazione degli analytics di Google, configurazione Apache / htaccess ed nginx, e via dicendo), ma c’è in tutto questo anche una buona componente di comunicazione: devo riuscire a rendere quella parte così astrusa comprensibile al cliente medio.

La scimmia da codice, per definizione, non comunica: scrive codice. Ed è un controsenso pensare che un ingegnere informatico sia un programmatore,  unpo’ per lo stesso motivo per cui è semplicemente fuori dal mondo pensarlo di un SEO. Se avete visto il film The Social Network, ricorderete quando Zuckerberg cambia città e si rintana in una nuova casa a ideare aggiornamenti per il suo Facebook.com. In quella sequenza fa pressing e ribadisce al proprio collaboratore (quasi certamente sottopagato, oserei scrivere) qualcosa tipo “tu pensa a programmare“: nel frattempo, è in corso un party con alcol e donne a volontà. Generazioni di startuppari si sono ispirati a questo modello negli anni, e sarebbe curioso (lo chiedo senza sarcasmo, ovviamente) sapere il tasso di successo delle loro imprese. L’approccio secondo il quale il tecnico deve fare il tecnico, del resto, vale soltanto nella misura in cui chiedi l’aiuto di un fonico o di un geometra, ma non – a mio umile avviso – se chiedi un consulente del mio settore.

Dico questo perchè ho aperto partita IVA e mi sono messo in proprio soprattutto perchè il ruolo di semplice operativo – code monkey, per l’appunto – non mi era mai piaciuto, lo facevo malvolentieri durante la mia gavetta e mi ha provocato numerose emicranie negli anni. L’ho fatto anche perchè l’ingegnere è ingegnere anche perchè si fa venire le idee giuste in una dimensione realistica, e perchè la dimensione libero professionistica mi piaceva di più. Chi se ne frega, starete pensando: ma importante scriverlo per lo stesso motivo per cui, nel settore SEO, troverete un sacco di “innamorati della SEO”, “nerd dei motori di ricerca” e “staff di appassionati” da cui lasciarvi sedurre. L’ho fatto, soprattutto, perchè mi sono formato da ingegnere informatico con capacità specifiche di problem solving, che poi ho affinato con un dottorato di ricerca che, oltre ad insegnarmi una certa flessibilità nell’approccio ai problemi, mi ha anche insegnato un metodo di lavoro efficace e anche, direi, che le soluzioni esatte nella vita reale sono raramente realizzabili.

Nella maggioranza dei casi, chi cerca un ingegnere informatico sa già quello che vuole e cerca semplicemente un programmatore. Ma dovrebbe forse fare un passo indietro e chiedersi se la sua idea non possa essere resa più efficente, più veloce, più efficace e più facile da formalizzare. Buona parte dei casi in cui stai cercando un programmatore, in effetti, ti serve uno qualunque “bravo col computer” da spremere come il limone che ho inserito come immagine di copertina. E naturalmente, ad oggi, per buona parte delle persone, ad eccezione di un team di “illuminati” che non smetterò mai di ringraziare, è normale identificare il programmatore con l’ingegnere informatico.

E oggi, sono qui a ribadire che non è così.