A proposito del lavoro del programmatore
E’ proprio vero quello che diceva stamattina Bill Kennedy durante il suo keynote alla #golab. Solo 4 o 5 anni fa, per essere considerato un programmatore abbastanza buono (cit.) bastava conoscere abbastanza bene uno o due linguaggi ed un pò di SQL, mentre per essere considerati degli ottimi programmatori, si richiedeva la conoscenza di qualche framework ed un pò di aggiornamento ogni tanto. E basta o quasi.
Oggi non solo le tecnologie ed i linguaggi si evolvono ad un ritmo impressionante, ma anche la quantità di conoscenze richieste sono aumentate in modo non lineare e l'aggiornamento costante e continuativo è una conditio si ne qua non per non perdere il posto e/o la faccia. Per usare un termine impiegato dallo speaker, tutte queste richieste sono diventate overwhelming e praticamente impossibili da soddisfare.
I programmatori, infatti, devono possedere un’ottima conoscenza del loro codice sia a livello micro (algoritmi) che a livello macro (patterns). Devono sapersi destreggiare tra db relazionali, non relazionali, documentali, a serie temporali, a code od eventi. Devono, o forse sarebbe meglio dire dovrebbero, saper pensare e scrivere almeno i test di unità e di integrazione e documentare in modo corretto il codice. Se lavorano in ambito web (e chi non lo fa oggi?) devono conoscere i protocolli più usati (soap, rest, grpc) e come implementarli nel linguaggio adottato; devono sapere quale reverse proxy scegliere e perchè. Devono poi essere in grado di comprendere, e spesso implementare, una (o più) delle svariate possibilità architetturali oggi in voga (microservizi Vs monolite), il tutto dopo aver scelto se lavorare in un ambiente virtuale o containerizzato, e scegliere, di conseguenza, il tipo di piattaforma in cui implementare il tutto (on premise Vs cloud, in cluster o meno, con o senza orchestrator), districandosi, inoltre, tra tutti gli strumenti a disposizione per ottimizzare le build, i test ed i rilasci (CI/CD). Come se non bastasse, devono poter produrre e consumare metriche, integrando nel proprio stack tool quali Prometheus o ELK.
Quanto spazio rimane, dunque, per quella conoscenza che, fino a qualche anno fa, veniva considerata la più preziosa e che la costosa in termini di tempo e risorse necessarie a raggiungerla, cioè la conoscenza funzionale, quella legata al Business?
Non credo che esista una risposta alla domanda precedente o quanto meno non l'ho ancora trovata. Mi riservo di provare ad approfondire la questione in futuro provando a cercare una qualche risposta sensata.
