Después de 14 años en la industria, sigo encontrando difícil programar

Incluso después de décadas de experiencia, muchos desarrolladores dicen que programar sigue siendo mentalmente agotador, no por la sintaxis o los algoritmos, sino por la creciente complejidad de los sistemas, los requisitos cambiantes y la necesidad de aprender continuamente nuevas herramientas y dominios. Los comentaristas trazan una línea clara entre “escribir código”, que a menudo sí se vuelve más fácil, y la ingeniería de software en su conjunto, que incluye modelar dominios de problemas difusos, integrar sistemas frágiles y navegar la política de oficina y la sobrecarga de procesos. Las opiniones van desde quienes siguen encontrando el oficio intrínsecamente divertido y gratificante hasta quienes se sienten cada vez más agotados, pero la mayoría coincide en que la verdadera dificultad reside en gestionar la complejidad y trabajar eficazmente con otras personas, no en teclear código.

¿Programar es “difícil” o “fácil”?

  • Muchos coinciden en que programar sigue siendo mentalmente agotador incluso después de décadas; la dificultad cambia, no desaparece.
  • Otros dicen que codificar en sí es fácil o հաճible; lo difícil es todo lo que lo rodea (sistemas, personas, procesos).
  • Algunos afirman que ahora se siente más difícil porque ven más modos de fallo y más complejidad que cuando eran juniors.
  • Una minoría sostiene que, en su mayoría, es fácil si tienes inclinación natural y/o te mantienes dentro de dominios de problemas familiares.

Qué es lo que realmente lo hace difícil

  • Gestionar la complejidad: bases de código grandes, capas profundas de abstracción, sistemas distribuidos, kernels, máquinas de estados, dominios críticos.
  • Requisitos deficientes o cambiantes, dominios de problemas difusos y descubrir que estás construyendo la cosa equivocada.
  • Integraciones con APIs inestables o mal diseñadas y sistemas heredados.
  • Entender y modificar de forma segura rutas de código antiguas, sin documentar o “en caliente”.

Progresión profesional y nivel de desafío

  • A medida que crece la experiencia, el trabajo tiende a moverse hacia problemas más complejos, menos definidos y de mayor impacto.
  • Algunos abrazan este desafío continuo; otros advierten que perseguir una dificultad constante al estilo “LeMond” lleva al agotamiento y requiere marcar el ritmo.
  • Un tema recurrente: a veces puedes y deberías elegir trabajo de “zona 2”, donde las cosas sean cómodamente fáciles.

Herramientas, lenguajes y stacks modernos

  • Las herramientas y los lenguajes son más expresivos y más amigables para principiantes, pero en conjunto los stacks se sienten más hinchados y frágiles.
  • La configuración del entorno, las compilaciones/tests lentos o inestables y los pipelines de despliegue complejos se citan como grandes puntos de dolor.
  • La rápida rotación en frameworks, APIs móviles y herramientas de IA hace que “mantenerse al día” sea agotador para muchos.

Factores organizativos y “blandos”

  • La política de oficina, la rotación de la gestión, la carga de reuniones, la sobrecarga de procesos (JIRA, OKRs, informes TPS) y las arquitecturas disfuncionales a menudo dominan la dificultad.
  • Las “habilidades blandas” (a menudo rebautizadas como “habilidades profesionales”)—comunicación, descubrimiento de requisitos, gestión de stakeholders—se describen como cruciales y difíciles de adquirir.
  • La coordinación de equipos grandes, el cambio de contexto y la tutoría de ingenieros más débiles se nombran repetidamente como agotadores.

Calidad, corrección y “buen código”

  • El buen código se describe como comprensible (para futuros lectores y para su autor), cercano al dominio del problema y correcto.
  • Muchos subrayan que la corrección está infravalorada; normalizamos publicar sistemas con defectos latentes.
  • La calidad del código está muy moldeada por la evolución de los requisitos y la historia de la organización, no solo por decisiones técnicas.

El papel de la IA

  • Algunos ven la IA como algo que apenas afecta su día a día; el código es una parte pequeña del trabajo.
  • Otros imaginan que la IA manejará reuniones o actuará como agentes, pero señalan que los verdaderos cuellos de botella son humanos y organizativos, no la velocidad de tecleo.