EE vs Ciência da Computação: Efeito nas abordagens e estilos dos desenvolvedores? [fechadas]

Existem diferenças sistemáticas entre os desenvolvedores de software (engenheiros de software, arquiteto, qualquer que seja o cargo) com formação em eletrônica ou outra engenharia, em comparação com aqueles que ingressaram na profissão através da ciência da computação?

Por formação em eletrônica, refiro-me a um diploma de EE, ou a um técnico em eletrônica autodidata, a outros tipos de engenheiros e físicos experimentais.

Pergunto-me se entrar nas profissões de criação de software a partir de um forte conhecimento de flip-flops, buffers tristados, tempos de subida do relógio e assim por diante, geralmente leva a uma abordagem distinta de problemas, mentalidades ou habilidades superiores em determinadas especialidades e carências. de outras habilidades, quando comparadas aos tipos de ciência da computação que estão cheios de conceitos como tipos abstratos de dados, orientação a objetos, normalização de bancos de dados, que falam de "fechamentos" em linguagens de programação - coisas que pouco fazem sentido para a multidão de ferro de solda até que aprenda programação suficiente.

O mundo real, tenho certeza, oferece uma grande variedade de exceções individuais, mas, na maioria das vezes, você pode dizer que existem diferenças gerais? Isso teria implicações na contratação, por exemplo (para inventar algo) "nunca contrate um agitador de elétrons para fazer o design do banco de dados"? O conhecimento de alguma diferença poderia ajudar os candidatos a encontrar algo apropriado de maneira mais eficaz? Ou fornecer esclarecimentos ou alguns conselhos práticos para aqueles que se encontram desajustados em uma função específica no trabalho?

(Aliás, eu nunca tive aulas de ciências da computação; minha impressão exata do que elas cobrem é imprecisa. Eu também sou do tipo eletrônica / física / arte.)

Tendo um EE menor e um CS major, eu trabalhei com os dois grupos academicamente. Eu nunca tive um emprego onde projetei produtos no estilo EE, mas consumi muitos deles trabalhando para empresas com coisas como PLC e, portanto, consegui entender (de uma formação educacional) o que era bom . Portanto, não posso dizer que conheço 100% sobre o comportamento e as características do local de trabalho, mas posso descrever as academicdiferenças entre os dois até certo ponto.

O pessoal de EE tende a se concentrar nos detalhes e a conhecer a implementação exata. Se não é 100% mapeável, eles não gostam. O pessoal da EE irá otimizar para remover detalhes desnecessários, se puderem.

As pessoas do SE tendem a gostar de camadas e compartimentação da lógica. O pessoal da SE não se importa com projetos inchados. As pessoas do SE tendem a ser muito orientadas para a matemática. Eles tendem a pensar em termos de equações e como resolver problemas a partir de um conceito de padrão. As junções são mais intuitivas para esse grupo, como o trabalho de banco de dados. Quanto mais longe você for, mais tenderá a ver pessoas fluentes em coisas como Programação Funcional. Isso simplesmente não é um terreno seguro para uma pessoa de EE.

Ambas as pessoas sabem sobre coisas como mapas de Karnaugh, então há muita sobreposição nessas áreas. Redução lógica, esse tipo de coisa.

Ok, então essa é a minha resposta subjetiva. Espero que ajude.

Se eu tivesse que generalizar, eis a minha experiência:

• Engenheiros (ou apenas EE) tendem a se sair melhor na "perfeição dos pequenos". Dada uma pequena tarefa de programação, eles pensam muito sobre todos os casos extremos e têm mais probabilidade de criar um software muito robusto. Geralmente é orientado a partir de uma abordagem de cima para baixo, projetar tudo de frente, porque é a isso que eles estão acostumados no hardware. Geralmente envolve o uso de máquinas de estado, porque elas estão acostumadas a projetá-las para hardware e se encaixam na abordagem do "grande design". Por outro lado, eles não estão pensando tanto em escalabilidade ou manutenção.

• Seus desenvolvedores tradicionais são melhores no gerenciamento de grande complexidade, principalmente porque o treinamento divide os problemas em bits menores e mais gerenciáveis. Eles são ensinados a evitar o grande design, e apenas separam as preocupações, escrevem testes e fazem os testes passarem. Normalmente, existem muitos casos extremos perdidos, apenas devido à complexidade e ao tempo, mas esses acabam sendo cobertos. Os desenvolvedores tendem a tirar vantagem do fato de ser apenas software e deve ser (ou é) fácil mudar. Quando o EE trabalha com hardware, eles não têm essa vantagem, e acho que leva tempo para fazer a transição.

Como eu disse, essa é a minha experiência generalizada. Não é verdade em todos os casos.

Na minha experiência, os tipos de EE parecem projetar programas lineares e não incorporar as camadas de abstração. Os tipos de CS parecem confortáveis.

Nenhum comentário sobre as diferenças de qualidade ou a falta delas.

Duvido que você veja muita diferença no tipo usual de negócios ou aplicativos da web em que a maioria das pessoas acaba trabalhando, uma vez que ambos têm alguns anos de experiência. Todas as coisas que você lista como confusas para a "multidão do ferro de soldar" são habilidades normais de programação. Em essência, você está respondendo à sua própria pergunta - alguém sem formação em programação pode aprender programação, mas até isso não é um programador. Alguém com uma mente lógica e analítica achará muito mais fácil aprender a programar bem do que alguém que não o faça - essa seria a única vantagem que posso pensar em um consertador eletrônico autodidata.

A Ciência da Computação (em oposição à Engenharia da Computação) é predominantemente matemática, pois (nos níveis mais altos) são as várias outras ciências, como a física - mas é um tipo muito diferente de matemática. Se você fez uma ciência diferente, também terá feito matemática e, portanto, deve ser possível se atualizar, ao contrário de alguém que não tem formação em matemática. Certamente, muito poucos programadores realmente precisam saber sobre teoria dos conjuntos, big-O ou qualquer outra coisa - certamente não em alto nível.

Comecei com um BSEE, comecei a trabalhar no projeto de circuitos lógicos para um grande laboratório de pesquisa e desenvolvimento por telefone e (isso foi há cerca de 40 anos) percebi que a maior parte do que eu estava construindo poderia eventualmente ser feita com um programa de computador. Então voltei e me formei em MSCS.

Eu sempre me interessei pela arquitetura de computadores e pelo que acontece no nível do hardware. Passei a maior parte da minha carreira projetando sistemas de microcontroladores incorporados, onde tento encontrar a melhor correspondência entre o que é feito no hardware e o que é feito no firmware. No entanto, eu fiz bastante programação na Web e algum design de banco de dados.

Sem minha formação em CS, acho que teria muito mais dificuldade em entender conceitos mais abstratos. Além de muitas linguagens assembler diferentes, usei C, C ++, C #, Pascal, Delphi, Perl, PHP e alguns Lisp. Atualmente, estou tentando aprender Ruby e Python. Design OO com o qual estou bastante confortável. Programação funcional Eu não sou (ainda).

O mesmo para bancos de dados. Eu entendo normalização. Tenho problemas com alguns dos JOINs mais esotéricos e os evito. Eu não estou realmente confortável com algo, a menos que eu entenda o que está acontecendo sob o capô.

Quero poder "ver" como o computador executaria o programa na minha cabeça.