¿Diferencias entre la programación en la escuela y la programación en la industria? [cerrado]

Muchos de los estudiantes cuando se gradúan y obtienen su primer trabajo sienten que realmente no saben programar aunque hayan sido buenos programadores en la universidad.

¿Cuáles son algunas de las diferencias entre programar en un entorno académico y programar en el "mundo real"?

En un programa tradicional de ciencias de la computación, solo aprendes programación. Pero el mundo real no quiere personas que solo sean programadores. El mundo real quiere ingenieros de software reales. Sé que muchas descripciones de trabajo no parecen expresar esta distinción, lo que solo confunde el asunto. En el mundo real necesitas poder:

• Reúna y analice los requisitos cuando no se los entreguen directamente
• Diseñe y analice arquitectura con posibilidades casi infinitas
• Cree planes de prueba y actúe sobre ellos para evaluar y mejorar la calidad de un sistema
• Trabajar en colaboración en un equipo de personas con diferentes antecedentes y niveles de experiencia.
• Estime y planifique el trabajo incluso si no sabe exactamente qué construir
• Comuníquese de manera efectiva con las partes interesadas que tienen necesidades diferentes que no necesariamente se alinean
• Negocie el cronograma, el presupuesto, la calidad y las características sin decepcionar a los interesados

Ah, sí, y también tienes que poder escribir código, aunque eso toma, en promedio, solo del 40 al 60% del tiempo de un ingeniero de software.

Por lo tanto, no es que los estudiantes de ciencias de la computación recién preparados no sepan programar (de hecho, muchos son muy buenos programadores). Es que muchos de ellos no saben hacer otra cosa.

En la Universidad...

Tu profesor te da:

• Un problema aislado y bien definido, cuya solución se puede proporcionar en un período de tiempo corto y bien definido (y se descartará después)
• Un conjunto bien definido de herramientas que le presentaron antes de la asignación
• Una medida bien definida para la calidad de su solución, con la que puede determinar fácilmente si su solución es lo suficientemente buena o no

En el mundo real"...

• El problema es borroso, complejo e incrustado en contexto. Es un conjunto de requisitos contradictorios que cambian con el tiempo y su solución debe ser lo suficientemente flexible y robusta para que pueda reaccionar ante esos cambios en un tiempo aceptable.
• Las herramientas deben ser seleccionadas por usted. Tal vez ya haya algo útil en la base de código de 10 años de su equipo, tal vez haya algún proyecto de código abierto, o tal vez una biblioteca comercial o tal vez tenga que escribirlo usted mismo.
• Para determinar si la iteración actual de su software es una mejora (porque casi nunca ha terminado con un proyecto de software), debe realizar pruebas de regresión y pruebas de usabilidad, lo que generalmente significa que es borroso, complejo y contradictorio. , los requisitos integrados en el contexto cambian una vez más.

Conclusión

La programación en la escuela y la programación en el mundo real son inherentemente diferentes al punto en el que en realidad hay muy poca superposición. CS lo preparará para el desarrollo de software del "mundo real", como el entrenamiento deportivo prepararía un ejército para la batalla.

Se enfrentan a un aspecto diferente del problema:

La academia se centra principalmente en la "ciencia de la programación", estudiando así la forma de hacer un algoritmo particular eficiente o desarrollando lenguajes personalizados para hacer que ciertos paradigmas sean más expresivos. La industria se centra principalmente en producir cosas que tienen que venderse. Tiene que depender de "herramientas" que no son solo los lenguajes y los algoritmos, sino también las bibliotecas, los marcos, etc.

Esta diferencia en "enfoque" es lo que hace que un maestro académico en C prácticamente no pueda escribir una aplicación de Windows (¡ya que las API de Windows no están en el estándar C99!), Por lo que se siente como "incapaz de programar". Pero, de hecho, tiene todas las capacidades para aprender lo que se está perdiendo. Algo que, sin los estudios académicos adecuados (no necesariamente realizados en la Academia), es bastante difícil de encontrar.

Buenas respuestas Permítanme agregar, la programación académica tiende a ser casi como un juguete en escala. Esto es bueno para enseñar. Como profesor, estás tratando de transmitir ideas de la manera más eficiente. La desventaja es que la programación realista es tan cualitativamente diferente que es difícil cerrar la brecha.

Un área de diferencia está en el análisis de rendimiento. He escrito muchas publicaciones tratando de señalar esto. El análisis de rendimiento es solo superficialmente sobre algoritmos y mediciones. Para hacerlo de manera realmente efectiva, debe abordarlo como un proceso de depuración.

Otra área de diferencia es la mantenibilidad. Esto abarca todo, desde el estilo hasta el diseño del lenguaje específico del dominio. No puede hacerlo de manera efectiva a menos que realmente sepa lo que está tratando de minimizar.

Estas cosas no se enseñan y marcan una enorme diferencia en la productividad.

En el mundo académico, la mayoría de las personas estudian informática o cursos relacionados. Dijkstra observó una vez que "la informática no se trata más de computadoras que la astronomía de telescopios". Una persona que estudia ciencias de la computación está aprendiendo principalmente a convertirse en un científico y no en un programador. Como programador, seguirá siendo un aficionado y, en consecuencia, la transición a un programador profesional es difícil.

Actualización: como si alguien estuviera leyendo mi mente: expectativas graduadas versus realidad ...

Mi opinión, otros dos factores:

Tamaño del problema : en la academia, principalmente tuve que desarrollar software "desde cero", lo que significaba que la mayoría de las veces, el programa más grande que había encontrado era el más grande que escribí. Esto enfatiza la capacidad necesaria para manejar y hacer frente a la complejidad que surge de las diferentes piezas de software que interactúan entre sí. Si fuera consciente del esfuerzo necesario para comprender con complejidad, podría haber optado por no estar en la industria en absoluto.

Lectura versus escritura : Otro efecto secundario del tamaño del problema es que, a menudo, en el "mundo real" estamos expuestos a trabajos escritos por otros, ya sea con fines de mantenimiento (no realicé tareas de mantenimiento en la academia), extensión o simplemente Division de trabajo. Por lo tanto, leer el código se vuelve muchas veces más importante que escribirlo.

Una propuesta para mejorar la educación en programación : la academia debería exponernos más a situaciones del mundo real sin retroceder a la formación profesional. Los médicos tienen que enfrentar un cadáver en algún momento para ver si están "hechos para eso" (he escuchado historias de personas que abandonaron el curso después de esta experiencia). Si hubiera visto a principios de mis veinte años un proyecto LOC de 20K compuesto por diferentes estilos de programación, que tenía que entender en un día y corregir un error en tres, podría haber considerado otras opciones de carrera, aunque probablemente no.

La mayor diferencia que he encontrado entre la programación académica y la industrial es con respecto a la robustez. Casi todos han experimentado la paradoja de "funciona para mí" en su carrera, y esto es una extensión de esta condición. En la academia, la atención se centra en los algoritmos y las funciones, y se presta poca atención a la usabilidad y estabilidad del software en condiciones cotidianas.

Por ejemplo, en mi oficina tenemos un ingeniero que tomará el software y es un maestro en causar accidentes por condiciones de esquina. Hará clic en un botón lo más rápido que pueda hasta que algo se bloquee ... si una operación lleva demasiado tiempo, simplemente comenzará a hacer clic al azar alrededor de la pantalla (¿por frustración? IDK ...)

Cambiar nuestras filosofías de programación para que hagamos cosas "a prueba de Steve" ha mejorado en general la estabilidad de nuestra aplicación.

No tengo experiencia personal con la capacitación en programación en la escuela: era estudiante de inglés. ¡Pregúnteme acerca de Keats y Byron! - pero he recibido varios graduados nuevos y los mencioné y los asesoré en el mundo del desarrollo de software profesional. Entonces puedo hablar desde esa perspectiva.

Mi experiencia es que realmente TODO lo que obtuvieron de su educación fue un interés en la programación. Sus habilidades variaron de cero a insignificante. Su habilidad para autodirigir era inexistente incluso en los más hábiles de ellos. Su pensamiento no era solo a pequeña escala; en realidad pensaron en miniatura. Un sistema que comprende más de un par de docenas de líneas de código los hizo caer completamente en pedazos.

¿Pero sabes que? Adquirieron un interés , y eso es un gran problema. Un interés es suficiente . Puedo trabajar con alguien que esté interesado. Puedo convertirlos en desarrolladores, siempre que me interesen ser uno. Demonios, eso es todo con lo que empecé. Eso y una apreciación por los novelistas estadounidenses posmodernos.

En academia

DIBUJOS

• Tenemos plazos que son principalmente para ganar puntos.
• Los errores realmente no causan problemas, ya que la mayoría de los proyectos nunca se usan en aplicaciones del mundo real.

MÁS

• Tenemos tiempo suficiente para investigar.
• Alejarse de los objetivos iniciales no causa muchos problemas.

En la industria,

• Trabajamos en proyectos que en realidad serán utilizados por las corporaciones.
• Trabajamos bajo el estrés de los requisitos cambiantes del cliente.
• Los plazos rara vez son flexibles, ya que eso podría conducir a enormes pérdidas financieras tanto para la empresa de software como para los clientes.

Mira esto:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

La programación académica es más sobre codificarlo usted mismo. Esto es importante para aprender cómo funciona. La calidad del código y el control de revisión no cuentan mucho. Con notables excepciones, el código no tiene una vida útil más allá de la asignación. El alcance de los proyectos tiende a ser bastante limitado y es poco probable que se arrastre.

En el mundo real, debe tener el menor código original posible. Los equipos desarrollan mucho código. Es mejor usar rutinas de biblioteca que codificarlo usted mismo. La calidad del código y el control de revisión se vuelven más importantes. El código tiende a tener una vida mucho más allá de lo que se esperaba originalmente. El alcance del proyecto suele ser bastante amplio y tiende a arrastrarse significativamente si no se gestiona.

Realmente,

Es imposible distinguir completamente entre la programación de nivel académico y la programación del mundo real.

Yo diría que la mayor diferencia podría ser esta: en la programación del mundo real, hay que saber más que programar y poder adaptarse rápidamente.

Según el sector en el que esté trabajando, debe cumplir con sus leyes.

Michael solo tocó la punta del iceberg al indicar tareas relacionadas con la programación, que yo clasificaría como cosas fáciles (si vales la masa, te pagan).

En general, enfrentará al menos un par de desafíos por materia en una industria:

• Leyes vigentes (por ejemplo, confidencialidad del cliente para fines médicos)
• Conocimientos técnicos (por ejemplo, sistema de facturación de impuestos, inventario, gestión de recursos, planes médicos, estándares de la industria)
• Requisitos del cliente que faltan o no existen o difieren de los estándares de la industria / leyes vigentes

Si compara un proyecto de programación de nivel de doctorado de investigación con uno del mundo real, lo más probable es que sean muy similares en dificultad, conocimiento de nivel de entrada y tal.

La única diferencia real es que el proyecto del mundo real

• tiene un cliente
• tiene presupuestos (tiempo, dinero, recursos humanos)

Es un juego de pelota diferente cuando alguien más hace las reglas :)

Si observa las materias estudiadas en TI en la academia, encontrará que aproximadamente la mitad del tiempo perdido en matemáticas, ciencias, asignaturas optativas, etc. y la otra mitad en materias académicas como: diseño del compilador, teoría de algoritmos, arquitectura de computadoras, Optimización, sistemas operativos, electrónica digital y algunos otros cursos relacionados con la industria, como la programación en C y la programación web.

La mayoría de los temas mencionados anteriormente son agradables de conocer, pero tampoco proporcionarán directamente una sólida base en lo que se requiere en el día a día de TI.

Tome los requisitos de programación web de Microsoft (es decir, áreas requeridas por alguien para ser un miembro productivo del equipo en una organización):

1- C # .NET o VB.NET

2- ASP.NET

3- HTML y CSS

4- SQL Server (u otra base de datos)

5- programación y diseño de aplicaciones OO

6- Script Java

7- marco MVC

8- Alguna exposición a las herramientas de control de fuente

9- Alguna exposición a herramientas de prueba automatizadas

Herramienta de seguimiento de 10 errores

11-Conceptos de comercio electrónico (opcional)

12-ORM

13-Algunas habilidades de análisis de negocios

14-Algunas habilidades de comunicación

15-Probablemente, algunos fundamentos de computación en la nube

Como puede ver, la mayoría de los requisitos anteriores rara vez se centran (puede obtener 1 curso como máximo) durante la universidad.

No se puede culpar por completo a las instituciones, ya que hay muchas pilas de tecnología y siguen cambiando.

La mayor parte de lo anterior de Microsoft no ayudará a alguien que quiera desarrollar aplicaciones en Java.

El verdadero problema es que ninguna de las pilas de tecnología que necesita el negocio hoy está completamente cubierta.

Lo anterior cubre la cuestión de la idoneidad de los graduados para trabajos empresariales como la programación en el entorno empresarial. Esta respuesta no cubre las necesidades de los laboratorios de investigación, etc. Además, otras áreas requieren más habilidades que las anteriores, como desarrollo de juegos, desarrollo integrado, desarrollo de sistemas en tiempo real, etc.

Escala y enfoque
Según mis experiencias, en un entorno académico, en general, la escala de la aplicación en la que está trabajando es mucho más pequeña, algo que puede completarse en un día o una semana, o tal vez el semestre por uno o dos programadores. -típicamente todo lo que escriba será código desechable que se descarta después del término. En el mundo real, puede encontrarse trabajando en una aplicación que un equipo más grande ha tardado meses, si no años, en desarrollar por completo. Pasas mucho más tiempo depurando el código de otras personas e intentando comprender la infraestructura de una base de código, haciendo malabarismos sin romper las partes existentes para agregar algún requisito nuevo o modificado.

Requisitos, integración, clientes
Además, hay aspectos para desarrollar código, como análisis de requisitos, pruebas de integración, etc., que tienden a estar menos representados en proyectos académicos. En aras de una buena calificación, el instructor ya ha establecido los requisitos para usted, y no se decide en colaboración en las reuniones. No tiende a tener que "vender al cliente" con un enfoque particular que no es exactamente lo que quería, pero a diferencia de sus deseos, en realidad es factible desde un punto de vista técnico. En un entorno académico, su cliente (el calificador o instructor) tiende a tener una idea bastante concreta de lo que quiere, en el mundo real, puede encontrar clientes que realmente no saben lo que quieren y tienen que elegir su cerebro para entender qué debe ser construido

Mantenimiento y mantenibilidad

En la academia (al menos a nivel de pregrado), el software se construye con objetivos a corto plazo en mente, generalmente para completar una tarea o un proyecto a término. Una vez que se completa la asignación, el código se desecha y nunca se vuelve a ver.

En un entorno profesional, la mayoría del software está escrito con un uso a largo plazo en mente; El software está diseñado para ser utilizado durante al menos algunos años y debe construirse para mantenerse y actualizarse fácilmente con el tiempo.

Relacionado con esto está el trabajo de mantenimiento. La mayoría del trabajo de programación profesional implica actualizar o mantener el software existente. Los llamados proyectos de "campo verde" son la excepción, más que la norma.