Expectativas de los graduados versus realidad [cerrado]

Al elegir lo que queremos estudiar y hacer con nuestras carreras y vidas, todos tenemos algunas expectativas de cómo será. Ahora que he estado en la industria durante casi una década, he estado reflexionando un poco sobre lo que pensé (cuando estudiaba Ciencias de la Computación) que iba a ser la programación de la vida laboral, y cómo está resultando realmente ser.

Mis dos choques más grandes (o debería decir, expectativas rotas) son la gran cantidad de trabajo de mantenimiento involucrado en el software y la falta general de profesionalismo:

1. Mantenimiento : en la universidad, todos nos dijeron que la mayoría del trabajo de software es el mantenimiento de los sistemas existentes. Entonces sabía que esperar esto en abstracto. Pero nunca imaginé exactamente lo abrumador que resultaría esto. Tal vez es algo que me miré mentalmente, y esperaba que estuviera construyendo cosas nuevas desde cero mucho más. Pero realmente es el caso de que la mayoría de los trabajos son abrumadoramente orientados a mantenimiento, corrección de errores y soporte.

2. Falta de profesionalismo : en la universidad, siempre tuve la impresión de que el trabajo de software comercial está muy orientado a los procesos y rigurosamente diseñado. Tenía imágenes de procesos ISO, montones de documentación técnica, cada característica y error se documentaba estrictamente, y un entorno generalmente profesional. Fue una gran sorpresa darse cuenta de que la mayoría de las empresas de software operan de manera diferente a un equipo de estudiantes que trabajan en un gran proyecto de un semestre. Y he trabajado tanto en la pequeña y ágil tienda de hacks como en la empresa corporativa de tamaño mediano. Si bien no diría que siempre ha sido completamente "poco profesional", definitivamente parece que la industria del software (en general) está lejos de la fuerte disciplina de ingeniería que esperaba que fuera.

¿Alguien más ha tenido experiencias similares a esto? ¿Cuáles son las formas en que sus expectativas de cómo sería nuestra profesión eran diferentes a la realidad?

Te siento hombre. De hecho, me gradué hace poco más de un año, de hecho, aproveché la primera oferta de trabajo que recibí y recibí la mayor sorpresa de mi vida.

Cosas que no esperaba:

El estrés escolar y el estrés laboral no son lo mismo : el estrés de trabajar en un proyecto escolar con amigos, o trabajar en solitario, incluso con la fecha límite de tesis inminente o la defensa especial del proyecto no se compara con el estrés de los plazos de trabajo aparentemente irracionales, los problemas de comunicación , (un poco de política de oficina) y tiempos de crisis.

Falta de mejores prácticas : igual que su experiencia en profesionalismo. Antes de tomar mi primer trabajo y durante mi período de capacitación, me apresuré a revisar y leer sobre las mejores prácticas tanto en programación como en ingeniería de software. Estos no se siguen tan bien como deberían por razones poco prácticas y, para ser justos, prácticas. Y a veces, su conocimiento cuenta muy poco en contra de otros que simplemente tienen miedo de lo desconocido y tratan estas prácticas con desdén.

Lo que enseñaron en la escuela fue solo la punta del iceberg : pensando que lo que aprendí de autoaprendizaje y de las clases fue suficiente para ayudarme, me sorprendí por decir lo menos mientras miraba atónito el primer fragmento de código que estaba se supone que debe mantener Muchas de las habilidades que uso ahora se aprendieron en el trabajo o durante mi trabajo y sigo preguntándome si podría haberlo logrado sin un título universitario. XD

La importancia de la comunicación : me hizo darme cuenta de para qué servían todas esas clases de inglés. Antes del mundo real, no podía ver la relevancia de tener tres o cuatro clases diferentes de inglés en la universidad cuando se enseña desde que estábamos en primer grado. No sirve de nada en su trabajo cuando puede hablar con una computadora, pero no puede hablar con la gente.

La mayor parte del trabajo que haces no es innovador

Cuando trabajé en Uni, trabajé en rutinas de inteligencia artificial para controlar robots que jugaban al fútbol, ​​construí compiladores y pirateé los núcleos del sistema operativo.

Pero en el mundo real, el 99% ^* del desarrollo de software es bastante aburrido. Siempre he admirado a los arquitectos o constructores que, cuando me preguntan "¿a qué te dedicas?" puede señalar un edificio o lo que sea y decir "hice eso ". Pero la mayoría de los desarrolladores de software no pueden hacer eso. Cuando se le preguntó "¿a qué te dedicas?" Lo más parecido a lo que he podido llegar es cuando solía trabajar para una compañía que construía software que procesaba mensajes SMS para estaciones de radio y cosas por el estilo ... Podría decir, "sabes cuando envías mensajes de texto a una estación de radio para votar por una canción, bueno, escribí el software que procesa esos votos y esas cosas ". Todavía no hay nada tan genial como poder señalar un edificio y decir "Yo construí eso".

Por supuesto, no son las personas que pueden decir "yo trabajaba en Windows" o lo que sea, pero estoy seguro de que en realidad no dicen a nadie que por temor a la siguiente pregunta bienestar "No puedo lograr que la impresora de trabajo, ¿Puedes arreglar eso por mí?

^* y el 62% de todas las estadísticas se componen sobre el terreno

Si nos fijamos en el software de hoy, a través de la lente de la historia de la ingeniería, ciertamente es una especie de ingeniería, pero es el tipo de ingeniería que hicieron las personas sin el concepto del arco. La mayoría del software actual es muy parecido a una pirámide egipcia con millones de ladrillos apilados uno encima del otro, sin integridad estructural, pero solo hecho por la fuerza bruta y miles de esclavos. -Alan Kay, 2004

la entrevista completa: http://queue.acm.org/detail.cfm?id=1039523

No soy un veterinario de la industria; Todo lo contrario, soy un recién graduado pero de una escuela superior de informática en los EE. UU. Pero mi sentimiento instintivo es que la forma en que estamos construyendo el software es incorrecta. En lugar de presionar el botón de pausa y reexaminar los fundamentos de cómo programamos, acabamos de apresurarnos usando modelos anticuados de los años 50 y 60, agregando continuamente un poco de azúcar en la parte superior. Si seguimos así nunca pasaremos de donde estamos. Los humanos simplemente no pueden manejar la complejidad de cosas que son del tamaño de la base de código MS Windows. Necesitamos una nueva forma. No se que es eso.

Creo que esta es la razón subyacente de la sensación de que las tiendas de software grandes y pequeñas parecen hacer software pirateándolo sin una comprensión profunda de los principios fundamentales.

No obtuve un título, pero aprendí un poco en las bibliotecas y laboratorios de la universidad y la universidad.

• Big Iron : las tecnologías que enseñaban eran principalmente mainframes y minicomputadoras. El decano de una universidad me dijo que no podría conseguir un trabajo porque ni siquiera sabía qué era un archivo maestro. No tenía intención de trabajar en mainframes ya que no podía permitirme uno, pero no iba a ser tan tonto como para no estar ligeramente preparado. Los VAXen eran geniales, y tenía ganas de que me pagaran por el código de mi propio Micro VAX en mi cubículo. Qué lástima que el mercado estalló totalmente. (Resultó que tenía dos puestos trabajando con mainframes ... como contratista para IBM).

• Ingeniería de software : siguiendo los pasos de la programación estructurada, SASD y otras metodologías de diseño, es posible que haya pensado que seríamos ingenieros reales. Yo hice. Pero los maestros estaban dando muy poca orientación sobre las técnicas de diseño que leía en la biblioteca. Se dejó que los estudiantes se las arreglaran solos y los micros hicieron que fuera demasiado fácil cambiar el código hasta que obtuvieran una respuesta con la que estaban contentos. No me di cuenta de lo peor que era en el mercado laboral. De alguna manera tuve que hacer un poco de código nuevo, así que no fue tan aburrido. Pero también me hice cargo de mucho, y fueron lo suficientemente malos como para ser un nuevo proyecto porque tuve que arreglar mucho código. Fue una combinación de investigar la funcionalidad existente y crear un nuevo código (su reemplazo); herramientas de escritura para simplificar el proceso e instituir una mejor gestión de proyectos.

• Carrera de alta tecnología : una cosa es cuando las escuelas tienen edificios y equipos antiguos (el equipo de la tarjeta perforada se reemplazó el semestre antes de que comenzara ... en 1984), pero cuando trabajas en un almacén mal iluminado o para un jefe que cuelga en los clientes que llaman a la línea de soporte, comienza a darse cuenta de que la descripción de su trabajo no incluye cocinar palomitas de maíz con un láser de 5 megavatios.

• El desarrollo es principalmente trabajo en equipo. Eso significa que la comunicación (hablada y leída), la lectura del código de otros y la reutilización de módulos anteriores (tanto internos como externos) es algo a lo que se enfrentan casi todos los días. En mi universidad, al menos tuve que codificar con más personas en muy pocas ocasiones, así que pensé que la parte principal del trabajo era codificar solo, en el desierto. No lo es.
• Explicar cosas a los que no son desarrolladores es difícil (también cubierto para el primer punto), y es su responsabilidad hacer sus puntos (no del otro 99% del mundo).
• La buena prueba es la prueba que falla. (la primera vez, al menos) Y, por supuesto, no existe un código libre de errores. No eres un mal programador si tienes errores. Los errores son solo una parte (muy importante y que consume mucho tiempo) de su trabajo.
• No hay balas de plata. Cada tecnología tiene sus ventajas y desventajas.
• La universidad no te enseña tecnologías de punta. Pero también, el 90% de las obras usa tecnologías bastante antiguas. Que, por cierto, a veces es lo que se necesita.
• Las personas no técnicas toman decisiones sobre soluciones técnicas , principalmente por razones esotéricas como mantenimiento, asociación, disponibilidad de los trabajadores ...
• Estás empezando , joven padawan .

Desde entonces he comenzado a darme cuenta del hecho de que la codificación es un trabajo que haces en conjunto con más personas, especialmente ahora que el código abierto es más prominente. Pero cuando estaba en la universidad (finales de los noventa), estaba convencido de que iba a hacer las cosas desde cero y que nunca miraría el código de los demás ni tendría que coordinarme con los demás ...

Mirando hacia atrás, para mí una de las mejores partes es aprender y enseñar a otros .

• La programación informática no es física ni intuitiva.
  • Cuando un constructor de casas termina su trabajo, puede caminar e inmediatamente ver / sentir si algo está mal. Un error de programación de computadora no se puede descubrir de la misma manera, y puede estar al acecho en el sistema durante meses o incluso décadas.
  • Si bien un programador puede ver / sentir una pieza de código fuente a través de la revisión del código, no se garantiza que detecte todos los errores contenidos en el código. Sin embargo, una computadora podría reproducir exactamente el error cada vez ejecutando el programa con cierta entrada. Por lo tanto, la comprensión humana de una parte del código fuente es siempre un modelo imperfecto de la esencia de que son las instrucciones para una computadora.
• Es muy fácil codificar un programa que maneja los casos más comunes, pero no puede manejar completamente los casos extremos.
  • En otras disciplinas, es relativamente fácil aplicar una acción correctiva después del hecho. Incluso puede haber un cuerpo de conocimiento específicamente dedicado a acciones correctivas. No existe tal cosa en el desarrollo de software.
  • Afortunadamente, el desarrollo basado en pruebas ayuda a codificar los casos extremos que se supone que maneja el código.
  • Agregado Por otro lado, ciertas metodologías de desarrollo de software parecen sugerir que podemos extraer valor comercial (tiempo de comercialización más rápido, etc.) al elegir conscientemente no manejar casos extremos y comunicar esas decisiones a los clientes.
• Los clientes pueden encontrar valores comerciales en un software que maneja solo los casos más comunes, por lo tanto, los proveedores de software no están demasiado preocupados por manejar los casos raros.
  • Los clientes simplemente aprenden a evitar los bordes ásperos.

Adicional

• La elegancia del código fuente no se valora.
  • Los clientes no ven la elegancia del código fuente. Solo ven la elegancia de la interfaz de usuario y las interacciones.
  • Los programadores, por otro lado, generalmente no valoran la elegancia de la interfaz de usuario, y generalmente no permanecen en un solo proyecto durante el tiempo suficiente para comenzar a apreciar un diseño de software elegante.
  • Como ni los clientes ni los programadores valoran la elegancia del código fuente, las empresas tampoco lo valorarán.

Adicional

Mis dos centavos: solo acostúmbrate.

Las imágenes de procesos ISO, una gran cantidad de documentación técnica, cada característica y error están estrictamente documentados, y un entorno generalmente profesional describe a mi empresa bastante bien. Sin embargo, hacemos productos de hardware / software de infraestructura crítica, por lo que, bueno, la presión está en la calidad (por ejemplo, tenemos la certificación ISO 9001).

Después de graduarme, pensé que las personas a cargo podrían reconocer el buen trabajo del mal trabajo. Después de recibir la millonésima copia del "código realmente genial que nuestro codificador principal creó" y hacer que se vea así:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Casi he renunciado a tratar de entender lo que sucede entre las orejas del jefe de pelo puntiagudo. "Genial" significa pesadilla de mantenimiento, "bueno" significa choques en una brisa suave, y "horrible desastre" significa eso o una base de código bien estructurada cuyos ingenieros se han negado a cumplir plazos obscenos para mantener su cordura.

He oído argumentar que toda la ingeniería de software después de la primera línea de código es mantenimiento. Y eso ciertamente parece coincidir con mi experiencia. El único código que he escrito que no terminó teniendo la mayor parte de su costo de mantenimiento fue un código que no tuvo tanto éxito que nunca o solo se usó brevemente.

Creo que puede encontrar equipos de ingeniería disciplinados que desarrollan y siguen procesos sólidos que conducen al lanzamiento de un código robusto en el que el equipo puede tener un alto nivel de confianza (aunque no complicaría eso con grandes cantidades de documentación). Creo que trabajo en un equipo así en este momento. Aunque ciertamente he experimentado el otro tipo de desarrollo.

Sin embargo, lo que he llegado a apreciar es que el desafío no siempre es encontrar el algoritmo perfecto o la solución más limpia para el problema. Pero a menudo se intercambian todo tipo de restricciones (recursos, conocimiento, dinero, tiempo, habilidades, riesgos, capacitación de usuarios preexistentes, etc.) para lograr el mayor retorno de la inversión disponible. Es construir un sistema que se adapte mejor a todos esos factores y no solo a las influencias técnicas.

Una gran cantidad de software simplemente no llega al punto en que se usa / compra lo suficiente. Cuando uno lo hace, tiende a quedarse y solo se "enreda" en el mantenimiento.

Las expectativas de los usuarios aumentan cada día para las características, pero en muchas áreas, son más bajas en áreas de ingeniería. Supongamos que el software de transacciones bancarias es tan sólido y profesionalmente diseñado como un automóvil moderno. El manejo del volumen es una maravilla moderna, pero ¿qué hay de la confiabilidad de cada transacción? No tanto. Su publicación sobre la primera porquería de su cachorro en la alfombra se dejó caer, y qué. Es más como las pequeñas bolsas de plástico en la tienda de comestibles. Hacen miles de millones, se rasgan y se rompen y se tiran. A la mayoría de las personas no les importa lo suficiente como para exigir una mejor bolsa.

Creo que el software de calidad se hace, eventualmente. Algo de eso llega al mercado antes que la mayoría de los productos comerciales. ¿Quién puede conducir un automóvil en Beta?