Come spiegheresti che l'ingegneria del software è più specializzata di altri campi ingegneristici? [chiuso]

but in a way it also trivializes the profession, as in "Codemonkey, go sling code".

Direi piuttosto il contrario. Un buon ingegnere del software avrebbe la capacità di concettualizzare, progettare e progettare un software di qualità indipendente dalla tecnologia. L'estremità opposta di questo spettro è .NET o Java o PHP solo "codemonkey" che è bravo a ricevere indicazioni o specifiche e utilizzare lo strumento per implementare il software.

Un ingegnere del software non ha bisogno di essere un maestro di tutti gli strumenti, ma dovrebbe avere una buona comprensione ad alto livello su ciò che è la maggior parte di loro, ciò che portano in tavola e ciò che sarà probabilmente più appropriato per il progetto dato. Mi aspetterei che una scimmia del codice sia solo un maestro della loro esperienza proclamata in uno strumento specifico.

Non mi fiderei di un ingegnere Ford che non sa come fare il lavoro del meccanico.

Tuttavia, l'ingegneria del software è uno di questi campi in cui in molti casi ci si aspetta che siano l'Ingegnere, il Costruttore e il Meccanico allo stesso tempo.

Sono d'accordo con la persona con cui lavori. Un buon ingegnere del software si occupa dei principi generali di progettazione e produzione del software. Le lingue e i framework attuali sono dettagli.

Questo non significa banalizzare la facilità con cui è possibile acquisire nuovi linguaggi e framework. C'è sempre una curva di apprendimento ad essi associata, ma il punto è che si tratta di una curva, non di un muro verticale per un buon ingegnere del software.

Un buon ingegnere del software ha una vasta esperienza in numerosi strumenti e tecnologie diversi. Se non lo fa, come può scegliere lo strumento migliore per il lavoro? Per tirare fuori il vecchio cliché, per un uomo che sa come usare un martello, ogni problema sembra un chiodo. Anche se non sei un esperto con un cacciavite, vale la pena comprenderle per poter riconoscere una vite non solo come un chiodo dall'aspetto divertente.

Versione TLDR: Altre discipline ingegneristiche hanno bisogno di conoscere i materiali che stanno usando (ad esempio gli architetti devono sapere quanto carico i materiali che stanno usando nel loro design può sopportare ). I linguaggi e le strutture che usiamo per l'ingegneria del software hanno determinati limiti e dobbiamo familiarizzarci con loro per progettare e sviluppare efficacemente contro di loro.

Ci sono due fasi distinte rispetto a ciò che facciamo. Il primo è il design concettuale. Questa è la progettazione di sistemi di alto livello e di basso livello (ad esempio utilizzando UML). I progetti di alto livello possono teoricamente essere indipendenti dall'implementazione (anche se a volte un progetto di alto livello deve prendere in considerazione aspetti come la piattaforma di database, il middleware off-shelf, ecc.). I disegni di basso livello sono un po 'più complicati. È possibile progettare le specifiche della business logic senza inserire i dettagli dell'infrastruttura e, di nuovo, queste possono teoricamente essere indipendenti dalla piattaforma.

La seconda fase è la programmazione vera e propria. Mentre alcuni vedono la programmazione come una costruzione, altri (me compreso) sostengono che la codifica è ancora una disciplina di progettazione (in PPP , Bob Martin si riferisce a un articolo in cui l'autore propone un'ottima argomentazione in tal senso, non ne ho ancora adesso, ma aggiornerò questa risposta con un collegamento a tale articolo). La costruzione vera e propria avviene quando si preme la compilazione ed è in effetti gratuito.

Proprio come un architetto deve prendere in considerazione cose come la resistenza alla trazione e alla compressione dei materiali da costruzione che sta usando, così un ingegnere del software deve conoscere le capacità della piattaforma su cui si stanno sviluppando durante la scrittura del codice. Direi che una progettazione di sistemi di basso livello non è molto efficace se non tiene conto anche delle scelte della piattaforma.

Come qualcuno che si è laureato in un corso di laurea in Ingegneria del software, posso dire che il tuo collega è parzialmente corretto. Un buon ingegnere del software si concentra sull'applicazione di matematica, statistica, informatica e esperienza di dominio per costruire un sistema. I metodi utilizzati da un ingegnere del software sono tipicamente indipendenti dalla tecnologia e dalla lingua: gli strumenti non contano tanto quanto i principi di base.

Detto questo, l'analogia del tuo collega è imperfetta. Comprendere i problemi del dominio è essenziale per qualsiasi disciplina ingegneristica. Se non comprendi pienamente il problema che stai cercando di risolvere e le persone che stai cercando di soddisfare, diventa infinitamente più difficile costruire la migliore soluzione possibile ai loro problemi.

In definitiva, l'ingegneria del software (e qualsiasi disciplina ingegneristica) riguarda l'applicazione di una serie di concetti per risolvere un problema. Se usi frequentemente gli stessi strumenti, diventerai più abile con questi strumenti. Sarà più facile per te identificare i problemi che questi strumenti possono risolvere, i rischi o le insidie nell'usare tali strumenti e quindi utilizzare tali strumenti per costruire una soluzione.

His analogy was that you don't have to have knowledge of the product being built to know how to build an assembly line that manufactures said product.

Questo è quasi certamente errato. I tecnici di produzione specializzati hanno bisogno di capire molto sui prodotti a loro cura.

In ogni caso, una migliore analogia è con i laureati dei corsi di ingegneria meccanica: anche se tutti iniziano (sia in mech che in software) con gli stessi skill, nessuno rimane "un ingegnere meccanico", ma si specializza in i tipi di cose che costruiscono. Allo stesso modo, lo sviluppo del software ha anche sottocampi molto distinti.

Per tornare all'analogia della catena di montaggio, ogni linea di assemblaggio è diversa per ogni prodotto, e diversi tipi di sviluppo del software richiedono diverse metodologie: non costruiresti il tuo software di sicurezza nello stesso modo in cui costruisci un gioco.

C'è una curva di apprendimento coinvolta con diverse specializzazioni. Sto parlando delle differenze tra programmazione embedded / Real-time, programmazione Web-App, programmazione sistemi / OS, programmazione thick-client, sviluppo mobile, ecc.

Qualcuno che è un esperto in un tipo di programmazione potrebbe non essere in grado di attraversare subito un altro a causa di requisiti diversi. Certo, un ingegnere del software ha le basi per farlo, ma ci vuole tempo per specializzarsi in qualcosa.

Sono d'accordo con le premesse suggerite dal collega, anche se aggiungerei un avvertimento.

Un buon ingegnere del software sarà in grado di costruire un buon software in qualsiasi tecnologia ..... dopo aver fatto un po 'di apprendimento con la nuova tecnologia.

Potrebbero esserci alcune stranezze che all'inizio non sono ovvie, ma un buon programmatore di software presto le imparerà.

Penso che quello che intende davvero è che solo perché uno sviluppatore ha 2 anni di esperienza in C # solida, non significa un ingegnere del software migliore con uno sfondo Java, che non ha mai fatto C # prima non poteva venire, imparare C # e diventa rapidamente uno sviluppatore C # migliore del primo.

In altre parole, non devi necessariamente scartare il ragazzo Java per un lavoro, perché ha "fatto il tempo" in C #.

Caso in questione: il framework del software che ritieni sia così importante per avere un'esperienza specializzata con probabilmente non esisteva 10 anni fa, o se ha subito una trasformazione significativa. La natura stessa della nostra professione rende impossibile specializzarsi per la totalità della propria carriera. A seconda dei tuoi rispettivi livelli di abilità, la tua specializzazione ti dà un vantaggio da qualche parte tra 1 e 6 mesi rispetto a qualcuno che non ha mai usato il tuo particolare framework. Dopo, sei alla pari.

Lavoro per una compagnia di elicotteri e gli ingegneri aeronautici qui sono specializzati per i tipi di aeromobili con i quali possono lavorare. Devono essere "classificati". Tecnicamente potevano lavorare su qualsiasi cosa, da un Robinson R22 a un Jumbo Jet, ma non senza l'addestramento alla conversione.

Penso che sia abbastanza simile all'ingegneria del software, tranne per il fatto che il "training di conversione" è più informale per gli ingegneri del software.

Quando parli con un pittore, gli diresti che non avrebbe problemi con la scultura?

Imparare una nuova lingua o specifiche per un nuovo dominio è simile a un artista che si occupa principalmente di matita e inchiostro, imparando a dipingere (o viceversa). Questo è ciò di cui parlano la maggior parte delle altre risposte, come il tuo amico è parzialmente corretto - si applicano molti degli stessi concetti.

Ma insegnare a un pittore come scolpire un oggetto 3D, o scrivere un romanzo (entrambe le forme di espressione artistica) è una bestia completamente diversa. Questo è il punto di vista da cui vieni.

Il software basato sul Web richiede un tipo di pensiero completamente diverso rispetto al software desktop. Entrambi sono completamente diversi se applicati ai giochi rispetto a un ambiente di lavoro. Sospetto che lavorare su un sistema operativo o su sistemi integrati richieda anche di pensare in un modo diverso (ma non ho esperienza con loro). E non ho dubbi che ci sono altri domini che richiedono anche un diverso modo di pensare.

Riepilogo ed esempi:

"Arte" include sculture, romanzi, fumetti e dipinti. Le sovrapposizioni di abilità includono:

• Forma del corpo e teoria del colore: sculture, fumetti e dipinti
• Comunicazione testuale: romanzi e fumetti

... E così via. Ma come detto sopra, è improbabile che un artista comico faccia bene nel suo primo romanzo. Devono pensare in modo diverso.

Allo stesso modo, c'è sovrapposizione in diversi campi di programmazione / ingegneria del software, ma la maggior parte di essi sono troppo distinti per poter semplicemente saltare. Ad esempio:

• Algoritmi: sistemi operativi / integrati, giochi e altri luoghi che è necessario ottimizzare per la velocità o la memoria. Raramente un grosso problema nello sviluppo web
• Design: ovunque nello sviluppo web, ma non molto importante nei sistemi integrati senza interfaccia utente.
• Software client / server: la mentalità "non si fida del cliente", che non esiste necessariamente in alcuni domini (giochi per giocatore singolo e altri software desktop standalone, che ammetto oggi è più raro).

Tutti i lavoratori delle costruzioni stradali sono in grado di utilizzare ogni pezzo di attrezzature e macchinari sul luogo di lavoro? La risposta è no. Ci sono pezzi di macchinari che conoscono e probabilmente conoscono gli altri. Lo stesso dovrebbe valere per gli ingegneri del software, ci x numero di lingue e framework che conosci perché lavori con loro ogni giorno, ma non ci si dovrebbe aspettare che sappiano le operazioni esatte degli altri senza un certo addestramento. È come prendere il lavoratore del martello pneumatico e assegnargli il compito di guidare la betoniera.

I linguaggi di programmazione e i framework sono solo strumenti in una cintura di strumenti dei tecnici del software. Ci sono alcuni strumenti che conoscerai meglio di altri a causa dell'esperienza. In definitiva, lo strumento migliore è la comprensione dei concetti e dei principi fondamentali dell'informatica. Scegliere linguaggi e framework è sufficiente selezionare quale cacciavite utilizzare su quale vite.

Questo genere di cose accade molto dove lavoro.

Mi piace paragonare la professione dello zio di mia moglie - un meccanico di auto.

È specializzato in Mercedes, può applicare le sue conoscenze ad altre marche di automobili, e lo fa - alcune delle quali piuttosto rare, ma ciò non significa che possa immediatamente ripara X, perché dici che sta facendo rumore.

Programma in alcune lingue, ma ciò non significa che io sappia perché Safari sul tuo MacBook ricarica le pagine ogni volta che cambi scheda (la chiamata strana di oggi). Cercherò di capire perché, ma non lo saprò in testa perché il campo di calcolo è ENORME .

In entrambi i casi, dopo aver passato un po 'di tempo a esaminare i nostri rispettivi campi, probabilmente potremmo trovare la risposta, ma non nei dieci secondi che la gente pensa perché "ma lavori con le macchine" o "ma lavori con i computer".

La gente dice cose del genere al proprio medico locale (come "Ho mal di testa che malattia ho?") - Scommetto che lo fanno perché la maggior parte della gente non capisce che c'è molto di più in una professione le loro aspettative immediate di detta professione.