7 Cosas que Odio de Desarrollar

Coders, si estás empezando a programar probablemente creas que todo tu trabajo será usar las últimas versiones de tu lenguaje favorito, frameworks modernos, APIs bien documentadas y empezar proyectos desde cero.

Y sí, a veces es así. Pero también hay momentos donde el desarrollo se convierte en algo pesado, rutinario y hasta frustrante. Cosas que no cuentan en los cursos, pero que en la vida real son inevitables.

Hoy te voy a compartir 7 cosas que odio de desarrollar, pero que más de una vez vas a enfrentar en tu carrera como programador.

1. SOAP en lugar de REST

Coders, vamos a empezar fuerte: SOAP todavía existe.
Y sí, aunque suene increíble, muchas veces cuando entras a proyectos grandes —sobre todo en gobiernos, bancos o empresas que manejan facturación electrónica— te vas a encontrar con APIs que no usan REST, sino SOAP.

¿Y qué tiene de malo? Pues que SOAP es otra forma simplemente de pedir datos entre sistema, y funciona, pero es pesado, anticuado y cero práctico.

Mientras que con REST haces una petición en JSON y todo fluye, con SOAP tienes que lidiar con XML larguísimos, nombres raros, configuraciones extras y errores crípticos. Cosas como “SOAP Fault” que te dicen poco o nada de lo que realmente pasó.

Y para colmo, en muchos casos te piden firmar digitalmente las peticiones, enviar certificados, manejar tokens extraños… o sea, no es que sea imposible, pero es un dolor de cabeza comparado con una API REST moderna.

Lo curioso es que, aunque todos odiemos usarlo, SOAP sigue vivo en entornos críticos porque es robusto y muy formal. Así que si trabajas en facturación, ERP o gobierno, prepárate: tarde o temprano te va a tocar pelear con un WSDL que parece sacado del 2005.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:urn="urn:Factura">
  <soapenv:Header/>
  <soapenv:Body>
    <urn:EnviarFactura>
      <urn:Auth>
        <urn:Username>user</urn:Username>
        <urn:Password>pass</urn:Password>
      </urn:Auth>
      <urn:FacturaXmlBase64>...</urn:FacturaXmlBase64>
    </urn:EnviarFactura>
  </soapenv:Body>
</soapenv:Envelope>

2. Documentación en Word

Coders, no hay nada peor que esto: llegas emocionado a un proyecto grande, te presentan la API que vas a usar y… la “documentación” es un archivo de Word escrito a mano.

Sí, literal: un documento con capturas de pantalla, ejemplos medio inventados y parámetros que nunca están completos. Entonces te toca escribirle al de soporte:
—Oye, ¿este campo es obligatorio?
—Ah, sí, se me olvidó ponerlo.

Y así, terminas trabajando más por adivinanza que por lo que dice el documento.

Lo triste es que esto pasa hasta en empresas enormes, donde uno pensaría que todo está súper organizado. Pero no: te mandan un Word como si estuviéramos en 2003.

La realidad es que una mala documentación no solo te hace perder tiempo, también retrasa integraciones, afecta a clientes y vuelve cualquier proyecto un caos.

Por eso, si algún día estás en una empresa así, por favor muéstrales que existen herramientas modernas como Swagger, ReDoc, GitBook, Docusaurus o incluso Postman, que no solo documentan bien, sino que hasta se integran directo con la API.

Porque seamos sinceros: si una API está mal documentada, es como si no existiera.

3. No existen webhooks

Otra cosa que me saca de quicio es cuando una API no tiene webhooks.

Para los que no lo saben, un webhook es básicamente como si la API te avisara:
"Hey, pasó algo nuevo, aquí tienes los datos".

Pero cuando no existe, ¿qué toca hacer? Pues lo peor: consultar la API cada cierto tiempo para ver si hay cambios. Es decir, un bucle infinito de:
—¿Ya hay algo nuevo?
—No.
—¿Ya hay algo nuevo?
—Tampoco.

Esto se llama Pooling, no solo es ineficiente, también consume recursos, complica el código y a veces hasta te pone límites porque estás pegándole a la API cada cinco minutos.

Con un webhook todo es más simple: el sistema te notifica al instante y tú solo reaccionas. Pero sin ellos, terminas con cron jobs, retrasos en los datos y un montón de lógica que podrías haberte ahorrado.

4. No existe entorno de desarrollo

Ahora imagínate esto: llegas a un proyecto y te dicen “No, aquí no tenemos ambiente de pruebas… todo se hace en producción”.

Sí, leíste bien: producción. Eso significa que cada vez que pruebas algo, estás jugando con datos reales, con usuarios reales y con el riesgo de romper todo en segundos.

Es como si un cirujano aprendiera a operar directamente en pacientes vivos, sin maniquí ni simulación. Una locura.

El problema es que sin un sandbox o un entorno de desarrollo, no puedes experimentar con seguridad. Y en proyectos complejos, no todo son simples peticiones GET: muchas veces tienes que probar pagos, registros, cancelaciones… cosas que en un ambiente real no deberían hacerse a la ligera.

Así que cuando te toque algo así, vas a vivir con el miedo constante de que un console.log mal puesto o una petición de prueba termine enviando facturas falsas o eliminando información crítica.

Moral de la historia: si un proyecto no tiene entorno de desarrollo, cada cambio se siente como cortar el cable rojo o el cable azul de una bomba.

5. Máquinas virtuales para desarrollar

Otra cosa que me desespera: cuando una empresa, en lugar de darte un entorno moderno con Docker o contenedores listos, te dice:
"Aquí está tu máquina virtual… instálalo todo tú."

Y ojo, no hablo de una VM que tengas en tu propia computadora. No, muchas veces son máquinas virtuales en la nube donde tienes que conectarte y trabajar directamente ahí.

¿El problema? Si tu conexión a internet no es la mejor, prepárate para sufrir: cada acción es lenta, abrir carpetas tarda, cambiar de pestaña es un suplicio, y olvídate de compilar rápido porque usualmente esas máquinas vienen con recursos mínimos de RAM y CPU.

Y para rematar, a veces se “olvidan” de pasarte la contraseña o alguien cambia el acceso y tienes que esperar a que un compañero de soporte te la dé para poder seguir trabajando.

Mientras tanto, tu código está secuestrado en una VM que corre más lento que una laptop del 2005.

En cambio, con contenedores modernos puedes tener todo tu entorno en segundos y en tu propia máquina. Pero con estas VMs viejas y mal configuradas… hasta mover el mouse se siente como ir con lag en un videojuego online.

6. Versiones viejas de frameworks y librerías

Otro clásico: llegas emocionado a un proyecto pensando que vas a trabajar con lo último… y resulta que todo está hecho con versiones viejísimas.

Puede ser React sin hooks, AngularJS del 2010, un Laravel que ya nadie mantiene o un Java con librerías que llevan años deprecadas. Y claro, el código funciona… pero cada cambio se siente como caminar en un campo minado: cualquier ajuste puede romper media aplicación.

Lo peor es que actualizar no siempre es opción. A veces el proyecto es tan grande, o depende de tantas piezas, que migrar a la versión actual sería un proyecto aparte, y mientras tanto tienes que seguir con prácticas que ya están muertas.

Esto significa que, mientras otros devs disfrutan de nuevas features modernas y mejores herramientas, tú estás atrapado usando técnicas que parecen sacadas de un museo del software.

En resumen: trabajar con frameworks viejos es como que te den un Nokia ladrillo cuando todos ya tienen smartphones. Sirve, pero se siente como volver a otra era.

7. Plugins y temas en CMS y ERPs

Y llegamos a otro de mis dolores favoritos: trabajar con plugins y temas en plataformas como WordPress, Odoo, Shopify u otros CMS y ERPs.

Desde fuera parece fácil: instalas un plugin, activas un tema y listo. Pero cuando eres el desarrollador detrás, la historia cambia. El entorno es pesado, debuggear es lento y muchas veces necesitas clonar bases de datos completas para poder probar algo sin arruinar el sistema en producción.

Además, no puedes hacer cosas muy complejas sin chocar con limitaciones. Quieres modificar algo y te das cuenta de que tienes que crear un módulo, un hook, una extensión… y eso significa horas peleando con documentación poco clara y entornos que se cargan como tortuga.

Lo curioso es que, aunque como dev lo odies, para el cliente estas plataformas son oro: con un par de clics tienen un e-commerce, una plataforma educativa o un software empresarial corriendo. Y sí, funcionan. Pero para el programador, mantener, personalizar o extender estas cosas es como meterse en un pantano.

En resumen: trabajar con plugins y temas en CMS o ERPs es rápido para el cliente, pero lento y frustrante para el desarrollador.

Bonus: Meetings innecesarias

Y no podía faltar este clásico: las reuniones innecesarias.

De esas que duran dos horas, donde al final te das cuenta de que lo único importante se pudo haber dicho en un correo… o en un mensaje de Slack de dos líneas.

Lo peor es que muchas veces ni siquiera son sobre tu trabajo directo: te hacen escuchar discusiones eternas de cosas que no te afectan, y tú ahí, con la cámara encendida, pensando en todo el código que podrías estar escribiendo.

En serio, pocas cosas matan más la productividad que una reunión sin objetivo claro.

Así que sí, los programadores no odiamos las reuniones… odiamos las reuniones que no tienen sentido.

Conclusión

El desarrollo no siempre es glamuroso ni divertido. A veces toca trabajar con tecnologías viejas, procesos mal hechos o herramientas poco amigables.

Pero lo importante es entender que todo esto también forma parte del trabajo real de programar. Y mientras más aprendas a lidiar con estas situaciones, más valor tendrás como desarrollador.