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

Lavoro con qualcuno che insiste sul fatto che qualsiasi buon ingegnere del software può svilupparsi in qualsiasi tecnologia software e l'esperienza in una particolare tecnologia non ha importanza per la costruzione di un buon software. La sua analogia era che non devi avere conoscenza del prodotto in costruzione per sapere come costruire una catena di montaggio che fabbrica tale prodotto.

In un certo senso è un complimento essere visto con un occhio tale che "se sei bravo, sei bravo in tutto", ma in un certo senso banalizza anche la professione, come in "Codemonkey, vai al codice dell'imbragatura". Senza esperienza in determinati framework software, puoi metterti nei guai velocemente e questo è importante.

Ho provato a spiegarlo, ma non l'ha comprato. Qualche diverso punto di vista o pensieri su questo per aiutare a spiegare che la mia esperienza in una cosa, non si traduce in tutte le cose?

ma in un certo senso banalizza anche la professione, come in "Codemonkey, vai al codice dell'imbracatura".

Direi il contrario. Un buon ingegnere del software avrebbe la capacità di concettualizzare, progettare e progettare agnostici di tecnologia di qualità. L'estremità opposta di questo spettro è solo "codemonkey" .NET o Java o PHP 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 conoscenza abbastanza buona di alto livello su ciò che è la maggior parte di loro, ciò che portano sul tavolo e ciò che sarà probabilmente più appropriato per il progetto dato . Mi aspetterei che una scimmia codice sia solo un maestro della loro proclamata esperienza 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 le strutture attuali sono dettagli.

Questo non per banalizzare la facilità con cui è possibile acquisire nuove lingue e framework. C'è sempre una curva di apprendimento associata a loro, ma il punto è che è una curva, non una parete verticale per un buon ingegnere del software.

Un buon ingegnere del software ha una vasta gamma di esperienze in una serie di strumenti e tecnologie diverse. In caso contrario, come può scegliere lo strumento migliore per il lavoro? Per far uscire il vecchio cliché, per un uomo che sa usare un martello, ogni problema sembra un chiodo. Anche se non sei un esperto con un cacciavite, vale la pena avere una comprensione passante di loro in modo da poter riconoscere una vite come non solo un chiodo dall'aspetto divertente.

Versione TLDR: altre discipline ingegneristiche necessitano della conoscenza dei materiali che stanno utilizzando (ad es. Gli architetti devono sapere quanto carico possono sopportare i materiali che stanno utilizzando nella loro progettazione ). I linguaggi e le strutture che utilizziamo per l'ingegneria del software hanno determinati limiti e dobbiamo conoscerli per progettare e sviluppare in modo efficace contro di essi.

Ci sono due fasi distinte in ciò che facciamo. Il primo è il design concettuale. Questa è la progettazione di sistemi di alto e basso livello (ad es. Usando UML). I progetti di alto livello possono teoricamente essere agnostici rispetto all'implementazione (anche se a volte un progetto di alto livello deve tener conto di specifiche quali piattaforma di database, middleware standard, ecc.). I progetti di basso livello sono un po 'più complicati. È possibile progettare le specifiche della logica aziendale senza inserirvi i dettagli dell'infrastruttura e, di nuovo, questi possono teoricamente essere indipendenti dalla piattaforma.

La seconda fase è la programmazione effettiva. Mentre alcuni considerano la programmazione come costruzione, altri (incluso me) sostengono che la codifica sia ancora una disciplina di progettazione (in PPP , Bob Martin si riferisce a un articolo in cui l'autore propone un ottimo argomento in tal senso, non ce l'ho con ora, ma aggiornerò questa risposta con un link a quell'articolo). La costruzione effettiva avviene quando si preme compilazione ed è in effetti libera.

Proprio come un architetto deve tenere conto di cose come la resistenza a trazione e compressione dei materiali da costruzione che sta usando, così un ingegnere del software deve conoscere le capacità della piattaforma contro cui 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 della matematica, delle statistiche, dell'informatica e dell'esperienza del dominio al fine di costruire un sistema. I metodi che utilizza un ingegnere del software sono in genere tecnologia e linguaggio agnostico: gli strumenti non contano tanto quanto i principi sottostanti.

Detto questo, l'analogia del tuo collega è imperfetta. Comprendere i problemi del dominio è essenziale per qualsiasi disciplina ingegneristica. Se non capisci completamente 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 spesso gli stessi strumenti, diventerai più abile con quegli strumenti. Sarà più facile per voi identificare i problemi che tali strumenti possono risolvere, i rischi o le insidie ​​nell'uso di tali strumenti e quindi nell'utilizzare quegli strumenti per costruire una soluzione.

La sua analogia era che non devi avere conoscenza del prodotto in costruzione per sapere come costruire una catena di montaggio che fabbrica tale prodotto.

Questo è quasi certamente errato. Gli ingegneri di produzione specializzati devono capire molto sui prodotti a loro affidati.

In ogni caso, un'analogia migliore è con i laureati dei corsi di ingegneria meccanica: anche se tutti iniziano (sia in mech che in software) con le stesse abilità, nessuno rimane "un ingegnere meccanico", ma invece è specializzato nei 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 catena di montaggio è diversa per ogni prodotto e diversi tipi di sviluppo software richiedono metodologie diverse: 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 di differenze tra programmazione Embedded / Real-time, programmazione App Web, programmazione Sistemi / SO, programmazione Thick-client, sviluppo mobile, ecc.

Qualcuno che è un esperto in un tipo di programmazione potrebbe non essere in grado di passare immediatamente a 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.

Concordo con la premessa suggerita dal tuo 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 delle stranezze che all'inizio non sono ovvie, ma un buon ingegnere del software le imparerà presto.

Penso che ciò che significhi davvero sia che solo perché uno sviluppatore ha 2 anni di solida esperienza in C #, ciò non significa che un ingegnere del software migliore con un background Java, che non ha mai fatto C # prima non potrebbe venire, imparare C # e rapidamente diventare uno sviluppatore C # migliore del primo ragazzo.

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

Caso in questione: il framework software che ritieni sia così critico da 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 l'intera carriera. A seconda dei rispettivi livelli di abilità, la tua specializzazione ti dà un vantaggio per un periodo compreso tra 1 e 6 mesi rispetto a qualcuno che non ha mai usato il tuo particolare framework. Dopodiché, sei alla pari.

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

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

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

Imparare una nuova lingua o le specifiche di un nuovo dominio è simile a un artista che si occupa principalmente di matita e inchiostro, imparando a dipingere (o viceversa). Questo è ciò di cui parla la maggior parte delle altre risposte, in che modo 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 sul fatto che ci siano altri domini che richiedono anche un diverso modo di pensare.

Riepilogo ed esempi:

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

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

... E così via. Ma come accennato in precedenza, è improbabile che un artista di fumetti faccia bene il loro primo romanzo. Devono pensare diversamente.

Allo stesso modo, ci sono sovrapposizioni in diversi campi della programmazione / ingegneria del software, ma la maggior parte di essi è troppo distinta per poter semplicemente saltare. Ad esempio:

• Algoritmi: SO / sistemi integrati, giochi e altri luoghi che è spesso necessario ottimizzare per velocità o 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 fidarti del client", che non esiste necessariamente in alcuni domini (giochi per giocatore singolo e altri software desktop autonomi, che ammetto sia più raro in questi giorni).

Tutti i lavoratori delle costruzioni stradali sono in grado di utilizzare ogni attrezzatura e macchinario sul posto di lavoro? La risposta è no. Ci sono macchinari che conoscono e probabilmente hanno familiarità con gli altri. Lo stesso dovrebbe valere per gli ingegneri del software, ci sono un numero x di lingue e framework che conosci perché lavori con loro ogni giorno, ma non ci si dovrebbe aspettare che conoscano le esatte operazioni di altri senza una certa formazione. È 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 nella cintura degli strumenti di un ingegnere 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 le lingue e le strutture è semplicemente selezionare quale cacciavite utilizzare su quale vite.

Questo genere di cose succede molto dove lavoro.

Mi piace confrontarmi con la professione di zio di mia moglie, un meccanico di automobili.

È specializzato in Mercedes, può applicare le sue conoscenze ad altre marche di automobili, e lo fa - alcune piuttosto rare, ma ciò non significa che possa riparare immediatamente X perché si dice che fa rumore.

Programma in alcune lingue, ma ciò non significa che so perché Safari sul tuo MacBook ricarica le pagine ogni volta che cambi scheda (strana chiamata di oggi). Proverò a capire perché, ma non lo saprò dalla testa perché il campo di elaborazione è ENORME .

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

Le persone dicono cose del genere al loro medico locale (come "Ho un mal di testa quale malattia ho?") - Scommetto che lo fanno perché la maggior parte delle persone non capisce davvero che in ogni professione c'è qualcosa di più delle loro aspettative immediate di detta professione.