EE vs Informatica: effetti sugli approcci, gli stili degli sviluppatori? [chiuso]

Ci sono differenze sistematiche tra gli sviluppatori di software (ingegneri sw, architetto, qualunque titolo professionale) con un background elettronico o di altro tipo rispetto a quelli che hanno iniziato la professione attraverso l'informatica?

Per background elettronico, intendo un diploma EE o un armeggiatore elettronico autodidatta, altri tipi di ingegneri e fisici sperimentali.

Mi chiedo se entrare nelle professioni del software da una forte conoscenza di infradito, buffer tristate, tempi di salita del clock e così via, di solito porta a un approccio distinto a problemi, mentalità o abilità superiori in determinate specialità e carenze di competenze in altri, rispetto ai tipi di informatica che sono pieni di concetti come tipi di dati astratti, orientamento degli oggetti, normalizzazione del database, che parlano di "chiusure" nei linguaggi di programmazione - cose che hanno poco senso per la folla del saldatore fino a quando imparare abbastanza programmazione.

Il mondo reale, ne sono certo, offre una vasta gamma di eccezioni individuali, ma per la maggior parte, puoi dire che ci sono differenze complessive? Questi avrebbero implicazioni di assunzione, ad esempio (per inventare qualcosa) "non assumere mai un elettrone wrangler per fare la progettazione di database"? La conoscenza di eventuali differenze può aiutare le persone in cerca di lavoro a trovare qualcosa di appropriato in modo più efficace? O fornire illuminazione o qualche consiglio pratico per coloro che si trovano disadattati in un particolare ruolo lavorativo?

(A proposito, non ho mai preso lezioni di informatica; la mia impressione di quello che coprono è confusa. Sono un tipo di elettronica / fisica / arte, me stesso.)

Avendo un minore EE e un maggiore CS, ho lavorato accademicamente con entrambi i gruppi. Non ho mai svolto un lavoro in cui ho progettato prodotti in stile EE, ma ne ho consumati molti facendo lavori per aziende con cose come PLC, e quindi essere stato in grado di capire (da un background educativo) cosa è successo . Quindi non posso dire di conoscere al 100% il comportamento e le caratteristiche del luogo di lavoro, ma posso descrivere le academicdifferenze tra i due in una certa misura.

Le persone di EE tendono a concentrarsi sui dettagli e tendono a conoscere l'esatta implementazione. Se non è mappabile al 100%, non gli piace. La gente di EE ottimizzerà verso il basso per rimuovere i dettagli non necessari, se possibile.

Le persone SE tendono ad apprezzare gli strati e la compartimentazione della logica. La gente SE non si preoccupa dei progetti gonfiati. La gente SE tende ad essere molto orientata alla matematica. Tendono a pensare in termini di equazioni e come risolvere i problemi da un concetto di modello. I join sono più intuitivi per questo gruppo, come il lavoro di database. Più SE vai avanti più tendi a vedere persone che sono fluenti con cose come la Programmazione Funzionale. Questo non è un terreno sicuro per una persona EE.

Entrambe le persone conoscono cose come le mappe di Karnaugh, quindi ci sono molte sovrapposizioni in quelle aree. Riduzione della logica, quel genere di cose.

Ok, questa è la mia risposta soggettiva. Spero che sia d'aiuto.

Se dovessi generalizzare, ecco quale è stata la mia esperienza:

• Gli ingegneri (o solo gli EE) tendono a fare meglio nella "perfezione del piccolo". Dato un piccolo compito di programmazione, pensano molto e duramente a tutti i casi limite e hanno maggiori probabilità di finire per costruire un software che è molto robusto. Di solito è guidato da un approccio top-down design-it-all-up-front, perché è quello a cui sono abituati nell'hardware. Di solito comporta l'uso di macchine a stati, perché sono abituate a progettarle per l'hardware e si adatta all'approccio del "grande design". D'altro canto, non pensano tanto alla scalabilità o alla manutenibilità.

• I tuoi sviluppatori tradizionali sono più bravi a gestire una grande complessità, soprattutto perché la formazione spinge a scomporre i problemi in bit più piccoli e più gestibili. Viene loro insegnato a evitare il grande progetto e a separare le preoccupazioni, scrivere test e far passare i test. In genere ci sono molti piccoli casi limite mancati, solo a causa della complessità e del tempo, ma quelli alla fine vengono coperti. Gli sviluppatori tendono a trarre vantaggio dal fatto che è solo un software e dovrebbe essere (o è) facile da cambiare. Quando EE lavora con l'hardware, non hanno questo vantaggio e penso che ci voglia tempo per effettuare la transizione.

Come ho detto, questa è la mia esperienza generalizzata. Non è vero in ogni caso.

Nella mia esperienza, i tipi di EE sembrano progettare programmi lineari e non incorporare gli strati di astrazione con cui i tipi CS sembrano essere a proprio agio.

Nessun commento sulle differenze di qualità o sulla loro mancanza.

Dubito che vedresti molte differenze nel solito tipo di business o app web su cui la maggior parte delle persone finisce per lavorare, una volta che entrambi hanno qualche anno di esperienza sotto le loro cinture. Tutte le cose che elenchi come confuse per la "folla di saldatori" sono normali abilità di programmazione. In sostanza stai rispondendo alla tua domanda: qualcuno senza un background di programmazione può imparare la programmazione, ma fino a quando non lo fanno non sono un programmatore. Qualcuno con una mente logica e analitica troverà molto più facile imparare a programmare bene di qualcuno che non lo fa - sarebbe l'unico vantaggio che posso pensare per un armeggiatore elettronico autodidatta.

L'informatica (al contrario dell'ingegneria informatica) è prevalentemente matematica, come (ai livelli più alti) sono le varie altre scienze come la fisica - ma è un tipo molto diverso di matematica. Se hai fatto una scienza diversa, allora avrai fatto anche la matematica e quindi dovresti trovare la possibilità di alzarti per la velocità a differenza di qualcuno che non ha una conoscenza della matematica. Ovviamente, pochissimi programmatori hanno mai veramente bisogno di conoscere la teoria degli insiemi, il big-O o qualsiasi altra cosa - certamente non ad alto livello comunque.

Ho iniziato con un BSEE, ho iniziato a lavorare sulla progettazione di circuiti logici per un grande laboratorio di ricerca e sviluppo telefonico e (questo è stato circa 40 anni fa) ho realizzato che la maggior parte di ciò che stavo costruendo alla fine poteva essere fatta con un programma per computer. Quindi sono tornato e ho ottenuto un diploma MSCS.

Sono sempre stato interessato all'architettura del computer e a ciò che accade a livello hardware. Gran parte della mia carriera è stata dedicata alla progettazione di sistemi di microcontrollori incorporati, dove cerco di trovare la migliore corrispondenza tra ciò che viene fatto nell'hardware e ciò che viene fatto nel firmware. Tuttavia, ho fatto un bel po 'di programmazione Web e un po' di progettazione di database.

Senza il mio background in CS, penso che avrei molti più problemi a cogliere concetti più astratti. Oltre a molti linguaggi assembler diversi, ho usato C, C ++, C #, Pascal, Delphi, Perl, PHP e alcuni Lisp. Attualmente sto cercando di imparare Ruby e Python. Design OO con cui sono abbastanza a mio agio. Programmazione funzionale Non lo sono (ancora).

Lo stesso vale per i database. Capisco la normalizzazione. Ho dei problemi con alcuni dei JOIN più esoterici e li evito. Non mi sento davvero a mio agio con qualcosa a meno che non capisca cosa sta succedendo sotto il cofano.

Voglio essere in grado di "vedere" come il computer eseguirà il programma nella mia testa.