EE vs Computer Science: effetto sugli approcci degli sviluppatori, stili? [chiuso]

Avendo un EE minor e un CS maggiore, ho lavorato con entrambi i gruppi accademicamente. Non ho mai tenuto un lavoro in cui ho progettato prodotti in stile EE, ma ho consumato molti di loro facendo lavoro per aziende con cose come PLC, e quindi essendo stato in grado di capire (da un background educativo) che cosa stava succedendo era bello . Quindi non posso dire di conoscere al 100% il comportamento e le caratteristiche del posto di lavoro, ma posso descrivere le differenze di academic tra i due in una certa misura.

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

La gente di SE tende ad apprezzare gli strati e la compartimentalizzazione della logica. Alla gente di SE non importa progetti gonfiati. La gente di 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 sui database. Più si SE si va e più si tende a vedere persone che parlano fluentemente 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 c'è molta sovrapposizione in quelle aree. Riduzione logica, quel genere di cose.

Ok, questa è la mia risposta soggettiva. Spero che ti aiuti.

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

• Gli ingegneri (o solo EE) tendono a fare meglio nella "perfezione del piccolo". Dato un piccolo compito di programmazione, pensano molto a lungo su tutti i casi limite e sono più propensi a finire con la creazione di un software molto robusto. Di solito è guidato da un approccio top-down design-it-all-up-front, perché è ciò a cui sono abituati nell'hardware. Solitamente 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 stanno pensando 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 piccoli bit più gestibili. Viene loro insegnato ad evitare il grande design, e basta separare le preoccupazioni, scrivere test e superare i test. In genere ci sono molti piccoli casi limite, solo a causa della complessità e dell'ampiezza; tempo, ma quelli alla fine vengono coperti. Gli sviluppatori tendono a trarre vantaggio dal fatto che è solo software e dovrebbe essere (o è) facile da cambiare. Quando gli EE lavorano con l'hardware, non hanno questo vantaggio e penso che ci vuole tempo per effettuare la transizione.

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

Nella mia esperienza - i tipi EE sembrano progettare programmi lineari e non incorporare i livelli di astrazione con cui i tipi CS sembrano essere a loro agio.

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

Dubito che vedresti molta differenza nel solito tipo di app aziendali o web a cui la maggior parte delle persone finisce per lavorare, una volta che entrambi hanno qualche anno di esperienza alle spalle. Tutte le cose che elevi come confuse per la "folla di ferro saldato" sono normali abilità di programmazione. In sostanza stai rispondendo alla tua stessa domanda - qualcuno senza un background di programmazione può imparare a programmare, ma fino a quando non lo fa non è un programmatore. Qualcuno con una mente logica e analitica troverà molto più facile imparare a programmare bene rispetto a qualcuno che non lo fa - questo sarebbe l'unico vantaggio che posso pensare per un riparatore di elettronica autodidatta.

Computer Science (al contrario di Computer Engineering) è prevalentemente matematica, in quanto (ai livelli più alti) sono le varie altre scienze come la fisica - ma è un tipo di matematica molto diverso. Se hai fatto una scienza diversa allora avrai fatto anche matematica e quindi dovresti trovare la possibilità di diventare più veloce a differenza di qualcuno che non ha esperienza in matematica. Certamente, pochissimi programmatori hanno davvero bisogno di conoscere la teoria degli insiemi, il big-O, o qualsiasi altra cosa - certamente non ad un livello elevato comunque.

Ho iniziato con un BSEE, sono andato a lavorare alla progettazione di circuiti logici per un laboratorio R & amp D di grandi dimensioni telefoniche, e (questo era circa 40 anni fa) mi sono reso conto che la maggior parte di ciò che stavo costruendo poteva essere fatto con un programma per computer. Così sono tornato e ho ottenuto una laurea in MSCS.

Sono sempre stato interessato all'architettura dei computer e cosa succede a livello hardware. La maggior parte della mia carriera è stata dedicata alla progettazione di sistemi embedded di microcontrollori, in cui cerco di trovare il miglior abbinamento tra ciò che viene fatto nell'hardware e ciò che viene fatto nel firmware. Tuttavia, ho fatto un bel po 'di programmazione web e alcuni progetti di database.

Senza il mio background in CS, penso che avrei molti più problemi ad afferrare concetti più astratti. Oltre a molti linguaggi di assemblatore, ho usato C, C ++, C #, Pascal, Delphi, Perl, PHP e alcuni Lisp. Attualmente sto cercando di imparare Ruby e Python. OO design mi sento abbastanza a mio agio. Programmazione funzionale Non sono (ancora).

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

Voglio essere in grado di "vedere" come il computer avrebbe eseguito il programma nella mia testa.