Expectativas de los graduados versus realidad [cerrado]

50

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?

Mesas Bobby
fuente
44
Como estudiante casi fuera de la universidad, esta es una pregunta muy interesante. No puedo esperar para ver algunas respuestas
Mike42
8
Lo que estás viendo ahora es la realidad. Otros hechos divertidos que también pertenecen a la realidad son: miles de millones de personas sin alimentos, analfabetas, bajo la amenaza constante de la guerra, el mercado financiero cerca del colapso, etc. En otras palabras, la universidad es un campo maravilloso de distorsión de la realidad, y la gente puede aprender mucho conocimiento de libros de texto dentro de la protección de este campo.
rwong
Deberías esperar lo que quieras. Si resulta ser algo menos de lo que esperabas, no lo aceptes como realidad. ¡Sé un pionero y haz realidad tus expectativas!
Atomix
1
Amo la programación. Odio la realidad de cómo se está desarrollando el software en el mundo "real". Lo que describe es una descripción bastante precisa del estado de las cosas en la industria del software.
Capitán Sensible
Como ingeniero de software de Fresh Jr., también estoy experimentando esto, pensé que esto es solo en mi país, ahora estoy obteniendo la función No escrita del desarrollo de software.
Parmanand

Respuestas:

27

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.

Jonn
fuente
55
+1 La importancia de la comunicación. En cuanto al # 2, no es la falta de mejores prácticas; son (i) demasiadas mejores prácticas y (ii) falta frecuente de interés en seguir alguna.
rwong
1
¡+1 para la punta del iceberg! Muchos graduados piensan que lo saben todo, ¡ahora siento que sé menos que nunca!
billy.bob
+1 Algunos buenos puntos aquí. A menudo, la razón de la falta de mejores prácticas / sistemas / procedimientos es el "costo" inicial (es decir, requiere un gasto de capital para la compra), pero el precio por no tenerlos es un mayor mantenimiento o, peor aún, la falla del producto a través de listas de errores fuera de control o requisitos no satisfactorios ... qué buena comunicación podría ayudar a evitar :-)
JBRWilkinson
2
Me gusta esta respuesta Es una buena. Y me hace preguntarme: ¿por qué no hay algún tipo de "pasantía" como todos los médicos tienen que pasar? Una larga y seria zona de transición profesional donde uno puede participar pero no en el camino de la ruta crítica de cualquier proyecto. Algunas grandes empresas pueden tener eso, pero no es un estándar universal en esta profesión. Sin embargo, el trabajo que hacen muchos programadores / desarrolladores de SW / ingenieros de SW es ​​tan peligroso y crítico para las organizaciones de todo tipo, como lo que hacen los médicos para las personas.
DarenW
1
Si es posible, le daría un +1 extra por la punta del punto de iceberg
DarenW
18

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

Dean Harding
fuente
1
Esto es cierto, pero no innovar no significa que no sea crucial o importante. Hay muchas aplicaciones que no son innovadoras que, sin soporte y soluciones, podrían colapsar, por ejemplo, nuestra economía (en el lado extremo ...) ... además, siempre habrá innovaciones dependiendo del proyecto de vez en cuando ...
aggietech
3
Muchos de nosotros abrimos nuevos caminos todos los días. Puede que no sea la cura para el cáncer, pero celebramos los pequeños triunfos con choca esos cinco, una ronda de pasteles / muffins / donas, etc., para marcar el momento. Muchos trabajos, no solo la programación, no tienen una salida que pueda mostrar a sus amigos / familiares, sino que es una cuestión de encuadre: podría decir "Configuré conmutadores de red, servidores DNS y cortafuegos", o podría reformular esto como "¿Conoces Internet: Facebook, YouTube, Twitter y todo eso? Bueno, ayudo a que funcione".
JBRWilkinson
1
@JBRWilkinson: +1. El mejor caso de "reformulación" que tuve fue con un trabajo anterior en el que trabajé en el software de buscapersonas del hospital NurseCall. Se podría decir algo genérico al respecto, como "Escribí programas que ejecutan buscapersonas". OTOH, también puede decir "¡Escribí un software que ayudó a los hospitales a funcionar mejor y probablemente salvé vidas!". No había pensado en eso hasta ahora ... pero estadísticamente probablemente sea cierto. De hecho, me siento mucho mejor con ese trabajo ahora. es decir, ese software salió a producción antes gracias a mi esfuerzo, etc. Realmente podría haber salvado vidas. :)
Bobby Tables
1
@Guzica: Que usted pueda ser / contribuir a salvar vidas a diario es probablemente la mejor satisfacción laboral que cualquiera puede tener, ¡bien hecho!
JBRWilkinson
1
Jaja, excelente respuesta y +1 por tener sentido del humor!
Capitán Sensible
17

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.

maharishi
fuente
Como un graduado relativamente reciente, tengo la impresión de que la forma en que muchos lugares hacen software es incorrecta, pero que mi lugar de empleo actual es ... no perfecto, pero lo intentan y funciona mucho mejor . Ciertamente, parece haber muchos lugares que adoptan un enfoque horrible de "fuerza bruta" ... pero si estás en uno de esos lugares, considera buscar otro lugar.
1
El desarrollo de software en su conjunto es un proceso evolutivo, no revolucionario. Claro, en teoría, podría construir una estructura piramidal a partir de nanotubos de carbono que sea más fuerte, más duradera y más liviana que las pirámides egipcias en teoría. Pero no es práctico ni factible hacerlo. Si el lugar donde trabaja es realmente malo, encuentre un nuevo trabajo. De lo contrario, no se deje atrapar demasiado en la perfección porque los trabajos de programación reales tienen limitaciones reales (como tiempo / financiación). Recuerde que "en teoría, teoría y práctica son lo mismo. En la práctica no lo son".
Evan Plaice
>>> Necesitamos una nueva forma. No se que es eso. - Tampoco nadie más, ¡así continúa!
Gary Willoughby
5

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.

Huperniketes
fuente
5
  • 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 .

Khelben
fuente
"La universidad no te enseña tecnologías de vanguardia": Sí y no. En algunos campos, la academia está 20-30 años adelante de la industria, y puedes aprender algo de eso en la universidad.
Giorgio el
3
  • 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.

rwong
fuente
8
construcción de viviendas en comparación con la reparación de errores, ¿hmm? "¡Hey, acabo de girar el pomo de la puerta en la dirección equivocada, y la casa se desvaneció!"
xor_eq
3

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

Paul Nathan
fuente
1
@Guzica: Una de las empresas para las que trabajé estaba bastante orientada a la ingeniería. Sin la certificación ISO9001, pero siguiendo procesos internos bastante estrictos de manera bastante formal. Los otros estaban, bueno, como se dijo, no más organizados que un grupo de estudiantes de CS haciendo un proyecto de último año juntos.
Bobby Tables
2

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.

Wheaties
fuente
1

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.

flamingpenguin
fuente
Muy buenos puntos. Dos de las empresas medianas / grandes en las que he trabajado han mostrado un marcado contraste entre estos dos casos. Uno estaba fuertemente orientado a la ingeniería, y el otro funciona más como un grupo de equipos de estudiantes de CompSci que realizan proyectos separados del último año en sus propias burbujas, y de alguna manera tienen que integrar las cosas más tarde. (Nota: la gerencia en realidad admite estas "burbujas" - nombre real - pensando que es más eficiente para los equipos trabajar por separado que preocuparse por la integración durante el desarrollo. No estoy bromeando.)
Bobby Tables
1

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?

JeffO
fuente