Conoscete degli sviluppatori software che abbiano più di quarant'anni? Con molta probabilità la risposta sarà no, perché secondo le ultime rilevazioni statistiche sembra che la "vita" professionale media di uno sviluppatore superi di poco i trent'anni. Ma perché dovrebbe accadere questo? Qual è il reale motivo che sta dietro ad una mancanza così importante di risorse mature?
Le ragioni per cui esistono pochi sviluppatori software over 40
Esistono due ragioni: la prima è che troppi sviluppatori passano al management dopo pochi anni, sia perché questo era l'obiettivo fin dall'inizio sia perché a volte finiscono in tale posizione anche per caso (ad esempio il manager in carica lascia ed il suo posto viene preso quasi sempre dal più esperto). In quest'ultimo caso parliamo di buoni sviluppatori software che mantengono delle elevate prestazioni fino al momento in cui non viene data loro una possibilità importante.
Quindi, senza neanche accorgersi, si ritrovano catapultati in sale conferenze per la maggior parte del tempo e difficilmente ne avranno da dedicare allo sviluppo. Insomma, l'ambizione prende naturalmente il posto della passione.
La seconda ragione risiede nel fatto che è gli sviluppatori a lungo termine spesso iniziano a credere di avere una conoscenza completa al riguardo il konw-how del momento (cosa peraltro vera nella maggior parte dei casi) per cui perdono lo stimolo ad apprendere nuove modalità di soluzione ai problemi, o a mantenersi aggiornati con il resto della comunità di sviluppatori.
È un po' quello che è accaduto ai primi programmatori HTML, alcuni dei quali, sicuri della loro posizione sono rimasti paludati nelle conoscenze iniziali, per poi trovarsi indietro quando hanno preso il sopravvento altri linguaggi di programmazione. Il concetto, sia per gli sviluppatori che per i programmatori, è il seguente: "perché cambiare una soluzione vincente?". Sostanzialmente uno sviluppatore dovrebbe convincersi di avere sempre qualcosa da imparare, onde evitare di diventare il classico veterano che, ad un'obiezione di un collega più giovane, risponderebbe: "fidati, è da vent'anni che scrivo codici!".
Lo scopo di uno sviluppatore (ma è così in tutti i campi sia della vita che lavorativi) è quello di accrescere le proprie competenze ma di non sentirsi mai arrivato, in modo da essere sempre stimolato a conoscere e ad aprirsi verso nuove idee e metodologie, altrimenti si rischia di nuocere a persone più giovani e ancora in fase di formazione. L'esperienza deve servire da guida per coloro che si accingono ad entrare nel mondo dello sviluppo, non da ostacolo.
Uno sviluppatore dovrebbe sempre chiedersi cosa fa e cosa pensa
Quando si ha a che fare con lo sviluppo di software, una gran parte della conoscenza non ha lunga vita; tutto ciò che si sa al momento riguardo il building di un software potrebbe essere irrilevante tra 10 anni. C'è anche di più: sembra paradossale, ma la conoscenza attuale di uno sviluppatore potrebbe ostacolargli lo sviluppo di un buon software tra cinque anni. Una scarsa presenza di figure professionali over 40 del mercato dello sviluppo software è quindi da ricercare nelle motivazioni riportate in precedenza.
Personalmente però ritengo che questo non rappresenti poi un problema, visto che ci sono sviluppatori giovani e dotati di ottime capacità, pieni di entusiasmo e di voglia di fare; è chiaro che l'ambizione porta raggiungere livelli sempre più alti, ma se resta la passione è sempre possibile trasmetterla verso chi si affaccia per la prima volta a questo mondo. Lo sviluppatore non sarà quindi una figura longeva, ma sicuramente può contare su un forte legame con la sua professione.
Nella mia ditta attualmente tutti gli addetti al software sono over 40 (me compreso)… 🙂
…forse siamo l’eccezione che conferma la regola?!? 😉
Premetto che ho sempre implementato (tranne qualche eccezione) software su sistemi embedded.
Infatti come detto nei commenti precedenti, in tale ambito conta molto l’esperienza e l’evoluzione non è così esasperata come a lavorare su programmi a PC e sebbene ormai si programmi in C o C++ a volta capita di dover usare ancora il buon vecchio assembler che era si scomodo da usare, ma almeno si era certi che il microprocessore faceva quello che gli dicevi (varie volte mi sono scervellato a capire certi bachi che alla fine si sono rivelati errori di compilatore).
Adesso tutti questi linguaggi ad alto livello (java, c#, ecc..) semplificano certe operazioni, ma rendono i sistemi lenti, meno deterministici e secondo me meno affidabili a causa di troppi strati di software programmati da chissà chi.
Ho visto giovani ingenieri far spendere decine di migliaia di € in sistemi operativi perchè non sapevano come configurare il controller ethernet del microprocessore. Poi a conti fatti hanno impiegato di più a configurare il sistema operativo. Per fortuna hanno cambiato ditta prima di fare altri danni ed ora viaggiamo alla grande senza sistema operativo.:)
Condivido anch’io il fatto che se una persona arriva a 40 anni e fa ancora programmazione vuol dire che è appassionato a tale lavoro altrimenti a causa dei grattacapi che da, avrebbe sicuramente cambiato professione.
Invece in ambito programmazione pura a PC secondo me a 40 anni è vero che pochi ci arrivano, infatti questo tipo di programmazione è molto più noiosa e alienante. Per fortuna a me capita raramente e quindi per ora resisto. 🙂
L’ambizione prende il posto della passione…penso che questo avvenga puntualmente non solo per gli sviluppatori software, ma un pò per tutti gli ambiti. Anche un progettista elettronico parte con la passione e finisce a dirigere team di progettisti, certo non sempre ma che ha ambizione si. Oppure ancora si parte con la passione per poi diventare degli imprenditori. Ho un parente ingegnere elettronico che dopo aver sviluppo un prodotto e brevettato, ora gira per l’italia a commercializzarlo.
Conuque leggendo il titolo dell’articolo avevo capito,in un primo momento, che gli sviluppatori software non vivessere per più di 40 anni….ahahahahaha
Sviluppare software per quanto possa essere un’attività interessante, secondo me è un lavoro proprio brutto. Cioè, io mi sono iscritto a ingegneria elettronica perchè ho passato gli anni prima a scrivere software e ho deciso che quella non era la vita che avrei voluto fare. Ci sono sempre un sacco di problemi nella scrittura di software, e spesso alcuni sono insormontabili, o peggio ancora sono sormontabili andando a cambiare un milione di impostazioni. Poi personalmente odio la parte di debug del codice e la scrittura di interfacce grafiche. Per questo mi auguro di fare il progettista elettronico, e non il programmatore. Poi non capisco come facciano tutti a passare al management dopo i 40 anni… quanti manager ci deovrebbero essere in giro?
Manager, non è detto che si occupi solo di economia, ma penso che si volesse comprendere nella categoria anche chi passa a dirigere il team… e che quindi non ha proprio più tempo per scrivere codice.
Per quanto riguarda ingegneria elettronica… mi sono laureato tre anni fa, e ti assicuro che non passa giorno che non mi trovi a progettare sia hardware, che firmware che software. quindi non penso che tu abbia scelto la strada migliore per allontanarti dal software! Oramai l’hardware quasi sempre ha al suo interno un micro, e quindi significa che qualcuno dovrà scriverne il codice…
Io non intendevo il manager solo come economista, ma come dici tu, anche come supervisore, organizzatore ecc. Comunque se tutti dopo 10 anni di lavoro diventassero manager, ne avremmo più o meno uno per ogni programmatore… mi sembra un pò esagerato.
Per quel che riguarda il lavoro, se devo mettere le mani a un firmware, o a un programma in C, so muovermi benissimo! Mi piacerebbe però che questa fosse solo una delle cose che dovrei fare. La programmazione embedded mi attira, è la programmazione di alto livello tipo Java, visual basic, .NET, Flash ecc. che non mi attira.
(detto questo dovrei anche specificare che sono più o meno 8 anni che programmo in php, e 4 che programmo in C e assembly), quindi se pure mi capitasse un lavoro come programmatore per il web, e non avessi niente da perdere, accetterei molto volentieri. La cosa che mi dispiacerebbe di più è che quello che prima era un hobby, poi diventa un mestiere… e spesso quando una cosa va fatta per forza comincia a non piacere più…
Caro Giovanni,
penso che nella vita la cosa più bella sia sempre quella che non si conosce. Sono un progettista elettronico e perciò mi capita di lavorare, alternativamente, sia con hardware che con firware, se non , a volte, anche con software a livello più alto. E ti assicuro che la scelta dell’elettronica non cambierà nulla. Il debug di una scheda elettronica, alla fine, non è per nulla di differente rispetto al software. Ci sono un mucchio di cose che non vanno, documentazione scarsa, errori del produttore non indicati, bachi nei micro e chi più ne ha più ne metta. Ore ed ore all’oscilloscopio a capire cosa non va. Altre alle maledettissime interferenze. Non voglio disilluderti, ma lo scopo del gioco, nella progettazione di qualsiasi tipo, è risolvere i problemi, spesso incomprensibili, devi essere preparato ad affrontarli, altrimenti ne avrai molte delusioni…
Certamente il debug hardware non differisce molto da quello software, però se per caso uno si ritrova a fare il progettista analogico o digitale di circuiti integrati (magari!) immagino che riesca ad avere una visione sul circuito che sta progettando pressochè totale… se serve sapere che fa la tensione a un nodo, si fa la simulazione del sistema e capisce più o meno tutto quello che va e che non va, e poi ci mette le pezze con la propria esperienza. I limiti sono essenzialmente dettati dalla natura delle cose. Invece se uno deve mettersi a scrivere un programma usando un framework, o altre componenti scritte da terze parti è sicuro come la morte che se lo usa a fondo trova qualche magagna o qualcosa che non va. A quel punto se il sistema che si utilizza è closed source, “non ci resta che piangere” e riscriverci interi pezzi di libreria. In genere i bug software da quel che ho capito sono molto più diffusi dei bug hardware.
Se voglio creare un VCO in tecnologia MOS che oscilli a 10THz sono un folle, e la colpa del non funzionamento sarebbe solo la mia, ma qualcuno nello stesso team potrebbe darmi uno schiaffo e chiedermi che sto combinando, così il progetto verrebbe corretto e vissero tutti felici e contenti. se invece scrivo il mio bravo programma, e quello crasha per colpa di una libreria esterna che funziona male, ho poco da fare. Potrei dovermi riscrivere daccapo la libreria sulla quale avevo basato il mio progetto. correggetemi se sbaglio!
Esempio banalissimo: Arduino. la funzione digitalWrite è estremamente lenta, tanto che in un banalissimo loop che accende e spegne un pin di uscita, arrivo al massimo a dei periodi di un centinaio di kHz, pur avendo un microcontrollore da 16 Mhz. E se in uscita devo far oscillare una porta a frequenza maggiore? Con arduino è facile ovviare, ma era solo un esempio…
Io stò ancora studiando in una terza itis informatica(17 anni), ma programmo da più di 3 anni e da 2 con il C. Sono inoltre appasionato di elettronica e spesso mi studio cose in più rispetto alle basi insegante a scuola.
Sono d’accordissimo che ci sono più bug software che hardware, ma credo che questo sia dovuto alla basilare differenza che un qualsiasi utente possa cimentarsi nella creazione di software(immagino solo cosa potrebbe venir fuori se qualcuno si mettesse a programmare in C/C++ senza conoscere come funziona il linguaggio…), mentre per sviluppare delle parti hardware occorrono delle conoscenze che chi non ha fatto un itis o si è laureato in una delle branchie dell’elettronica/informatica non possiede.
Lo sviluppo di un software è la stessa cosa di progettare una scheda hardware, con la differenza che se sbagli qualcosa non è il sistema operativo a dirti “errore” ma è la scheda che non funziona o si brucia. Molti framework(anche open source ma anche molti, moltissimi proprietari) e software sono scritti in tutta velocità e senza fermarsi sui test e dando meno importanza al debug. Questo è alla base di molti problemi software.
Secondo me bisogna specificare a quale tipo di applicazione software e a quale tipo di prodotto finale ci si riferisce. Per applicazioni orientate al web, al desktop, ad architetture client-server o database (applicazioni nei settori bancario, finanziario, e-commerce, ecc.) penso che il discorso possa avere un senso. In questi settori le tecnologie sono in continuo cambiamento e si susseguono a velocità elevatissime, per cui la possibilità di disporre di risorse “fresche” ed aggiornate è un vantaggio.
Per le applicazioni invece più vicine all’hardware (quelle sulle quali personalmente ho maturato una certa esperienza) non è assolutamente così. Recentemente ho partecipato a progetti nei quali si aveva difficoltà a reperire sviluppatori junior con conoscenza del linguaggio C (in compenso c’era un’elevata disponibilità su Java), per non parlare delle competenze in ambito real-time o embedded. E l’assembler? La filosofia object-oriented (di cui sono un grande estimatore) non ha certo cancellato la necessità di sviluppare in assembler: kernel di sistemi operativi, driver, ISR, o intere applicazioni sono ancora oggi scritte in assembler. Penso di non sconvolgere nessuno dicendo che buona parte dei programmatori assembler (quei pochi che sono rimasti) oggi abbia i capelli brizzolati (o bianchi..). Questo è un aspetto molto importante da tenere presente, visto che la manutenzione del software (si pensi alle applicazioni militari, biomedicali, nel settore dell’energia, ecc.) spesso deve essere garantita per molti anni e quindi richiede risorse capaci di sostenerla.
Credo proprio che anche io devo darti una brutta notizia!!! Se hai scelto ingegneria elettronica per non avere a che fare con software e firmware in genere, ti scontrerai presto con una realtà diversa. Il Software e il firmware sono ovunque ormai!! Se nel software vai a combattere con debugger e compilatori, che a volte non compilano o che prendono iniziative strane a causa di bug interni, nell’elettronica avrai molti altri problemi legati ai più disparati settori dell’ingegneria. Fin dal pensiero (di qualche fantasioso manager ) che fa nascere una nuova scheda avrai a che fare con scelte progettuali del tipo: Scelta dell’architettura del sistema che soddisfa le specifiche, e che sia fisicamente realizzabile ovviamente. Scelta dei componenti da utilizzare, con l’accortezza di contenere i costi, non solo del componente stesso, ma anche del costo del montaggio e del PCB (vedi BGA FBGA). Valutare la possibilità di eseguire test e debug della scheda, con ovviamente del firmware a bordo. Ecc. ecc. Il resto lo scoprirai strada facendo non voglio rovinarti la sorpresa 🙂
Fatto questo inizierai a combattere con tutti i software che utilizzi per fare gli schemi elettrici, il PCB, il firmware, il software ecc ecc. Ovviamente i problemi sorgono a causa dei bachi presenti nei vari programmi, e che sono forniti gratuitamente con il software stesso 🙂 Poi finalmente arriva la scheda pronta e montata. dopo aver verificato che chi ti ha montato la scheda non ti ha messo un condensatore come Pull-Up, ad esempio. Accendi il tutto e inizia a verificare che tutto funziona e che le specifiche siano soddisfatte (auguri). In genere anche questa fase non è semplice viste il numero di variabili che devi gestire. Infine, e non so se è stato solo un mio problema, ma ogni volta qualcuno inizia a scrivere del software (softweristi) gli errori non sono nel software che stanno scrivendo ma nell’HW che sbaglia i calcoli!!
Per chiudere, un ingegnere elettronico, oggi, oltre a scriversi il software e il firmware si fa anche l’hardware da solo, esegue il debug della scheda e anche dei software con cui l’ha disegnata!!!! Però è un gran bel lavoro nel momento in cui finisci il debug e vedi funzionare il tutto. 🙂 Hai finalemente i tuoi 10 minuti di gloria dopo magari 20 e più giorni di……..
PS. Il tutto da aggiungere a quello che hanno scritto gli altri in questa pag.
Sarcasmo a parte il lavoro che hai scelto non è per nulla più semplice dallo scrivere solamente del sofware, anzi hai in aggiunta molti altri problemi da risolvere.
Salve a tutti, vero che è difficile trovare sviluppatori (SW, ma anche HW) over 40, ma posso assicurarvi che ci sono e di regola se hanno “resistito” significa che sono veramente bravi e soprattutto capaci!
Io stesso ho passato i 40 (da poco), ma lo sviluppar nuovi prodotti è quella cosa che mi dà la più gran soddisfazione personale. Non credo debba descrivervi l’adrenalina che si sviluppa quando finalmente, dopo aver ottimizzato tutto, le cose funzionano come volevi! Questo chiaramente prende parecchio tempo ed è un processo di evoluzione. Le doti principali per colui che vuole sviluppare sono comunque la tenacità, la costanza e la perseveranza, doti che con il passare degli anni spesso tendono a diminuire.
Ho comunque colleghi over 40 che sono dei miti, degli autentici “geni”. Ho un amico che ha 50 anni ed è comunque sempre considerato un “guru” del silicio (sviluppa chip) addirittura da coloro che hanno lavorato nella silicon valley, un altro amico che ne ha 45 e sviluppa SW a livello professionale fin da quando ne aveva 16 (ha iniziato con il C64) e ancora oggi è reputato un “guru” nel suo dominio, tanto che quando ha voluto partire dall’azienda per cui lavora gli hanno detto: -“Chiedici lo stiupendio che vuoi, ma non andartene!”. Questi personaggi sono forse delle eccezioni, ma anche mio padre, che ha ormai raggiunto i 70 anni, continua a sviluppare nuovi SW nonostante da anni sia pensionato… un professore che ho avuto per un corso all’università aveva passato i 60 anni pure lui, ma ancora oggi è attivo nello sviluppo (molto meno) e ha oltre 80 anni!
Questi personaggi hanno tutti un fattore comune: sono curiosi, si entusiasmano e si divertono come bambini a fare quel che fanno! Ecco, forse è proprio questo il segreto, bisogna amare quello che si fa! Se qualcuno sceglie di fare ricerca e sviluppo per vocazione “durerà” nel tempo, gli altri passeranno ad altro.
Fintanto che la mattina vi sveglierete con la voglia di “andare a giocare” in ufficio, allora sarete degli ottimi sviluppatori, il giorno che vi peserà farlo (che abbiate passato i 40 o meno), sarete pronti a passare ad altro.
Dai, ora è meglio che continui a giocare… 😉
Pienamente daccordo con te!! L’argomento affrontato nell’artico, va riferito nel contesto della programmazione ad alto livello!! Più ci si avvicina all’hardware più ci si accorge che i linguaggi di programmazione sono gli stessi da molti anni!! (Asembler C/C++) Chiunque investe il proprio tempo nell’apprendere questi linguaggi, applicati all’hardware, avra un know how che di sicuro durerà nel tempo. Sarà in grado di proporsi ad un mercato del lavoro in cui, la velocità di evoluzione rende in breve tempo obsoleto un linguaggio di programmazione, o peggio, un intero framework. Come quello che è successo nel cambiamento avvenuto passando dal VB6 alle ultime versioni di visual studio!!
….nel senso che è sempre la passione e la curiosità e spingono ad impelagarsi in progetti e problemi apparentemente complessi ma affascinati.
Vale sia per gli imprenditori che aprono una pizzeria che per gli sviluppatori.
Ovviamente c’è una enorme differenza tra lavorare in proprio e non, nel primo caso la spinta viene dalla volontà ed intraprendenza di voler mantenere ed ampliare il proprio giro, sia la manutenzione di un software storico, dell’hardware o di provare ad investire su un nuovo progetto o trovare nuovi clienti, qui non conta l’età gli imprenditori vanno avanti ‘a vita’, magari passano, come si è detto, dallo sviluppo al management, ma non smetteranno mai di fare ‘gli analisti’; nel lavoro dipendente è chiaro che si presentano tutti gli inconvenienti che ci sono nel fare un lavoro comunque pesante, ripetitivo e poco pagato.
Per portare la mia esperienza io ho passato i 50 e programmo quando ne avevo 20, sono appassionato di elettronica e o trasferito questo nella gestione dei microcontrollori, musica, grafica, videogames, ho lavorato dipendente (poco) in sia in officine che come sviluppatore (pessimo), ho in giro alcuni applicativi verticali che mantengo da anni che ancora mi appassionano (non contabilità) e che mi danno da campare, sviluppo per il web, in .net, faccio reti, cose, vedo gente, vendo e manutengo(?) hardware ecc., ho creato piccole aziende che sono sopravvissute poco o tanto ma comunque sempre con la passione e la curiosità che chi sta in questo ambiente deve sempre avere, altrimenti cambiare settore prima di fare harakiri con la pennina usb.
Saluti
nb.anch’io avevo capito che gli sviluppatori campavano poco :).
Scrivo software dal lontano 1971. I primi programmi li ho realizzati in linguaggio RPG. Si trattava di semplici applicativi per gestire i cartellini orologio timbrati dai dipendenti.I computer si chiamavano allora “Calcolatori elettronici” e il CED “Centro meccanografico”. L’ingresso dei dati da elaborare avveniva tramite la lettuira di schede perforate.Poi sono passato a realizzare applicativi e gestionali scritti in Assembler, e via via in C.Poi su macchine piu’ evolute ho scritto applicativi in RM-COBOL e successivamente in ACU-COBOL.Cambiando azienda ho realizzatto l’intero gestionale su macchine RSIC 6000 IBM in ACU-COBOL. Data la mia esperienza in Assembler sono passato poi a scrivere software per microcontrollori ST6 ST7 PIC16 PIC18 poi in C su PIC24 e CORTEX-M3.
Ora ho quasi 60 anni e mi entusiasmo ancora ogni volta che inizio un nuovo progetto.
La parte piu’ bella e’ quella del debug.
Il mio titolo di studio ? 3 media.
La mia fortuna ? Credere in quello che fai e smettere di piangersi addosso
Il lavoro piu’ bello ? Scrivere software
Ancora una volta ti devo disilludere… dire che l’hardwerista conosce le tensioni ai nodi è un po’ come dire che il softwerista può fare un debug completo visualizzando i parametri che ottiene da una routine in seriale. Ma oltre la barriera del componente fisico cosa succede? Un package, normalmente, ha dai tre ai 100 ( a volte più) piedini, ma all’interno ha un numero di piste almeno 10 volte più numerose…
Ho appena finito, ad esempio, di capire perché una routine che ho scritto non funzionava sebbene elettricamente fosse tutto ok, per scoprire che è un baco del micro di ST…
E lo stesso, ti assicuro, vale per gli analogici.
E poi si fa ancor più complesso quando i dati diventano non misurabili. Le interferenze elettromagnetiche, ad esempio, sono totalmente imprevedibili, e misurabili (parzialmente) solo con strumentazioni dedicate (e quindi in grosse ditte oppure in certificazione). Su un PC, invece, le condizioni al contorno sono tutte e prevedibili. Si sa già che parametri può ricevere una routine, mentre nessuno sa che segnale di disturbo potrebbe arrivare su una scheda in una certa condizione. Un po’ come diceva un mio prof. l’effetto “RadioMaria”…
Se come dici tu su un PC tutte le condizioni sono prevedibili non riesco a capire come mai non siano ancora riusciti a stabiire regole di sviluppo e tools 100% error free…
Inoltre tutte le condizioni prevedibili devono essere previste e le condizioni non sono solo SW ma anche HW o di comunicazione o di interazione con l’utente (in certe condizioni -registratori di cassa- ho dovuto considerare la possibilità che ci si sedesse sulla tastiera – queste io le chiamo prove scimmia ma non posso spiegarti perchè)
Non so a quanti è capitato ma io ho visto una CPU sbagliare a fare i conti e non dare errori
Ciao, diciamo che per ruolo dirigenziale si intende più che altro una qualsiasi persona che abbia al di sotto delle persone da gestire. Difficilmente è il caso dell’italia, caratterizzata da un ambiente lavorativo ancora feudale costituito da feudatari e sudditi, ma all’estero, soprattutto nel mondo anglosassone, esiste una schiera di team leader e manager di livelli così diversi da essere veramente un numero considerevole..da noi se sei manager sei arrivato, all’estero dipende da che manager sei. POi calcolate che molti passano alla progettazione dallo sviluppo o cambiamo magari radicalmente occupazione. In effetti, voi conoscete sviluppatori ‘anziani’?
Per electropower..eh si, infatti il titolo crea ambiguità: come a dire, se sei sviluppatore non arrivi alla pensione! 🙂
un amico che lavora in una importante azienda mondiale mi ha raccontato di come un prodotto Cadence impieghi 2 settimane a effettuare una simulazione transiente di 10 millisecondi di un circuito girando sui supercomputer dell’azienda. Mi auguro che permetta di conoscere le tensioni a tutti i nodi…
Poi se uno fa il progettista utilizzando integrati prodotti da terze parti è un altro discorso.
Ma uno che fa il proggettista, innanzi tutto, nel 99% dei casi utilizza prodotti di terze parti per realizzare una scheda elettronica. Se poi ti dovesse capitare di essere di quella minoranza che progetta direttamente un chip e che ha la visaione totale di quel che c’è dentro le problematiche da affrontare saranno ancora più complesse. Primo perchè, come hai detto tu stesso, si passa dalla realtà misurata alle simulazioni, perciò quello che conosci sono solo dati teorici, da verificare. Oltretutto direi con estrema tensione, visto che un errore di un progettista di chip può costare decine di milioni di euro ad ull’azienda. In secondo luogo una volta note le tensioni bisognerà tener conto di un buon numero di problematiche maggiormente legate alla fisica piuttosto che all’elettronica su cui non mi soffermo.
Condivido le tue affermazioni perchè sono dati oggettivi, ci mancherebbe… però è anche una cosa personale… cioè, io personalmente preferirei perdere una settimana di lavoro a cercare di aumentare il margine di fase di un amplificatore, piuttosto che passare un giorno a debuggare il codice Javascript che non funziona su internet explorer. Questo lo dico perchè l’ho fatto… Ti faccio un esempio: il mio ex datore di lavoro disegnava delle pagine con front page (mai visto programma più schifoso!!), poi le passava a me. Io aggiustavo tutto l’html, sbrogliando i tag incrociati e le tabulature (che front page non sa fare), poi aggiungevo il mio codice comprensivo di javascript, testavo su firefox e tutto funziona. Faccio l’upload sul server, e mi chiama il capo dicendo che non gli funziona niente. Allora scarico internet explorer, (lui usava in quel tempo, non troppo lontano, la versione 5) e vedo che in effetti non funziona niente. Allora mi sono rimesso da zero a provare quale codice gira su IE e quale no… ci ho perso 2 giorni a scrivere 10 righe di javascript che funzionasse su IE, ed è stata un’esperienza frustrante. Nel mondo dell’elettronica ancora non ho maturato tanta esperienza, ma è più frequente che i limiti li detta madre natura, non dei software scritti male.
Quest’articolo mi ricorda la vita familiare mia,
mio padre ormai quarantacinquenne all’epoca della sua gioventù è cominciato proprio con la programmazione.
Pur amava applicazioni finanziarie in COBOL e poco a poco visto che doveva conoscere molto bene il mondo delle finanze più che il mondo della programmazione, dopo una decina di anni si mi ricordo bene verso i suoi 28 anni quasi nettamente è passato dallo statuto di programmatore a quello come dice l’articolo manager,
Questo passaggio è stato influenzato da due fattori importanti il fatto che era diventato un ottimo finanziere più che un programmatore e che si transitava poco poco dal COBOL a linguaggi C e infine molto importante e che il salario visto che si guadagna di più è ormai era cinque anni cerco nato così siamo usciti dallo statuto di un salario precario di programmatore a un salario sicuro di manager.
Cara EDI quando tu probabilmente sei nata (82?) io partivo per il militare…
Prima di programmazione… il mio prof di informatica mi diceva che “il programmatore è una razza in via di estinzione…” e prima o poi accadrà, in realtà la differenza, più che la conoscenza dei linguaggi, la fa la capacità analitica e di progettazione la figura che una volta veniva chiamata “analista programmatore” e che in alcune aziende (prevalentemente estere) possono essere anche due figure diverse,
Veniamo alla carriera: il “programmatore” è un primate (lavorativamente e retributivamente parlando) difficilmente (sempre in Italia) trovi il programmatore professionista esperto bravo adeguatamente retribuito. Affrontare problematiche di un certo settore per sviluppare analisi e programmi lo porta ad essere un esperto del settore stesso e per una crescita professionale ed economica l’unica opzione è diventare project manager, commerciali o business consultant ma di questo hanno già parlato.
Veniamo all’esperienza io sono passato dall’assembler al basic, cobol, C, C++, Java, HTML, PHP,… in modo più o meno approfondito ma se devo essere sincero le evoluzioni dei linguaggi sono prevalentemente orientate a facilitare il compito dei programmatori o a (escluderli).
I linguaggi poi io ritengo siano come la modo alla fine i concetti di base sono gli stessi riciclati, se solo pensi che siamo partiti da linguaggi interpretati e siamo tornati a linguaggi interpretati…
La differenza la fanno le macchine e le loro prestazioni e come sfruttarle lo devi imparare per forza ma quello che fai oggi con il Python o con il Ruby lo fai con il C o con l’assembler (magari ci impieghi SOLO un po’ di più).
E’ vero rimanere aggiornati è una esigenza (anche del manager non solo del programmatore) ma anche uno sguardo al passato di alcuni programmatori giovani non sarebbe male, spesso, per metterli alla prova, mi capita di chiedere loro come controllare una data e trovarli impreparati…
Noi VECCHI programmatori o EX siamo una generazione dove per scoprire le cose abbiamo dovuto sperimentare e “creare” ora molti GIOVANI programmatori sono programmatori copia/incolla (non che non sia comodo ma si perde un certo gusto … e se il tuo problema nessuno lo ha avuto diventa un problema perchè non hai l’abitudine ad inventarti qualcosa!).