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

50

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"?

rdasxy
fuente
44
Yo diría que en la academia se aprende en profundidad: aprende conceptos, se hace preguntas, mejora el pensamiento abstracto. En la industria se aprende en forma amplia: se aprende a usar muchas tecnologías diferentes sin hacer demasiadas preguntas, hay que hacer las cosas. A través de la experiencia en la industria, también aprende a administrar proyectos grandes y complejos: este es un tema muy práctico que no puede aprender en la universidad por falta de tiempo.
Giorgio
99
¿Esta pregunta es acerca de lo académico en el nivel de doctorado, o después de la graduación, o simplemente un entorno general de "aula versus mundo real"?
Bob
@Mover. Esto era más sobre la academia general. Aula / investigación / lecturas dirigidas / tareas versus programación del "mundo real" en la industria.
rdasxy
Okay. Eso no estaba muy claro, porque existe la "programación académica" que realizan las personas que quieren decir, ayudar a los biólogos a descubrir simulaciones celulares.
Bob

Respuestas:

72

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.

Michael
fuente
18
Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time.- O incluso 0-20% en tiendas corporativas realmente malas y muy grandes.
Ritch Melton el
1
+1 para una muy buena respuesta y +1 (debería ser más) para Ritch. Si el ingeniero as / w está gastando más del 20% del ciclo de vida de un proyecto en codificación, entonces algo está muy, muy mal. 50% de diseño, 30% de prueba,% 20 para el resto ... todo lo demás, incluida la codificación, parece correcto. Con un diseño adecuado, la codificación debe ser trivial. Sin él, lo que la gente llama "codificación" es en realidad infinitas reescrituras, intentando hackear un diseño de algún tipo a medida que
avanzan
36

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.

back2dos
fuente
11
Esto es básicamente lo que iba a responder. En la escuela conoces el problema y conoces la solución. En el "mundo real" rara vez se conoce la solución y, a menudo, ni siquiera se conoce el problema real.
Bob
20

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.

Emilio Garavaglia
fuente
10

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.

Mike Dunlavey
fuente
1
Me pregunto cómo se podrían enseñar estas cosas, ya que requieren mucho tiempo y experiencia en el campo para adquirirlas. Estaba asistiendo a un curso de ingeniería de software donde equipos de 10 estudiantes tuvieron que desarrollar un pequeño producto de software en unos pocos meses (dos semestres, de octubre a abril). Esto les permitió tener una idea de la programación, planificación, priorización de requisitos y tareas, comunicación, etc. Pero, por supuesto, esto es poco comparado con lo que enfrentarán en el mundo real. Pero no puede pasar 4 años estudiando solo en esto.
Giorgio
@Giorgio: para el rendimiento, tengo una base de código preexistente (no muy grande) que muestro cómo optimizar a través de una serie de iteraciones, obteniendo grandes factores de aceleración. Es una habilidad fácil de enseñar. Para DSL y mantenibilidad, también tengo algunos ejemplos favoritos que podrían usarse para enseñar. Ambos podrían encajar fácilmente en un curso semestral, con espacio de sobra. Entonces creo que podría hacerse.
Mike Dunlavey
1
Ok, entiendo: use ejemplos grandes del mundo real y deje que los estudiantes trabajen en ellos. Muy buena idea.
Giorgio el
@Giorgio: yo era profesor hace 30 años, así que todavía recuerdo cómo hacerlo. También puse estas ideas en un libro que se vendió mal, lo que solo significa que he tenido tiempo de pensar y explicar cómo encaja todo.
Mike Dunlavey
No tengo mucha experiencia, fui asistente de enseñanza durante unos años durante mi tiempo de doctorado. Ahora trabajo en una empresa. Con respecto a la programación en la Universidad, en mi humilde opinión, la verdad está en un punto intermedio: hay algunas enseñanzas muy útiles en la Universidad, pero es difícil cubrir todos los problemas importantes que un ingeniero de software enfrentará a lo largo de su carrera. Con un poco de esfuerzo, realmente puede enseñar algunas cosas del mundo real, como lo ha señalado. No todos los profesores universitarios están dispuestos a hacerlo, por supuesto.
Giorgio
8

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.

thiton
fuente
8

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.

Dimitrios Mistriotis
fuente
Para ampliar su metáfora y desde mi propia experiencia en medicina: el médico aprende conceptos generales en la escuela de medicina, pero todos aprendemos los aspectos básicos y los atajos del mundo real en la capacitación en el trabajo como pasantes y residentes.
Aerodeslizador lleno de anguilas
2
¡Esta! La primera vez que se sumerge en una base de código LOC de 1 millón, se da cuenta de que esto no va a ser como todo lo que ha hecho en la universidad. Está claro muy rápidamente que nunca comprenderá la totalidad de esa base de código, y todo lo que comprenda debe provenir de leer y comprender el código de otras personas, en lugar de diseñar y escribir el suyo propio.
Roman Starkov
4

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.

Dave Nay
fuente
3

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.

Dan Ray
fuente
2

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

SHOUBHIK BOSE
fuente
Voy a tener que estar en desacuerdo sobre la parte de "realmente ser usado". A principios de mediados de los 90, pasé 5 años, en 3 compañías diferentes, grandes, pequeñas y medianas, y nada de lo que escribí entró en producción. No creo que sea una experiencia tan poco común.
Bruce Ediger
2

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.

BillThor
fuente
1

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 :)

Schalk
fuente
0

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.

Ninguna posibilidad
fuente
12
Tienes 15 artículos en tu lista. Supongo que podría agregar otros 30. No es tarea de la academia enseñarle todo eso, sino enseñarle cómo encontrar su camino a través de todo eso. Y también, tener un conocimiento que seguirá siendo utilizable cuando todas las tecnologías actuales sean obsoletas (¿dentro de 10 años?) ¡Para eso es válida toda la teoría y no es una pérdida de tiempo !
Giorgio el
2
@ Jorge, gracias por tu comentario, tu punto es válido. He declarado explícitamente que "No se puede culpar completamente a las instituciones". Si bien la pregunta original no es sobre la naturaleza de la educación académica, mi opinión personal es que existe una GRAN brecha entre lo que los académicos enseñan y lo que el negocio espera. La factura para cerrar la brecha solía ser pagada por la empresa en una costosa capacitación en el trabajo. Con la gran competencia y los tiempos difíciles por los que atraviesan todas las economías, me pregunto quién pagará el precio por cerrar esta brecha hoy.
NoChance
@Emmad Kareem: Sí, hay una gran brecha, estoy de acuerdo. A menudo, los profesores universitarios no tienen idea de lo que está sucediendo en el "mundo real" porque se centran en la investigación abstracta. Sin embargo, son estas habilidades de pensamiento abstracto las que ahora me permiten aprender un nuevo idioma en cuestión de semanas (aprender Scala ahora mismo). También entiendo que quizás para usted el problema del dinero se sienta con más fuerza. Crecí en Italia y cuando estudié los aranceles universitarios, alrededor de 200 $ por año (además tuvimos que comprar los libros nosotros mismos). Supongo que esto es muy poco en comparación con lo que pagas en los Estados Unidos.
Giorgio el
3
Del mismo modo, si estuvieras estudiando ingeniería y aprendiendo a construir un automóvil, nadie te enseñaría a conducir un automóvil específico: esto es algo que esperan que sepas o aprendas por ti mismo.
Giorgio el
1
¿Vano? Si tiene los títulos que dice tener, entonces debería saberlo mejor. Incluso si no está sentado allí programando matemáticas avanzadas, las lecciones aprendidas al estudiarlo se traducen directamente en "ver" una solución limpia y elegante.
Plataforma
0

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

Jessica Brown
fuente
0

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.

Ken Liu
fuente