• Passa alla navigazione primaria
  • Passa al contenuto principale
  • Passa alla barra laterale primaria
  • Programmazione
  • Siamo tutti geek
  • IT Business
  • Tlc & Internet
  • Applicazioni & OS
  • Networking & Security
  • Software Engineering
  • Gadget

Stacktrace

Aperiodico di resistenza informatica

  • Home
  • Collabora
  • Archivi
  • Chi siamo
  • Termini d’uso

Non ci sono più i software engineer di una volta

10 Gennaio 2008 A cura di Piergiuliano Bossi

CrossTalk, ovvero il giornale di software engineering del Dipartimento della Difesa americano (DoD), ha pubblicato nel numero di gennaio uno spunto interessante riguardante gli skill dei software engineer di domani. L’intervento è firmato da due professori del corso di Computer Science della New York University, nonché esponenti di spicco della comunità Ada attraverso AdaCore, fornitore di soluzioni Ada al DoD stesso (e non solo).

L’articolo ha un tono un po’ inconsueto e di fatto ha tutti gli elementi tipici di un rant, il che personalmente mi ha fatto un po’ specie, data l’autorevolezza dei personaggi in questione. Mi ricorda un po’ le lamentazioni di Bug Barbecue, uno dei personaggi più riusciti dei Microservi, altrimenti noto come “the World’s Most Bitter Man”, perennemente in preda a crisi di nostalgia per i bei tempi andati dello Xerox PARC.

Ci sono però alcuni elementi particolarmente degni di nota che vale la pena di sottolineare:

  • gli autori denunciano la scarsa preparazione teorica degli studenti tipicamente sfornati dai corsi di CS, con uno schiacciamento dell’orizzonte sui soli temi di programmazione a discapito di una migliore preparazione matematica, della conoscenza di metodi formali di specifica e verifica di correttezza, ecc.;
  • l’adozione di java come primo linguaggio di programmazione viene vista come una scelta particolarmente infelice, anche se comprensibile visti i trend attuali in ambito professionale.

Da un certo punto di vista non posso che essere d’accordo con Dewar e Schonberg: ogni software engineer degno di tale nome dovrebbe avere a cuore una preparazione a tutto tondo, senz’altro multidisciplinare. Allo stesso modo, dovrebbe non trascurare i principi e le meccaniche di base che ad esempio sottendono costrutti di programmazione in linguaggi di alto livello. Il bravo software engineer è innanzitutto un generalista onnivoro, in grado di muoversi su temi diversi in modo confortevole, dato un tempo adeguato di adattamento.

D’altro canto, gli strumenti di sviluppo, sia pratici che concettuali, si spostano sempre di più verso una maggior potenza a parità di espressività. Aritmetica dei puntatori e gestione dello heap sono senz’altro temi essenziali e ogni software engineer in nuce deve essere in grado di maneggiarli. Detto ciò, ben venga ogni semplificazione che consente di concentrarsi su design e architetture in modo omogeneo, senza compromettere il codice con tecnicismi ineleganti che assomigliano più a soluzioni rappezzate che a virtuosismi.

Archiviato in:Software Engineering Contrassegnato con: ada, c, c++, java, linguaggi, lisp, Programmazione

Interazioni del lettore

Commenti

  1. Laburno dice

    11 Gennaio 2008 alle 09:53

    Io non sono un grande programmatore ma quello che è stato detto su Java lo condivido.
    Mi sono ritrovato a studiarlo adesso per un progetto e rispetto al C++, cui ero abituato, è veramente molto più semplice: puntatori e riferimenti impliciti, assenza di distruttori, un garbage collector che lavora per te, etc… è una pacchia per certi aspetti.

  2. maesltrom dice

    11 Gennaio 2008 alle 10:20

    Condivido le affermazioni sulla preparazione degli studenti: sono convinto che il un linguaggio da imparare è sempre il C, per la possibilità che ti da di conoscere le problematiche di più basso livello.

    E poi sono anche d’accordo sulla preparazione matematica, che deve essere solida e ferrata.

  3. Masci dice

    11 Gennaio 2008 alle 10:35

    Se volete un punto di vista diverso leggete questo:
    http://www.joelonsoftware.com/items/2008/01/08.html

  4. Folletto dice

    11 Gennaio 2008 alle 15:59

    Io ritengo che un programmatore possa ritenersi tale solamente nel momento in cui, trovatosi ad imparare un nuovo linguaggio di programmazione, il suo unico problema è quello di capire la sintassi che le librerie).

    Ho visto troppi suddetti “programmatori” che messi davanti a del codice in un linguaggio “estraneo” non erano in grado di capire cosa facesse.
    E l’università non aiuta. Se penso che in Bicocca (Informatica) stanno adottando .Net e Java “perché prepariamo per il mondo del lavoro” ignorando che nel 90% dei casi quello che viene imparato è quello citato nell’articolo: assemblare più o meno a caso codice altrui.

    Degno di nota comunque, sempre in Bicocca, che almeno è presente un corso di base per Lisp e Prolog. Non eccezionale, ma almeno qualcuno ci prova.

  5. riffraff dice

    11 Gennaio 2008 alle 18:57

    io l’unica cosa relativa a modelli formali di costruzione, derivazione & verifica del software l’ha trovata per sbaglio facendo la tesi con NesC.

    Ing inf alla Sapienza, tre esami alla laurea e due ordinamenti universitari alle spalle. Ma forse ero io che ero distratto.

  6. morpheu5 dice

    2 Aprile 2008 alle 20:07

    Un po’ dipende da come è impostato il programma di una certa università. A Padova Ingegneria, per esempio, c’è molta teoria formale, sia matematica che algoritmica e su più livelli: dalla combinatoria all’algebra, dai modelli per valutare gli algoritmi allo studio dei linguaggi formali è tutto un fiorire di teoria.

    Peccato che manchi un bel corso di C/C++ (cosa che tentano di inserire a forza all’ultimo anno in un corso di sistemi operativi real-time con scarso successo).

  7. Alberto Brandolini dice

    7 Aprile 2008 alle 17:55

    Ciao,
    Un altro punto di vista interessante è quello espresso da McConnell in Professional Software Development: ci sono aree della professione di sviluppatore che vengono spesso ignorate dai programmi universitari: testing, software configuration management ed in generale ciò che concerne il lavoro di gruppo. In generale, poter attingere ad una molteplicità di linguaggi (il più possibile diversi da loro – io su questo sono stato fortunato) per risolvere determinate classi di problemi aiuta, decisamente.
    Alla fine la lezione che si impara è che nessuno ti insegna tutto, e che c’è un mare di roba “là fuori” da imparare, tra cui bisogna imparare a muoversi, in un modo o nell’altro.

Barra laterale primaria

Seguito da più di 16,000 programmatori

Idea Hai idee per un articolo? Contattami!

Leggi il mio libro

Technical Blogging: Amplify your influence

Printed | Ebook | Audiobook

Follow @stacktrace

Post recenti

  • Recensione di Amazon Books a Seattle
  • Il vero nemico degli artisti in rete
  • 10 consigli per interagire con il proprio geek di famiglia
  • Amazon lancia il Kindle italiano
  • IBM rilascia la versione 9.7.5 di DB2 Express-C

Commenti recenti

  • Leonardo su 10 consigli per interagire con il proprio geek di famiglia
  • Gilton su 10 consigli per interagire con il proprio geek di famiglia
  • Lorenzo su La fluidità del codice
  • Lorenzo su 10 consigli per interagire con il proprio geek di famiglia
  • Mr.Price su 10 consigli per interagire con il proprio geek di famiglia

Categorie

  • Applicazioni & OS (13)
  • Editoriali (11)
  • Gadget (7)
  • IT Business (25)
  • Legge & Privacy (8)
  • Libri (6)
  • Networking & Security (11)
  • Programmazione (104)
  • Siamo tutti geek (33)
  • Software Engineering (9)
  • Tlc & Internet (17)

Tag popolari

agile algoritmi amazon apple business c cisco conferenze django eventi extreme programming firefox framework geek google internet ironruby italia java libro linguaggi linux lisp matematica microsoft mozilla networking perl php Programmazione project euler pycon python rails rest rubinius ruby scheme startup vignetta visione web web2.0 windows xul

Hanno collaborato

  • Antonio Cangiano (RSS) (68)
  • Marco Beri (RSS) (23)
  • Michele Simionato (RSS) (22)
  • Alex Beri (RSS) (18)
  • Ludovico Magnocavallo (RSS) (12)
  • Valentino Volonghi (RSS) (9)
  • Marco Ceresa (RSS) (9)
  • Piergiuliano Bossi (RSS) (7)
  • Davide Ficano (RSS) (7)
  • Simone Dall'Angelo (RSS) (7)
  • Gabriele Renzi (RSS) (6)
  • Giovanni Intini (RSS) (6)
  • Daniele Varrazzo (RSS) (5)
  • Nicholas Wieland (RSS) (5)
  • Michele Finotto (RSS) (4)
  • Luigi Panzeri (RSS) (4)
  • Matteo Nodari (RSS) (3)
  • Lawrence Oluyede (RSS) (3)
  • Stefano Rodighiero (RSS) (3)
  • Andrea Righi (RSS) (3)
  • Roberto De Ioris (RSS) (2)
  • Alberto Revelli (RSS) (2)
  • Davide Casali (RSS) (2)
  • Franco Lombardo (RSS) (2)
  • Claudio Cicali (RSS) (2)
  • Carmine Noviello (RSS) (2)
  • Massimo Scamarcia (RSS) (1)
  • Marco De Paoli (RSS) (1)
  • Francesco Matarazzo (RSS) (1)
  • Emmanuele Somma (RSS) (1)
  • Nicola Larosa (RSS) (1)
  • Massimiliano Mirra (RSS) (1)
  • Lorenzo Bolognini (RSS) (1)

Disclaimer

Stacktrace.it partecipa al Programma Affiliazione Amazon EU, un programma di affiliazione che consente ai siti di percepire una commissione pubblicitaria pubblicizzando e fornendo link al sito Amazon.it (e altri siti Amazon di altri paesi). Forniamo inoltre link a siti non associati con Amazon, che ci permettono di percepire una commissione sulle vendite. Amazon e il logo Amazon sono marchi registrati di Amazon.com, Inc. o delle sue affiliate.

Copyright © 2007-2018 Antonio Cangiano