"Di cosa ti occupi?", una semplice domanda alla quale spesso i professionisti dell'IT trovano difficoltà a rispondere, non tanto per la mancanza di termini in grado di definire le caratteristiche del proprio lavoro, quanto per le reazioni degli interlocutori che spesso rivelano incomprensione. Sviluppatore, programmatore e software engineer sono soltanto alcune delle possibili occupazioni che ruotano intorno al codice sorgente, peccato però che gran parte di coloro che sono interessati a scoprire da cosa derivi una retribuzione sembrerebbero esserlo molto meno quando si scende nei dettagli.
In tanti oggi utilizzano applicazioni mobili, visitano siti Web, acquistano online e richiedono soluzioni digitali in grado di semplificare processi produttivi e commerciali; spiegare come funzionano questi aspetti dell'IT senza che chi ascolta mostri rapidamente segni di disattenzione è particolarmente arduo. A quanti utenti interessa realmente come funziona un'App, quali figure professionali coinvolge la sua realizzazione e quali strumenti vengono utilizzati per tali finalità?
Il developer Paul Oremland ha recentemente provato ad analizzare questa problematica sottolineando le differenze tra le diverse figure analizzate e riportando il discorso da un punto di vista tecnico.
Relativamente alla progettazione, il programmatore viene quindi definito come un professionista che pensa in termini di linguaggio, interfacce per la programmazione ed SDK. Si tratta di un professionista che agisce con strumenti in gran parte conosciuti e con i quali si trova a suo agio nell'operare, valorizza la creatività e le soluzioni ingegnose in fase di coding e si relaziona al deployment soprattutto in termini di scadenze.
Da parte loro invece, gli sviluppatori ragionerebbero in termini di interazioni, componenti e requisiti utilizzando schemi progettuali, piattaforme, linguaggi e framework che vengano incontro a questi fattori. Orientati al completamento dei progetti, favorirebbero in particolare aspetti come l'astrazione e la riusabilità del codice; da questo punto di vista diventerebbe fondamentale la possibilità di standardizzare strumenti e processi che permettano di gestire nel modo migliore la fase di deployment.
Infine, i software engineer utilizzerebbero un approccio incentrato sulle architetture privilegiando aspetti come la scalabilità, la gestione delle dipendenze e le possibili cause dei malfunzionamenti. Fortemente orientati al problem solving ricercherebbero in particolare soluzioni adattabili e flessibili, concependo sistemi caratterizzati dal maggior grado di automatizzazione possibile.
Si tratta di definizioni in parte condivisibili e in parte opinabili perché schematiche, soprattutto per un mercato come quello italiano che continua ad essere talmente immaturo da ricercare ancora professionisti full stack. Rimane il "problema" di rispondere chiaramente alla domanda "Ma tu che lavoro fai?", in questo caso però un approccio tecnico alla risposta potrebbe non essere il migliore.
Via Paul Oremland