EE vs Informática: ¿Efecto en los enfoques y estilos de los desarrolladores? [cerrado]

¿Hay alguna diferencia sistemática entre los desarrolladores de software (ingenieros de ingeniería, arquitectos, cualquier título de trabajo) con experiencia en electrónica u otra ingeniería, en comparación con los que ingresaron a la profesión a través de la informática?

Por experiencia en electrónica, me refiero a un título de EE, o un ingeniero electrónico autodidacta, otros tipos de ingenieros y físicos experimentales.

Me pregunto si entrar en las profesiones de creación de software a partir de un sólido conocimiento de chanclas, amortiguadores de estado, tiempos de subida del borde del reloj, etc., por lo general conduce a un enfoque distinto de los problemas, mentalidades o habilidades superiores en ciertas especialidades y falta de habilidades en otros, en comparación con los tipos de informática que están llenos de conceptos como tipos de datos abstractos, orientación a objetos, normalización de bases de datos, que hablan de "cierres" en lenguajes de programación, cosas que tienen poco sentido para la multitud de soldadores hasta que Aprende suficiente programación.

El mundo real, estoy seguro, ofrece una amplia gama de excepciones individuales, pero en su mayor parte, ¿puede decir que hay diferencias generales? ¿Tendrían estas implicaciones de contratación, por ejemplo (para inventar algo) "nunca contratar a un experto en electrones para hacer el diseño de la base de datos"? ¿Conocer las diferencias podría ayudar a los solicitantes de empleo a encontrar algo apropiado de manera más efectiva? ¿O proporcionar iluminación o algún consejo práctico para aquellos que se encuentran inadaptados en un puesto de trabajo en particular?

(Por cierto, nunca he tomado ninguna clase de ciencias de la computación; mi impresión de exactamente lo que cubren es confusa. Soy un tipo de electrónica / física / arte, yo mismo).

Teniendo un EE menor y un CS mayor, he trabajado con ambos grupos académicamente. Nunca he tenido un trabajo en el que diseñé productos de estilo EE, pero los he consumido haciendo trabajo para empresas con cosas como PLC, y así he podido entender (desde un entorno educativo) lo que sucedió fue agradable . Por lo tanto, no puedo decir que sé 100% sobre el comportamiento y las características del lugar de trabajo, pero puedo describir las academicdiferencias entre los dos hasta cierto punto.

Las personas de EE tienden a centrarse en los detalles y tienden a conocer la implementación exacta. Si no es 100% mapeable, no les gusta. La gente de EE optimizará hacia abajo para eliminar detalles innecesarios si pueden.

A la gente SE le gustan las capas y la compartimentación de la lógica. La gente de SE no les importa los proyectos hinchados. Las personas SE tienden a estar muy orientadas a las matemáticas. Tienden a pensar en términos de ecuaciones y cómo resolver problemas desde un concepto de patrón. Las uniones son más intuitivas para este grupo, como el trabajo de base de datos. Cuanto más avanzas en la SE, más tiendes a ver personas que dominan cosas como la programación funcional. Eso no es un terreno seguro para una persona de EE.

Ambas personas conocen cosas como los mapas de Karnaugh, por lo que hay mucha superposición en esas áreas. Reducción lógica, ese tipo de cosas.

Ok, esa es mi respuesta subjetiva. Espero eso ayude.

Si tuviera que generalizar, aquí está mi experiencia:

• Los ingenieros (o simplemente EE) tienden a mejorar en la "perfección de lo pequeño". Dada una pequeña tarea de programación, piensan mucho y mucho sobre todos los casos extremos, y es más probable que terminen construyendo un software que sea muy robusto. Por lo general, se maneja desde un enfoque de diseño descendente de arriba hacia abajo, porque eso es a lo que están acostumbrados en el hardware. Por lo general, implica el uso de máquinas de estado, porque están acostumbradas a diseñarlas para hardware, y encaja con el enfoque de "gran diseño". Por otro lado, no están pensando tanto en la escalabilidad o la capacidad de mantenimiento.

• Sus desarrolladores tradicionales son mejores en la gestión de grandes complejidades, principalmente porque la capacitación empuja la descomposición de los problemas en partes más pequeñas y manejables. Se les enseña a evitar el gran diseño y a separar las preocupaciones, escribir pruebas y hacer que las pruebas pasen. Por lo general, hay muchos pequeños casos límite perdidos, solo debido a la complejidad y el tiempo, pero finalmente se cubren. Los desarrolladores tienden a aprovechar el hecho de que es solo software y debería ser (o es) fácil de cambiar. Cuando EE trabaja con hardware, no tienen esta ventaja, y creo que lleva tiempo hacer la transición.

Como dije, esa es mi experiencia generalizada. No es cierto en todos los casos.

En mi experiencia, los tipos de EE parecen diseñar programas lineales y no incorporar las capas de abstracción con las que los tipos de CS se sienten cómodos.

No hay comentarios sobre las diferencias de calidad o la falta de ellas.

Dudo que vea mucha diferencia en el tipo habitual de negocios o aplicaciones web en las que la mayoría de las personas terminan trabajando, una vez que ambos tienen algunos años de experiencia. Todas las cosas que enumeras como confusas para la "multitud de soldadores" son habilidades normales de programación. En esencia, está respondiendo su propia pregunta: alguien sin experiencia en programación puede aprender programación, pero hasta que lo haga, no será un programador. A alguien con una mente lógica y analítica le resultará mucho más fácil aprender a programar bien que alguien que no lo haga; esa sería la única ventaja que puedo pensar para un ingeniero electrónico autodidacta.

La informática (a diferencia de la ingeniería informática) es predominantemente matemática, ya que (en los niveles superiores) se encuentran las otras ciencias, como la física, pero es un tipo de matemática muy diferente. Si has hecho una ciencia diferente, entonces también habrás hecho matemáticas y, por lo tanto, deberías poder ponerte al día a diferencia de alguien que no tenga experiencia en matemáticas. Por supuesto, muy pocos programadores realmente necesitan saber acerca de la teoría de conjuntos, big-O, o cualquier otra cosa, ciertamente no de un nivel alto de todos modos.

Comencé con un BSEE, trabajé diseñando circuitos lógicos para un gran laboratorio de I + D telefónico y (esto fue hace unos 40 años) me di cuenta de que la mayor parte de lo que estaba construyendo podría hacerse con un programa de computadora. Así que volví y obtuve un título de MSCS.

Siempre me ha interesado la arquitectura de computadoras y lo que sucede a nivel de hardware. La mayor parte de mi carrera la he pasado diseñando sistemas integrados de microcontroladores, donde trato de encontrar la mejor combinación entre lo que se hace en hardware y lo que se hace en firmware. Sin embargo, he realizado bastante programación web y algunos diseños de bases de datos.

Sin mi experiencia en CS, creo que tendría muchos más problemas para comprender conceptos más abstractos. Además de muchos lenguajes de ensamblador diferentes, he usado C, C ++, C #, Pascal, Delphi, Perl, PHP y algunos Lisp. Actualmente estoy tratando de aprender Ruby y Python. OO diseño con el que estoy bastante cómodo. Programación funcional no lo soy (todavía).

Lo mismo para las bases de datos. Entiendo la normalización. Tengo problemas con algunas de las uniones más esotéricas y las evito. No estoy realmente cómodo con algo a menos que entienda lo que está sucediendo debajo del capó.

Quiero poder "ver" cómo la computadora ejecutaría el programa en mi cabeza.