🧠 La trampa silenciosa del desarrollador que "ya sabe mucho"
Hay un punto en la vida de casi todo desarrollador donde el problema deja de ser técnico… y empieza a ser mental.
Ya no estás peleando con cómo hacer un loop, cómo conectar una base de datos o cómo levantar un servidor. Eso ya lo dominas. Ahora el enemigo es otro, mucho más incómodo:
Tomar decisiones.
Y aquí viene la parte que nadie te explica:
las decisiones que hacen que un producto funcione en el mundo real no siempre coinciden con las decisiones que hacen que el código se vea elegante, moderno o intelectualmente satisfactorio.
Este post es sobre esa transición.
Sobre dejar de ser solo alguien que escribe código… para convertirte en alguien que construye cosas que realmente importan.
Y sí, duele un poco.
🎯 Elegir lo mejor para el negocio (aunque no sea lo más divertido de programar)
Hay una pregunta que pesa más que cualquier bug:
"¿Esta feature que quiero hacer… realmente la necesita alguien?"
Porque seamos honestos, todos hemos tenido:
- Esa funcionalidad que suena brutal.
- Ese panel avanzado con mil filtros.
- Ese sistema complejo que "se vería épico".
… pero que nadie pidió. Nadie validó. Nadie espera.
Aprender a decir:
"Esto está buenísimo, pero no es lo que más valor aporta ahora"
es uno de los mayores saltos de madurez como desarrollador.
No se trata de matar tu creatividad.
Se trata de ponerla al servicio del impacto real, no del ego técnico.
🧩 La adicción a complicarlo todo (hola, microservicios antes de tiempo)
En algún momento descubrimos:
microservicios, Kubernetes, event-driven, CQRS… y sentimos una necesidad casi espiritual de usarlos todos.
El problema es cuando lo haces en un proyecto que todavía no ha demostrado que necesita escalar.
Entonces empiezan cosas hermosas como:
- Logs repartidos por 5 servicios.
- Debugs donde no sabes ni por dónde empezar.
- Dependencias cruzadas dignas de telenovela.
- "Eso no falla aquí, seguro es otro servicio".
Spoiler:
A veces solo necesitas un monolito bien organizado y una base de datos para validar tu idea.
Escalar está bien.
Escalar sin necesidad es sobreingeniería con traje elegante.
🧱 "Pero este framework maneja 200k requests por segundo…"
Buenísimo.
Tu API recibe 18.
Muchísimas veces elegimos tecnología por benchmarks extremos, cuando el problema real está en otro lado:
- Queries sin índices.
- N+1 queries.
- Traer 10.000 filas cuando solo necesitabas 20.
- Nada de caché.
- Paginación inexistente.
Cambiar de framework no arregla una consulta que tarda 2 segundos porque estás trayendo media base de datos.
La mayoría de APIs lentas no fallan por el router.
Fallen por datos mal pensados.
🐳 A veces un docker compose up es suficiente
No todo proyecto necesita:
- Clúster distribuido
- Autoescalado
- Service mesh
- 4 entornos por microservicio
A veces necesitas:
- Backend
- Base de datos
- Un Redis
Y que todo levante sin llorar.
Sencillo = entendible.
Entendible = mantenible.
Mantenible = menos incendios a las 2 AM.
La simplicidad no es mediocridad.
Muchas veces es experiencia hablando.
🧨 El falso microservicio: el monolito distribuido
Este clásico duele porque muchos hemos estado ahí.
"Tenemos microservicios"
…pero todos usan la misma base de datos.
Resultado:
- Un cambio en una tabla rompe medio sistema.
- Todo depende de todo.
- Nadie puede desplegar sin coordinar con medio equipo.
Eso no es microservicios.
Eso es un monolito con problemas de red.
Si vas a separar, separa de verdad:
- Límites claros.
- Independencia de datos.
- Comunicación por eventos o APIs claras.
- Tolerancia a fallos entre módulos.
Si un servicio se cae y tumba todo el sistema… no era independiente como parecía.
🚀 La obsesión por el código perfecto (y la feature que nadie usó)
Todos hemos pasado horas:
- Renombrando variables.
- Reorganizando carpetas.
- Haciendo refactors "porque sí".
- Mejorando una arquitectura que nadie más ve.
Mientras tanto, la feature:
- No se ha validado.
- Nadie la pidió.
- Nadie la usa.
Primero valida.
Luego embellece.
Porque refactorizar algo que sí se usa es una inversión.
Perfeccionar algo que nadie quiere es… arte moderno.
🧪 Tests: el dolor temprano que ahorra sufrimiento eterno
Agregar tests en un proyecto ya gigante es como intentar poner cinturones de seguridad después del choque.
Sí, escribir tests desde el inicio toma tiempo.
Pero agregar tests cuando el sistema ya es grande, frágil y lleno de parches… eso sí es dolor.
Siempre es mejor que:
- Romper algo sin darte cuenta.
- Tener miedo de refactorizar..
- No saber si tu cambio dañó otra parte.
Los tests no son para impresionar cobertura.
Son para darte confianza cuando el código crece.
... confianza para cambiar cosas sin miedo.
🤖 No te cases con una tecnología (ni con una religión tech)
Todos tenemos:
- Lenguaje favorito.
- Framework favorito.
- Stack favorito.
Y está bien.
Lo peligroso es pensar que esa es la solución para todo.
A veces usamos una tecnología porque:
"Es lo mejor del mundo"
Pero en realidad: Es lo más complejo del mundo para un problema simple.
Quizás para ese problema específico…
es como matar una mosca con un misil.
No hay blanco o negro.
Hay contexto.
Elegir bien no es seguir la moda.
Es entender:
Qué necesito, qué sé usar, y qué me permite avanzar sin hundirme.
🌱 La zona de confort también cansa
Trabajar siempre con lo mismo se siente seguro…
Hasta que un día te das cuenta de que estás aburrido.
Aprender cosas nuevas no siempre es para usarlas en producción.
A veces es solo para:
- Mantener la curiosidad viva.
- Entrenar el cerebro.
- Recordar que aún puedes ser principiante.
Tu cerebro es un músculo.
Úsalo… pero no lo lleves al fallo todos los días.
🗣 No todo es código: las habilidades blandas sí escalan
Saber explicar por qué una decisión técnica es correcta
vale tanto como tomarla.
Escuchar a otros, entender negocio, comunicar riesgos, negociar prioridades…
eso es lo que separa a un dev fuerte técnicamente de uno realmente senior.
El código vive en repositorios.
Las decisiones viven entre personas.
🧭 Piensa dos veces, programa una
Antes de escribir código, hazte preguntas incómodas:
- ¿Esto resuelve un problema real?
- ¿Hay una forma más simple?
- ¿Estoy sobreingenierizando?
- ¿Qué pasa si esto crece?
- ¿Qué pasa si no crece?
Pensar es barato.
Reescribir sistemas no.
Programar menos, decidir mejor
Con el tiempo entiendes algo clave:
Ser buen desarrollador no es solo saber construir cosas complejas.
Es saber cuándo NO hacerlas.
La madurez técnica no se ve en la cantidad de herramientas que usas, sino en la cantidad de problemas que evitas crear.
A veces crecer no es agregar más capas… es quitar las que no hacían falta.
Y eso, aunque no siempre luzca espectacular en GitHub, es lo que realmente construye productos que sobreviven.