¿Qué extrañé al no estudiar CS o CE como desarrollador de software? Estudié química y física, aprendí programación en el trabajo (C ++, Phython, un poco C #). Soy bueno en el procesamiento de imágenes y estoy trabajando a tiempo completo con sistemas HMI. ¿Qué me perdí?

Me gustaría ampliar ligeramente la pregunta y ampliar algunos de los diferentes caminos que podría haber tomado. Primero, dependiendo de lo que quiera decir con química y física estudiadas, podría haber comenzado con más o menos relevancia para su ocupación prevista. Además, el grado objetivo con el que te estás comparando también es importante. Los grados CS y CSE varían mucho. De hecho, usted dice “Desarrollador de software”, que podría estar más cerca de un título de Ingeniería de software de algunas escuelas. También supongo que estás hablando de comparar títulos universitarios.

Si comenzaste desde un entorno más matemático donde resolviste problemas de forma estructurada, te resultará mucho más fácil aprender los aspectos más finos de la informática, la ingeniería del software o ser un desarrollador de software. El pensamiento metódico es importante para analizar algoritmos, pensar en problemas de diseño, depuración, etc. Los lugares en los que se encuentra pueden estar un poco ciegos a lo que no conoce implican análisis de complejidad y problemas de software a mayor escala.

Si está apuntando a la informática, entonces deberá subir una colina más empinada. Los detalles sobre la teoría no serán tan fáciles de intuir a partir de su educación anterior. Probablemente debería mirar los currículos de ACM y trabajar a través de los temas (Recomendaciones de currículos). Pero si está apuntando a ser un desarrollador, entonces su experiencia en la resolución de problemas debería ayudarlo a subir la primera parte de la curva de aprendizaje con mayor facilidad. Sin embargo, tenga en cuenta que muchos temas que parecen poco profundos son realmente profundos. Le animo a profundizar en la arquitectura de software, las metodologías de prueba y varios paradigmas de programación. Amplíe lo suficiente para que pueda ver la falta de balas de plata y evitar a sus vendedores. También profundice en los paradigmas que usa día a día. Algunos de estos se esconderán a plena vista. Regularmente veo a los ingenieros de software confundirse al comprender la teoría de Codd porque simplemente pueden arrojar algo de SQL a un problema. Usando esto como ejemplo, la simplicidad de aprender SQL oculta la profundidad de comprensión que se necesita para hacer un buen modelado de datos. Existen problemas similares en la programación orientada a objetos. También debe intentar aprender los rudimentos de cómo funcionan realmente las máquinas. Puede parecer una tontería en ese momento, pero intente escribir un par de programas en ensamblador, escriba un simple compilador y comprenda cómo encaja todo. Eso se amortizará una y otra vez al tratar de comprender los problemas a nivel de sistemas.

Considere esta línea de código de la prueba de Kolmogorov-Smirnov implementada en R:

z <- cumsum(ifelse(order(w) <= nx, 1/nx, -1/ny))

Esperaría que tanto un programador autodidacta como con formación universitaria sea capaz de descubrir que "cumsum" significa "suma acumulativa", "ifelse" se explica por sí mismo y "orden" "devuelve una permutación que reorganiza su primer argumento en orden ascendente o descendente ".

No esperaría que el programador autodidacta pueda saber de inmediato qué parte de ese cálculo tomaría más tiempo y aproximadamente cómo aumentaría el tiempo de ejecución a medida que aumenta la longitud del vector w . Eso debería ser obvio para alguien que tenga una formación formal en algoritmos.

Dificil de decir.

Como programador autodidacta, pertenezco al grupo que descubrió que el problema de Barry Rountree sobre qué elemento de la declaración tardaría más en ejecutarse es intuitivamente simple.

Dado lo coloreado que está la experiencia personal de la autoaprendizaje, hay tantas respuestas a esta pregunta como personas autodidactas.

Si hubiera una tendencia, estaría dispuesto a formular una hipótesis: si asignamos un valor escalar al “conocimiento total” de uno, apuesto a que la variación en el conocimiento de los desarrolladores autodidactas es mucho mayor, con una media potencialmente algo menor.

Diría que probablemente no te perdiste nada que te impida ser un buen desarrollador y aprenderlo más tarde. Lo que podría haberse perdido fue la inmensidad de Ciencias de la Computación / Ingeniería y la capacidad de explicar aproximadamente todo el conjunto de computadoras, lo que tiene sus beneficios (supongo) en cómo aborda la programación.

La capacidad de explicar un botón que ve en su navegador y todo hasta la frecuencia analógica que representa un 0 o 1 digital para la comprensión de su procesador es mucho … UX, idiomas, teoría de computadoras, compiladores, bases de datos, redes, arquitectura de procesador, máquina El aprendizaje, el ensamblaje y los sistemas operativos son solo algunos de los muchos temas en los que es posible que no se haya sumergido cuando solo aprendió programación en el trabajo. Hace que te des cuenta de que la programación es (aunque la base) pero una pequeña parte del mundo de la informática.

Cierre

No estudiar CS solo te permite aprender la superficie concreta de lo que es un cierre. Es posible que tenga dificultades para comprender la diferencia entre cierre, devoluciones de llamada y función anónima. Esto es algo que te perdiste.

Pila de llamadas

Puede saber qué es un seguimiento de pila, pero tendrá dificultades para comprender cómo las funciones se invocan entre sí y cómo la recursión provoca errores de desbordamiento de pila. Debido a esta falta de conocimiento, puede causar problemas para la transición a lenguajes de programación funcionales que no tienen una pila.

Ética

No puedes enseñarte ética. Tu acción tiene consecuencias en la vida de las personas. Sus usuarios confían en usted con sus datos personales e información de identidad. Estos pueden ser robados. Tienes responsabilidad social con tus usuarios.

Te perdiste algoritmos y patrones de diseño. Te perdiste muchas cosas teóricas que probablemente no usarás en tu trabajo diario como desarrollador, pero que podrían ser útiles dependiendo de tu trabajo. Sin embargo, en general, no se perdió mucho que se relacionará directamente con su trabajo como desarrollador que no puede aprender por su cuenta.

Probablemente se haya perdido el pago de mucho dinero y perder el tiempo en un aula aprendiendo cosas que son demasiado académicas y teóricas que no recordará 3 años después.