Alla parola ingegnere ho finito per attribuire nel tempo sempre più rispetto. Nei primi anni di università studiavo per diventare fisico: di teoria ne avevo vista tanta, finché ho capito che volevo usarla per costruire e dare alla società qualcosa di tangibile.
Nello stesso periodo la parola software ha acquistato per me sempre più peso, perché porta leva reale sulla creazione di valore. Più o meno consapevolmente, ho imboccato quella direzione.
Due vie ricorrenti, in sintesi, per provare a portare valore alla società:
-
partire dai problemi e cercare la migliore combinazione di percorsi, soluzioni, tecnologia;
-
partire dalla tecnologia, dalla conoscenza e dalla competenza accumulata e dalla curiosità, e capire quali problemi quel percorso aiuta almeno a inquadrare e, quando va bene, a risolvere.
La sezione Writing porta avanti di solito la prima direzione; questo canale engineering la seconda.
Domande, contesto e direzione
Riprendendo da qui: un insieme di modelli mentali adatto al mestiere e una verifica quasi monotona. Mi sto ponendo davvero le domande giuste rispetto a ciò che c’è davanti sul tavolo?
Cambia anche la forma dell’esercizio quando una quota delle interrogazioni arriva prima da un sistema (modello linguistico statistico). Il passaggio delicato è dare abbastanza contesto, priorità leggibili, vincoli e una formulazione onesta dell’incertezza, così quell’assistenza resta direzionale e non si liquefa in rumore.
Capire in che direzione proseguire resta tutt’ altro che banale e non si risolve spostando la bussola interamente sulla macchina.
Esperienza e lacune
Parto dall’esperienza sul campo e dalle competenze maturate. Il bilancio dà uno sguardo piuttosto ampio su contesti tecnici diversi ma anche lacune teoriche e pratiche, effetto di una biografia abbastanza laterale sul piano delle curiosità.
Riprendo dalla base: tratto sintetico dove sono già solido, tratto lungo dove serve ancora rinforzo.
Crescita nel ruolo
Mi interessa essere chiaro sul significato di migliorare nel ruolo che oggi chiamiamo software engineer. Intendo trasformare progetti, codice e infrastrutture in conseguenze apprezzabili e stabili nel tempo.
Racconto qui principi osservabili e modelli mentali. È contenuto soggettivo nella forma, con ambizione pubblica minuscola: se capita materiale riusabile per chi vuole maturare tecnicamente o per chi cerca anche effetti fuori dall’IDE, meglio.
Tengo unite studio e pratica su progetti con potenziale di leva, così ciò che si impara coincide con qualcosa che resta concreto.
Buona parte del mestiere giornaliero è decidere su progettazione e architettura del software. Non esistono ricette universali. Contano la forma dei requisiti, la disponibilità spesso incompleta di informazioni, vincoli espliciti e impliciti, e una resa trasparente dei trade-off.
Funzione di questo spazio tecnico pubblico
Questo canale serve da diario tecnico sintetizzato.
Le definizioni complete vivono sulla documentazione delle fonti; qui tengo associazioni, schemi e sintesi che vale la pena fissare. Non ricopio i manuali: il dettaglio puntuale resta sulle prime fonti.
Talvolta, per accelerare su piccole formulazioni interrogative tecnico-pratiche, ricorro anche brevemente a uno strumento conversazionale, purché resti chiaro quale tipo di riscontro tecnico interessa.
Le interrogazioni sulla traiettoria lunga restano sul piano umano.