Pregúntale a un ingeniero qué hizo esta semana y muy poco de la respuesta será teclear lógica nueva en un archivo vacío.
Adónde va realmente el tiempo
La imagen pública del trabajo es composición. La realidad se parece más a arqueología, negociación y reparación.
Leer código existente para entender qué hace. Reproducir un fallo reportado. Revisar el cambio de otra persona. Integrarse con un sistema cuya documentación está desactualizada. Esperar una compilación. Discutir un enfoque. Desplegar. Investigar por qué el despliegue se comportó distinto al entorno de pruebas. Arreglar algo que llevaba dos años funcionando y dejó de hacerlo.
Escribir código nuevo es una parte genuina del trabajo y no es la mayor, y rara vez es la parte que determina si el proyecto tiene éxito.
La restricción en la mayoría de los equipos de software es la comprensión y la coordinación, no la velocidad al teclear.
Esto tiene una implicación directa para la formación. Un programa de desarrollo centrado por completo en lenguajes y frameworks está formando para la mitad más pequeña del trabajo. Las habilidades que deciden los resultados, leer sistemas desconocidos, revisar bien, diseñar para el cambio, comunicar una decisión técnica, son enseñables y normalmente se dejan a la absorción.
Qué cubre la dirección
El alcance: arquitectura, código, pruebas, interfaces de programación de aplicaciones, control de versiones, despliegue y trabajo en equipo.
Cuatro áreas.
Construcción. Lenguajes, diseño, interfaces y el oficio de escribir código que otros puedan cambiar.
Verificación. Pruebas en todos los niveles, revisión, y la disciplina de saber qué se ha comprobado realmente.
Entrega. Control de versiones, integración continua, despliegue y práctica de lanzamiento.
Colaboración. Trabajar en equipo sobre un sistema compartido, que es donde vive realmente la mayor parte de la dificultad del software comercial.
El mayor aumento de empleo de toda la tabla
Vale la pena decirlo con precisión, porque la conversación pública sobre esta ocupación se ha vuelto confusa.
La Oficina de Estadísticas Laborales de EE. UU. proyecta que el empleo de desarrolladores de software crezca un 15,8 % entre 2024 y 2034, un aumento de 267.700 puestos. En ese mismo conjunto de proyecciones, es el mayor incremento absoluto entre las ocupaciones tecnológicas que rastrea, mayor en cifras absolutas que los científicos de datos y los analistas de seguridad de la información juntos, aunque ambos crecen a tasas porcentuales más altas. Se proyecta que el empleo total en todas las ocupaciones crezca un 3,1 % en el mismo período.
Dos matizaciones acompañan de inmediato a esa cifra, y omitirlas sería deshonesto.
Es una proyección. Las proyecciones son modelos construidos sobre supuestos de adopción tecnológica y crecimiento del sector, y se revisan. Esta incorpora un supuesto sobre la inteligencia artificial elevando la productividad, que es por lo que la misma tabla muestra varias ocupaciones administrativas en declive.
La contratación de nivel de entrada ha sido difícil. Los egresados y quienes cambian de carrera han enfrentado un mercado más ajustado de lo que sugiere la cifra de crecimiento titular, y el crecimiento agregado a lo largo de una década no dice nada sobre lo fácil que es conseguir un primer empleo en un año dado.
La reconciliación es que gran parte de las vacantes proyectadas viene de reemplazo más que de expansión, y que la demanda se inclina hacia gente que puede trabajar con sistemas existentes. Eso es una afirmación sobre qué formación se paga, no un argumento de que el crecimiento sea ficticio.
La revisión es la habilidad que escala un equipo
La habilidad enseñable de mayor apalancamiento en ingeniería de software, y una que casi ninguna organización enseña de forma deliberada.
La revisión de código es donde se atrapan los defectos antes de que cuesten algo, donde se difunde el conocimiento por el equipo, donde los estándares se vuelven reales en lugar de solo documentados, y donde los ingenieros junior aprenden más rápido. También es donde se desperdicia una gran cantidad de tiempo y donde se origina una cantidad sorprendente de conflicto laboral.
Cuatro cosas que separan una revisión útil de un ritual.
Saber qué buscar. Corrección, manejo de errores, seguridad, comportamiento a escala, y si esto será comprensible dentro de un año. El formato es lo que debería gestionar una herramienta, y es en lo que los revisores sin experiencia gastan su atención.
Revisar el diseño, no el diff. El comentario más valioso con frecuencia es que el cambio no debería existir en esta forma, y ese comentario es mucho más barato antes de hacer el trabajo.
Separar lo que debe cambiar de lo que tú habrías hecho de otra forma. Confundir preferencia con requisito es la mayor fuente de fricción en la revisión, y enseña a la gente a dejar de preguntar.
Hacerlo seguro. Una cultura de revisión donde la gente teme ser criticada produce cambios más pequeños, más tardíos y menos honestos, y esconde los problemas hasta que se vuelven caros.
Nada de esto es difícil de enseñar. Simplemente se asume que se aprende por exposición, y la gente aprende lo que hiciera su primer equipo.
Dónde encaja en el dominio
Ingeniería de software es la segunda de ocho direcciones en el dominio de IA, datos y computación de Astra Trainer, y es la más grande por plantilla en casi cualquier organización socia. Se apoya en ciencias de la computación para el modelo subyacente y conecta hacia adelante con computación en la nube y DevOps, donde vive ahora la mitad de entrega del trabajo.
También conecta con ciberseguridad, ya que una gran parte de las vulnerabilidades son defectos de software ordinarios, y con inteligencia artificial y aprendizaje automático, donde los sistemas alrededor de un modelo son ingeniería de software convencional. Puedes ver las ocho direcciones aquí.
El mantenimiento es el trabajo, no lo que viene después
El software no termina cuando se lanza. La mayor parte del dinero que se gasta en un sistema a lo largo de su vida se gasta después del primer lanzamiento, y la mayoría de los ingenieros pasan la mayor parte de su carrera trabajando en código que ya existe.
Sin embargo, casi toda la formación técnica usa ejercicios desde cero. A la gente se le enseña a construir algo nuevo, en aislamiento, con requisitos limpios y sin historia, y luego se le contrata para un sistema con quince años de decisiones acumuladas, migraciones parciales y comentarios que describen un comportamiento que cambió hace tiempo.
Las habilidades que exige esa brecha son concretas y enseñables.
Leer código desconocido. Encontrar el punto de entrada, trazar un camino, construir un modelo mental funcional sin leerlo todo.
Cambiar código de forma segura. Añadir pruebas a código sin probar antes de modificarlo, hacer cambios pequeños y reversibles, y usar tipos y contratos para limitar el efecto de una edición.
Entender por qué algo es como es. Gran parte de lo que parece irracional en código heredado era una respuesta correcta a una restricción que ya no existe o a un bug que ya nadie recuerda. Borrarlo sin saber cuál de las dos cosas es como ocurren las caídas.
Gestionar la deuda técnica con honestidad. Distinguir las decisiones que fueron compensaciones razonables de la negligencia acumulada, y hacer visible el coste de cada una a quienes deciden las prioridades.
Migrar de forma incremental. Casi toda gran reescritura intentada como sustitución única es una historia con moraleja. La migración incremental es una habilidad con patrones conocidos y rara vez se enseña.
Los puestos, nombrados
Ingenieros de software, en front end, back end y full stack.
Ingenieros de plataforma, que construyen las herramientas internas de las que dependen otros equipos.
Ingenieros móviles.
Ingenieros de calidad y pruebas, incluida la automatización.
Ingenieros de fiabilidad de sitios (SRE), donde la ingeniería de software se encuentra con las operaciones.
Arquitectos técnicos.
Directores de ingeniería y líderes técnicos, donde la restricción suele ser el criterio más que la capacidad de programar.
Ingenieros de experiencia del desarrollador, una especialidad en crecimiento dirigida al cuello de botella de comprensión y coordinación.
Ingenieros de integración, que conectan sistemas que no se diseñaron para encajar.
Quién puede formarse para esto
Ingenieros de calidad y pruebas. La conversión interna más fuerte. Ya conocen el producto, saben cómo falla y conocen la base de código desde fuera.
Ingenieros de soporte y operaciones. Hacia desarrollo, con conocimiento de producción que a los equipos de desarrollo les falta y con frecuencia necesitan.
Analistas de datos. Ya escriben código, necesitando práctica de ingeniería: control de versiones, pruebas, revisión y diseño para el cambio.
Analistas de negocio y personal de producto con inclinación técnica, hacia puestos adyacentes a la ingeniería donde el conocimiento del dominio es la mitad escasa.
Ingenieros de otras disciplinas. Los ingenieros mecánicos, eléctricos y civiles convierten bien, aportando método sistemático.
Científicos e investigadores que ya escriben código para su propio trabajo, necesitando práctica colaborativa más que programación.
Desarrolladores con experiencia en tecnologías antiguas. Con frecuencia pasados por alto, con conocimiento profundo de sistemas y necesitando un conjunto de herramientas actual más que un cambio de carrera.
Sobre el código generado y la responsabilidad. El código producido por herramientas de generación es responsabilidad de la organización que lo publica, y puede tener defectos, vulnerabilidades de seguridad, implicaciones de licencia o un comportamiento que nadie del equipo puede explicar. Las obligaciones de revisión, pruebas y procedencia no se transfieren a la herramienta. Los sectores con software regulado, incluidos el médico, el automotriz, la aviación y los sistemas financieros, tienen requisitos específicos de proceso de desarrollo y trazabilidad que se aplican sin importar cómo se produjo el código.
Qué llevarte de esto
Producir código nuevo es la minoría del trabajo, y una formación que solo cubre lenguajes y frameworks se dirige a la mitad más pequeña.
Se proyecta que los desarrolladores de software añadan 267.700 puestos para 2034, el mayor incremento absoluto entre las ocupaciones tecnológicas que rastrea BLS, y es una proyección que convive con un mercado de entrada genuinamente difícil.
La revisión de código es la habilidad enseñable de mayor apalancamiento en un equipo y casi siempre se deja a la absorción.
El mantenimiento y el trabajo sobre código heredado es donde se pasan realmente las carreras, y la formación entrena mayoritariamente para proyectos desde cero.
Y los mejores candidatos internos suelen estar en pruebas, soporte y operaciones, ya con el conocimiento que a un nuevo contratado le lleva un año adquirir.
¿En qué pasan realmente el tiempo los ingenieros de software?
Leyendo código existente, reproduciendo fallos, revisando cambios, integrándose con sistemas cuya documentación está desactualizada, desplegando e investigando diferencias entre entornos. Escribir código nuevo es real pero no es la mayor parte.
¿Sigue creciendo el desarrollo de software como ocupación?
BLS proyecta un 15,8 % de crecimiento entre 2024 y 2034, un aumento de 267.700 puestos, el mayor incremento absoluto entre las ocupaciones tecnológicas que rastrea. Es una proyección, no una observación, y convive con un mercado de contratación de entrada difícil.
¿Por qué importa tanto la revisión de código?
Porque atrapa defectos antes de que cuesten algo, difunde el conocimiento por el equipo, hace reales los estándares y forma a los ingenieros junior más rápido que cualquier otra cosa. También es donde se origina la mayor fricción técnica cuando se hace mal.
¿Por qué se subenseña el trabajo sobre código heredado?
Porque la formación técnica usa ejercicios desde cero con requisitos limpios, mientras que la mayoría de los ingenieros pasan la mayor parte de su carrera cambiando sistemas con años de historia acumulada, migraciones parciales y razones sin documentar.
¿Quién convierte bien hacia ingeniería de software?
Los ingenieros de calidad y pruebas primero, luego el personal de soporte y operaciones, los analistas de datos que ya escriben código, los ingenieros de otras disciplinas, y los desarrolladores con experiencia en tecnologías antiguas que necesitan un conjunto de herramientas actual más que un cambio de carrera.