Expectativas de graduación versus realidad [cerrado]

Te siento hombre. Me gradué hace poco más de un año, de hecho, acepté la primera oferta de trabajo que se me presentó y me causó el mayor impacto 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 solo, incluso con la fecha límite de tesis que se avecina o la defensa especial del proyecto no se compara con el estrés de los plazos de trabajo aparentemente irrazonables, los problemas de comunicación, (un poco de política de la oficina) y la crisis veces.

Falta de mejores prácticas - Igual que tu experiencia en profesionalismo. Antes de tomar mi primer trabajo y durante mi período de entrenamiento, me apresuré a revisar y leer acerca de 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ácticos. Y a veces, su conocimiento cuenta muy poco en comparación con otros que simplemente temen 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í por mi cuenta y de las clases fue suficiente para superarme, me sorprendió decir lo mínimo, mientras miraba atónita la primera parte del código que se suponía que debía 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 - Hice que me diera cuenta para qué eran todas esas clases de inglés. Antes del mundo real, no podía ver la importancia de tener de tres a cuatro clases diferentes de inglés en la universidad cuando se impartía desde que estábamos en el primer grado. No puedes usar tu trabajo cuando puedes hablar con una computadora pero no puedes hablar con la gente.

La mayoría del trabajo que haces no es innovador

Cuando estuve en Uni, trabajé en rutinas de IA para controlar robots de fútbol, construí compiladores y piraté los núcleos de los sistemas operativos.

Pero en el mundo real, el 99% ^* del desarrollo de software es bastante aburrido. Siempre he admirado a los arquitectos o constructores que, cuando se les pregunta "¿qué haces para vivir?" puede señalar un edificio o lo que sea y decir "Yo hice eso ". Pero la mayoría de los desarrolladores de software no pueden hacer eso. Cuando se le pregunta "¿qué haces para vivir?" Lo más cercano a lo que he podido llegar es cuando solía trabajar para una compañía que construía un software que procesaba mensajes SMS para estaciones de radio y similares ... Podría decir, "sabes cuando escribes un mensaje de texto en 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 es tan genial como poder señalar un edificio y decir "Yo construí eso".

Por supuesto, hay personas que pueden decir "Trabajé en Windows" o lo que sea, pero estoy seguro de que en realidad no le dicen a nadie que, por temor a que la próxima pregunta sea " No puedo hacer que mi impresora funcione, ¿puedes arreglarlo por mí? "

^* y el 62% de todas las estadísticas están compuestas al momento

  

Si observa el software actual, 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 de los programas de hoy en día son muy parecidos a una pirámide egipcia con millones de ladrillos apilados uno encima del otro, sin integridad estructural, pero hechos solo por la fuerza bruta y miles de esclavos. -Alan Kay, 2004

la entrevista completa: enlace

No soy veterinario de la industria; Por el contrario, soy un recién graduado pero de una escuela de CS de primer nivel en los EE. UU. Pero mi sensación instintiva es que la forma en que estamos creando software es incorrecta. En lugar de presionar el botón de pausa y reexaminar los fundamentos de la forma en que programamos, nos apresuramos a usar modelos obsoletos de los años 50, 60 y continuamente agregando un poco de azúcar encima. Si seguimos así, nunca superaremos donde estamos. Los seres humanos simplemente no pueden administrar la complejidad de las cosas que son del tamaño de la base de código de MS Windows. Necesitamos una nueva forma. No sé qué es eso.

Creo que esta es la razón subyacente de la sensación de que las grandes y pequeñas empresas de software parecen crear software al piratearlos juntos sin una comprensión profunda de los principios fundamentales.

No me gradué, pero aprendí un poco en las bibliotecas y laboratorios de universidades y universidades.

• 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 la intención de trabajar en mainframes ya que no podía pagar uno, pero no iba a ser tan tonto como para no estar un poco preparado. Los VAXen eran geniales y esperaba que me pagaran el código de mi propio Micro VAX en mi cubículo. Qué pena que el mercado implosione totalmente. (Resultó que tenía dos posiciones trabajando con mainframes ... como contratista de IBM).

• Ingeniería de software : como consecuencia de la Programación estructurada, SASD y otras metodologías de diseño, podría haber pensado que íbamos a ser verdaderos ingenieros. Yo si. Pero los maestros estaban dando muy poca orientación sobre las técnicas de diseño que leí en la biblioteca. Se dejó que los estudiantes se vallaran por sí mismos y los micros hicieron que fuera muy fácil escribir el código hasta que obtuvieron una respuesta con la que estaban contentos. No me di cuenta de lo mucho peor que estaba 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 encargué mucho, y eran lo suficientemente malos como para ser un proyecto nuevo porque tenía que arreglar muchos códigos. Fue una combinación de investigación de la funcionalidad existente y la creación de 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 que las escuelas tienen edificios y equipos antiguos (el equipo de tarjetas perforadas se reemplazó el semestre antes de que empecara ... en 1984), pero cuando trabajando en un almacén mal iluminado o para un jefe que cuelga cuando los clientes llaman a la línea de asistencia, comienza a darse cuenta de que es probable que la descripción de su trabajo no incluya la preparación de 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), leer el código de otros y reutilizar módulos anteriores (tanto internos como externos) es algo que se debe enfrentar casi todos los días. En mi universidad, al menos tuve que codificar con más personas en muy pocas ocasiones, por lo que pensé que la parte principal del trabajo era codificar solo, en el desierto. No lo es.
• Explicar cosas a quienes 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 lenta) 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 vanguardia. Pero también, el 90% de las obras utiliza 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 el mantenimiento, la asociación, la disponibilidad del trabajador ...
• Estás empezando , joven padawan .

He empezado a darme cuenta desde entonces sobre el hecho de que la codificación es un trabajo que haces junto 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 buscaría el código de otros ni tendría que coordinar con otros ...

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, él / ella puede caminar e inmediatamente ver / sentir si hay algo mal. Un error de programación informática 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. Una computadora, sin embargo, podría reproducir exactamente el error cada vez que ejecuta el programa con cierta entrada. Por lo tanto, la comprensión humana de una pieza de código fuente es siempre un modelo imperfecto de la esencia de que sean las instrucciones para una computadora.
• Es muy fácil codificar un programa que maneja los casos más comunes, pero falla completamente en manejar los casos de borde.
  • En otras disciplinas, es relativamente fácil aplicar una acción correctiva después del hecho. Incluso puede haber un cuerpo de conocimientos específicamente dedicado a las acciones correctivas. No hay tal cosa en el desarrollo de software.
  • Afortunadamente, el desarrollo guiado por pruebas ayuda a codificar los casos de borde que se supone que el código debe manejar.
  • Agregado Por otra parte, ciertas metodologías de desarrollo de software parecen sugerir que podemos extraer valor comercial (un tiempo de comercialización más rápido, etc.) al elegir conscientemente no manejar casos de borde, y comunicar esas decisiones a los clientes.
• Los clientes pueden encontrar valores de negocios en un software que maneja solo los casos más comunes, por lo tanto, los proveedores de software no están demasiado preocupados por el manejo de los casos raros.
  • Los clientes simplemente aprenden a evitar los bordes ásperos.

Added

• 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, por lo general, no permanecen en un solo proyecto durante el tiempo suficiente para comenzar a apreciar un diseño de software elegante.
  • Dado que ni los clientes ni los programadores valoran la elegancia del código fuente, las empresas tampoco lo valorarán.

Added

Mis dos centavos: solo acostúmbrate.

Imágenes de procesos ISO, resmas de documentación técnica, todas las características y errores están estrictamente documentados, y un entorno generalmente profesional describe bastante bien a mi compañía. Sin embargo, hacemos productos de software / hardware de infraestructura crítica, así que, bueno, la presión está en para 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 bueno que nuestro codificador principal ha reunido" 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 me he rendido al tratar de entender lo que sucede entre los oídos del jefe de pelo puntiagudo. "Grande" significa pesadilla de mantenimiento, "bueno" significa choques con una suave brisa, y "desastre horrible" significa eso o una base de código bien estructurada cuyos ingenieros se han negado evidentemente a cumplir con plazos obscenos solo para mantener su cordura.

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

Creo que puedes encontrar equipos de ingeniería disipados que desarrollan y siguen procesos sólidos que llevan al lanzamiento de un código sólido en el que el equipo puede tener un alto nivel de confianza (aunque no lo convierto con una gran cantidad de documentación) . Creo que trabajo en un equipo así en este momento. Aunque ciertamente he experimentado el otro tipo de desarrollo.

Lo que sí he llegado a apreciar, sin embargo, es que el desafío no siempre es encontrar el algoritmo perfecto o la solución más limpia al problema. Pero a menudo se intercambian todo tipo de limitaciones (recursos, conocimientos, dinero, tiempo, habilidades, riesgos, capacitación de usuarios preexistentes, etc.) para lograr el mayor rendimiento de la inversión disponible. Eso 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 "mete" 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 las áreas de ingeniería. Supongamos que el software de transacciones bancarias es tan sólido y profesional como un automóvil moderno. El manejo del volumen es una maravilla moderna, pero ¿qué hay de la fiabilidad de cada transacción? No tanto. Tu publicación sobre la primera mierda de tu 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 de ellos, rasgan y rasgan y se tiran. La mayoría de las personas no se preocupan 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 conduce un coche en Beta?