Como você explicaria que a engenharia de software é mais especializada que outras áreas de engenharia? [fechadas]

Eu trabalho com alguém que insiste em que qualquer bom engenheiro de software possa se desenvolver em qualquer tecnologia de software, e a experiência em uma tecnologia específica não importa para criar um bom software. Sua analogia era que você não precisa ter conhecimento do produto que está sendo construído para saber como construir uma linha de montagem que fabrica o produto.

De certa forma, é um elogio ser visto com olhos de tal forma que "se você é bom, você é bom em tudo", mas de certa forma também banaliza a profissão, como em "Codemonkey, vá sling code". Sem experiência em certas estruturas de software, você pode ter problemas rapidamente, e isso é importante.

Eu tentei explicar isso, mas ele não comprou. Alguma opinião ou opinião diferente sobre isso para ajudar a explicar que minha experiência em uma coisa não se traduz em todas as coisas?

mas de certa forma também banaliza a profissão, como em "Codemonkey, vá sling code".

Eu argumentaria bem o oposto. Um bom engenheiro de software teria a capacidade de conceituar, arquitetar e projetar software de qualidade independente da tecnologia. O extremo oposto desse espectro é apenas o "codemonkey" do .NET ou Java ou PHP, que é bom para receber instruções ou especificações e utilizar a ferramenta para implementar o software.

Um engenheiro de software não precisa dominar todas as ferramentas, mas deve ter um bom entendimento de alto nível sobre o que a maioria delas é, o que elas trazem para a mesa e o que provavelmente será mais apropriado para o projeto em questão. . Eu esperaria que um macaco de código fosse apenas um mestre de sua experiência proclamada em uma ferramenta específica.

Eu não confiaria em um engenheiro da Ford que não sabe fazer o trabalho do mecânico.

Ainda assim, a engenharia de software é um desses campos em que, em muitos casos, devemos ser o engenheiro, o construtor e o mecânico, tudo ao mesmo tempo.

Eu concordo até certo ponto com a pessoa com quem você trabalha. Um bom engenheiro de software lida com os princípios gerais de design e produção de software. As linguagens e estruturas reais são detalhes.

Isso não é trivializar a facilidade com que você pode pegar novas linguagens e estruturas. Sempre há uma curva de aprendizado associada a elas, mas o ponto é que é uma curva, não uma parede vertical para um bom engenheiro de software.

Um bom engenheiro de software tem uma ampla gama de experiência em várias ferramentas e tecnologias diferentes. Se não, como ele pode escolher a melhor ferramenta para o trabalho? Para expulsar o velho clichê, para um homem que sabe usar um martelo, todo problema parece um prego. Mesmo que você não seja um especialista em uma chave de fenda, vale a pena ter uma compreensão passageira deles, para que você possa reconhecer um parafuso como não apenas uma unha de aparência engraçada.

Versão TLDR: Outras disciplinas de engenharia precisam conhecer os materiais que estão usando (por exemplo, os arquitetos precisam saber quanta carga os materiais que estão usando em seu design podem suportar ). As linguagens e estruturas que usamos para engenharia de software têm certos limites e precisamos estar familiarizados com eles para projetar e desenvolver efetivamente contra eles.

Existem duas fases distintas no que fazemos. O primeiro é o design conceitual. Esse é o design do sistema de alto e baixo nível (por exemplo, usando UML). Projetos de alto nível podem teoricamente ser agnósticos de implementação (embora algumas vezes um projeto de alto nível precise levar em consideração especificações como plataforma de banco de dados, middleware de prateleira etc.). Projetos de baixo nível são um pouco mais complicados. Você pode projetar as especificidades da lógica de negócios sem colocar os detalhes da infraestrutura nelas e, novamente, elas podem teoricamente ser independentes de plataforma.

A segunda fase é a programação real. Enquanto alguns veem a programação como construção, outros (inclusive eu) argumentam que a codificação ainda é uma disciplina de design (no PPP , Bob Martin se refere a um artigo em que o autor apresenta um argumento muito bom para esse efeito, não o tenho com agora, mas atualizarei esta resposta com um link para esse artigo). A construção real acontece quando você pressiona compilar e, na verdade, é livre.

Assim como um arquiteto precisa levar em conta coisas como resistência à tração e à compressão dos materiais de construção que está usando, o engenheiro de software também precisa conhecer os recursos da plataforma em que está desenvolvendo ao escrever código. Eu argumentaria que um design de sistema de baixo nível não é muito eficaz se não levar em consideração as opções de plataforma também.

Como alguém que se formou em um programa de graduação em Engenharia de Software, posso dizer que seu colega de trabalho está parcialmente correto. Um bom engenheiro de software se concentra na aplicação de matemática, estatística, ciência da computação e experiência no domínio para construir um sistema. Os métodos que um engenheiro de software usa são tipicamente independentes da tecnologia e da linguagem - as ferramentas não importam tanto quanto os princípios subjacentes.

Dito isto, a analogia do seu colega de trabalho é falha. A compreensão dos problemas do domínio é essencial para qualquer disciplina de engenharia. Se você não entende completamente o problema que está tentando resolver e as pessoas que está tentando satisfazer, torna-se infinitamente mais difícil criar a melhor solução possível para os problemas deles.

Por fim, a engenharia de software (e qualquer disciplina de engenharia) trata da aplicação de vários conceitos para resolver um problema. Se você costuma usar as mesmas ferramentas, ficará mais experiente com essas ferramentas. Será mais fácil para você identificar os problemas que essas ferramentas podem resolver, os riscos ou armadilhas com o uso dessas ferramentas e depois usá-las para construir uma solução.

Sua analogia era que você não precisa ter conhecimento do produto que está sendo construído para saber como construir uma linha de montagem que fabrica o produto.

Isso quase certamente está incorreto. Os engenheiros de produção especializados precisam entender bastante sobre os produtos sob seus cuidados.

De qualquer forma, uma analogia melhor é com os formandos dos cursos de engenharia mecânica: mesmo que todo mundo comece (tanto em mech quanto em software) com as mesmas habilidades, ninguém permanece "um engenheiro mecânico", mas é especialista nos tipos de coisas que eles constroem. Da mesma forma, o desenvolvimento de software também possui subcampos muito distintos.

Para retornar à analogia da linha de montagem, cada linha de montagem é diferente para cada produto, e diferentes tipos de desenvolvimento de software exigem metodologias diferentes - você não criaria seu software de segurança da mesma maneira que cria um jogo.

Há uma curva de aprendizado envolvida com diferentes especializações. Eu estou falando sobre diferenças entre programação Embedded / em tempo real, programação de aplicativos da Web, programação de sistemas / SO, programação de clientes espessos, desenvolvimento móvel, etc.

Alguém que é especialista em um tipo de programação pode não conseguir passar para outro imediatamente por causa de requisitos diferentes. Claro, um engenheiro de software tem o básico para fazer isso, mas leva tempo para se especializar em algo.

Concordo com a premissa que seu colega sugere, embora eu acrescentasse uma ressalva.

Um bom engenheiro de software será capaz de criar um bom software em qualquer tecnologia ..... depois de aprender um pouco sobre a nova tecnologia.

Pode haver algumas peculiaridades que não são óbvias a princípio, mas um bom engenheiro de software as aprenderá em breve.

Eu acho que o que ele realmente quer dizer é que, só porque um desenvolvedor tem 2 anos de experiência sólida em C #, não significa um engenheiro de software melhor com experiência em Java, que nunca fez C # antes não poderia aparecer, aprender C # e rapidamente torne-se um desenvolvedor de C # melhor que o primeiro.

Em outras palavras, você não deve necessariamente desconsiderar o cara Java por um emprego, APENAS porque ele "fez o tempo" em C #.

Caso em questão: a estrutura de software que você considera essencial para ter experiência especializada provavelmente não existia 10 anos atrás ou sofreu uma transformação significativa, se existir. A própria natureza de nossa profissão torna impossível se especializar durante toda a carreira. Dependendo dos seus respectivos níveis de habilidade, sua especialização oferece uma vantagem entre 1 e 6 meses em relação a alguém que nunca usou sua estrutura específica. Depois disso, você está no mesmo nível.

Eu trabalho para uma empresa de helicópteros e os engenheiros de aviação aqui são especializados pelo tipo de aeronave com a qual podem trabalhar. Eles precisam ser "classificados como". Tecnicamente, eles poderiam trabalhar em qualquer coisa, de um Robinson R22 a um Jumbo Jet, mas não sem o treinamento de conversão.

Eu acho que isso é bastante semelhante à engenharia de software, exceto que o "treinamento de conversão" é mais informal para os engenheiros de software.

Ao conversar com um pintor, você diria a ele que ele não teria problemas com a escultura?

Aprender um novo idioma ou especificidades para um novo domínio é semelhante a um artista que lida principalmente com lápis e tinta, aprendendo a pintar (ou vice-versa). É sobre isso que a maioria das outras respostas está falando, como seu amigo está parcialmente correto - muitos dos mesmos conceitos se aplicam.

Mas ensinar um pintor a esculpir um objeto 3D ou escrever um romance (Ambas as formas de expressão artística) é um animal completamente diferente. Esse é o ponto de vista de onde você vem.

O software baseado na Web requer um tipo de pensamento totalmente diferente do software de desktop. Ambos são completamente diferentes quando aplicados a jogos versus um ambiente de trabalho. Eu suspeito que trabalhar em um sistema operacional ou em sistemas integrados também exija pensar de uma maneira diferente (mas não tenho experiência com eles). E não tenho dúvida de que existem outros domínios que também exigem uma maneira diferente de pensar.

Resumo e exemplos:

"Arte" inclui esculturas, romances, quadrinhos e pinturas. As sobreposições de habilidades incluem:

• Forma corporal e teoria das cores: esculturas, quadrinhos e pinturas
• Comunicação textual: romances e quadrinhos

... E assim por diante. Mas, como mencionado acima, é improvável que um artista de quadrinhos faça bem em seu primeiro romance. Eles precisam pensar de maneira diferente.

Da mesma forma, há sobreposição em diferentes campos da engenharia de programação / software, mas a maioria deles é muito distinta para ser capaz de entrar. Por exemplo:

• Algoritmos: sistemas operacionais / jogos integrados, jogos e outros locais que você geralmente precisa otimizar para velocidade ou memória. Raramente um grande negócio em desenvolvimento web
• Design: em qualquer lugar do desenvolvimento da Web, mas não muito importante em sistemas integrados sem uma interface do usuário.
• Software cliente / servidor: a mentalidade "não confie no cliente", que não existe necessariamente em alguns domínios (jogos para um jogador e outro software de desktop independente, que, admito, é mais raro atualmente).

Todos os trabalhadores da construção de estradas podem usar todos os equipamentos e máquinas no local de trabalho? A resposta é não. Existem peças de máquinas que eles conhecem e provavelmente estão familiarizadas com as outras. O mesmo deve ser verdadeiro para os engenheiros de software, há um número de idiomas e estruturas que você conhece porque trabalha com eles todos os dias, mas não se deve esperar que saibam as operações exatas de outras pessoas sem algum treinamento. É como pegar o trabalhador da britadeira e atribuir a ele a tarefa de dirigir o misturador de cimento.

Linguagens e estruturas de programação são apenas ferramentas no cinto de ferramentas de engenheiros de software. Existem algumas ferramentas que você conhecerá melhor do que outras por causa da experiência. Por fim, a melhor ferramenta é entender os principais conceitos e princípios da computação. Escolher idiomas e estruturas é apenas selecionar qual chave de fenda usar em qual parafuso.

Esse tipo de coisa acontece muito onde eu trabalho.

Eu gosto de comparar com a profissão do tio da minha esposa - um mecânico de automóveis.

Ele é especialista em Mercedes, ele pode aplicar seu conhecimento a outras marcas de carros, e ele faz - alguns deles bastante raros, mas isso não significa que ele possa reparar imediatamente o X, porque você diz que está fazendo barulho.

Eu programo em alguns idiomas, mas isso não significa que eu sei por que o Safari no seu MacBook recarrega as páginas toda vez que você muda de guia (chamada estranha de hoje). Vou tentar descobrir o porquê, mas não vou saber de nada, porque o campo da computação é ENORME .

Nos dois casos, depois de passar algum tempo analisando nossos respectivos campos, provavelmente poderíamos encontrar a resposta, mas não nos dez segundos que as pessoas pensam porque "mas você trabalha com carros" ou "mas você trabalha com computadores".

As pessoas dizem essas coisas ao médico local (como "Estou com dor de cabeça, que doença tenho?") - aposto que sim, porque a maioria das pessoas realmente não entende que existe mais em qualquer profissão do que as expectativas imediatas. da referida profissão.