Si dentro de seis meses tengo que cambiar este módulo o la lógica de negocio evoluciona, ¿cuántos archivos voy a tener que romper?

Cuando estás empezando, la prioridad es que la pantalla pinte el dato, que el test pase en verde y cerrar la tarea antes de que termine la jornada. Pero a medida que avanzas como programador y buscas dirigir tu carrera hacia un perfil Senior, te das cuenta de que hacer que el código funcione es la parte fácil.

Lo verdaderamente difícil es hacer que siga funcionando cuando el proyecto cambia.

Y para lograrlo solo hay una vía: dominar el arte del desacoplamiento.

Hoy, en de CERO a SENIOR, quiero explicarte cómo evitar la trampa del código frágil y por qué, en plena era de la Inteligencia Artificial, este concepto de arquitectura es la mayor ventaja competitiva que vas a tener en tu carrera.

La trampa del acoplamiento y el código de cristal

El acoplamiento es un síntoma de código de mala calidad y que empezamos a observar en nuestro código cuando vemos que dos o más componentes de un sistema están tan entrelazados que cambiar uno te obliga a rastrear y modificar diez partes distintas.

Creo que todos hemos tenido ese típico dolor de cabeza que nos empieza a dar cuando vemos que al modificar X parte del código, hay otras que empiezan a fallar por arte de magia.

Y es que si no te esfuerzas conscientemente por escribir código flexible, acabas construyendo un código de cristal, ese código que funciona perfectamente mientras nadie lo toque, pero al menor cambio, salta por los aires en producción de la forma más insospechada.

Sí, ese código que todos queremos evitar pero que antes o después, hemos terminado escribiendo desde nuestra inexperiencia.

Pero no te preocupes, que para evitar esto, te voy a contar una regla fundamental que empecé a aplicar y me ayudó mucho: la de separar las cosas que cambian por razones distintas.

Dicho así suena muy sencillo, pero en el día a día es donde la mayoría fallamos.

Mezclamos la lógica que calcula un descuento con la consulta a la base de datos que trae al cliente, y de paso con el formato en el que vamos a enviar el correo de confirmación. Todo en la misma función o en la misma clase.

El problema de hacer esto es que cuando el departamento de marketing decide cambiar las reglas del descuento, terminas tocando sin querer la parte que envía los correos, y ahí es donde aparece el desastre. Separar por razones de cambio significa que si cambia la forma de cobrar, toques el módulo de cobros; y si cambia el diseño de la factura, toques el módulo de plantillas.

Ni más, ni menos.

Para poder aplicar esta regla con éxito, lo primero que tuve que hacer fue aprender a detectar las trampas en las que caía continuamente sin darme cuenta. Esos vicios de diseño que parecen inofensivos cuando estás picando código, pero que en realidad están atando tu aplicación de pies y manos.

Hay tres escenarios en concreto que son auténticas fábricas de acoplamiento y a los que deberías empezar a poner la lupa:

1. Los Train Wrecks y la Ley de Demeter

¿Has visto alguna vez una cadena de llamadas a métodos que parece una vía de tren sin fin? Algo como esto:

$user->getOrders()->last()->getInvoice()->getPaymentMethod()->process();

A simple vista, cuando estás empezando, te puede parecer código limpio, compacto e incluso elegante. La realidad es que es un choque de trenes en toda regla y una bomba de tiempo en tu repositorio.

El problema de esa línea no es solo que si el último pedido no existe la aplicación salta por los aires. El problema real es que ese módulo necesita conocer la estructura interna de cuatro clases diferentes para ejecutar una simple acción. Tu código “sabe demasiado” sobre cómo están hechas las cosas por dentro en otros sitios. Si mañana el equipo decide cambiar la forma en que se estructuran las facturas, esta línea se rompe. Y la que está en aquel otro controlador, también.

Para solucionar esto existe la Ley de Demeter, que a mí me gusta resumir como el principio del mínimo conocimiento: habla solo con tus amigos directos, nunca con los amigos de tus amigos.

Tu código solo debería conocer a sus dependencias inmediatas. Si necesitas procesar algo del usuario, pídeselo al objeto User o a un servicio de pagos dedicado, pero jamás fuerces a tu capa superior a navegar por toda la arquitectura para conseguir un dato.

2. Los males de la globalización y lo estático

El estado global es probablemente la fuente más traicionera de acoplamiento que existe en el desarrollo de software.

Variables globales, Singletons usados sin control o llamadas a métodos estáticos que leen la base de datos o la configuración en cualquier rincón de tu aplicación crean hilos invisibles por todo el proyecto.

Son como cables pelados que cruzan la pared sin que nadie los vea.

Este tipo de código provoca que probar un módulo de forma aislada —hacer un simple unit test— se convierta en un infierno, porque el comportamiento de lo que estás probando depende mágicamente de lo que haya hecho otro componente cinco minutos antes en otro lugar de la memoria.

Cuando buscas un código más profesional y con mejor arquitectura te das cuenta de que la inyección de dependencias no es simplemente tener ganas de escribir más código: es la forma de hacer que cada pieza sea autónoma y transparente.

Si una clase necesita algo para funcionar, pídeselo en el constructor. No dejes que salga a buscarlo a ciegas al ámbito global.

3. El peligro oculto de la herencia

Durante muchos años, en la universidad o en los cursos de programación, nos vendieron la herencia como el pilar absoluto de la Programación Orientada a Objetos. Te enseñaban el típico ejemplo del Animal y el Perro y todo parecía encajar perfectamente.

La realidad en proyectos de negocio reales es muy distinta: la herencia añade un acoplamiento feroz.

Cuando creas una subclase que hereda de una clase base, esa subclase queda encadenada para siempre a los detalles de implementación de su padre.

Cualquier modificación que hagas en la clase base para solucionar un problema concreto puede romper inesperadamente el comportamiento de tres o cuatro subclases que ni recordabas que existían en otra parte del sistema.

Pero… ¿cómo solucionamos esto?

Pues priorizando casi siempre la composición sobre la herencia.

No hagas que tu clase sea algo, haz que tu clase tenga algo. Modulas mejor, reduces el impacto de los cambios y ganas una flexibilidad brutal cuando las reglas de negocio evolucionan.

Por qué la IA te está preparando un campo de minas

No puedo hablar de arquitectura hoy sin mencionar lo que está pasando en nuestro día a día con la Inteligencia Artificial porque estamos viviendo un momento en el que generar código es ridículamente fácil y rápido.

Le pides a un LLM una función, te devuelve la respuesta en tres segundos, la pegas, ves que funciona y sigues a la siguiente tarea. Es la era del vibecoding.

Pero aquí está el verdadero peligro para tu carrera si quieres construir software serio: la IA tiende de forma natural al acoplamiento.

Los modelos de lenguaje están optimizados para darte la solución más rápida, directa y funcional al problema concreto que le acabas de plantear en el prompt.

La IA no se va a parar a pensar de forma espontánea en la arquitectura global de tu proyecto a tres años vista.

• Te creará funciones que invocan directamente métodos estáticos para ahorrar líneas de código.

• Te sugerirá herencias profundas porque es el camino más obvio para resolver el caso puntual.

• Acoplará la capa de presentación o las vistas directamente con la base de datos sin despeinarse.

Si utilizas estas herramientas sin tener estos conceptos de arquitectura grabados a fuego en tu cabeza, te vas a convertir en un mero copiloto que valida código que parece correcto hoy, pero que está dejando una deuda técnica devastadora para mañana.

Las aplicaciones “vibecodeadas” sin supervisión arquitectónica van a ser el código heredado más difícil e infame de mantener de los próximos años.

La IA es un motor de velocidad increíble para ejecutar, pero la responsabilidad del diseño y de la salud del sistema sigue siendo, nos guste o no, 100% tuya.

Suscríbete ahora

Compartir

Escribir código para humanos

Escribir código desacoplado requiere más esfuerzo inicial, no te voy a engañar. Requiere frenar el impulso de picar a lo loco, tomarte un café y pensar un par de minutos antes de crear una clase o definir un módulo.

Cualquier programador, incluso con poca experiencia o ayudado por una IA, puede escribir código que una máquina entienda y ejecute. Sin embargo, lo que define a un verdadero Senior es la capacidad de escribir código que los humanos puedan entender, mantener y evolucionar con el paso del tiempo sin sufrir en el proceso.

La próxima vez que vayas a cerrar un pull request o a dar por buena una funcionalidad, hazte la pregunta con la que empezamos hoy:

Si esto cambia mañana, ¿cuántas cosas voy a romper?

Si la respuesta es una sola, vas por el buen camino.

Nos leemos en la siguiente entrega,
Julián.

Durante mucho tiempo, tenía entendido que durante el verano el ritmo de trabajo, y por ende las oportunidades, bajaba y era una época m´sa tranquila... pero la realidad es que este julio y agosto está siendo todo lo contrario.

Me estoy encontrando con un volumen de trabajo que me está constando gestionar, presupuestos grandes sobre la mesa (voy a batir mi récord de facturación mensual en el mes de agosto) y, para sorpresa de nadie... unas cuantas sorpresas desagradables al empezar con ciertos proyectos.

Proyectos con código legacy, proyectos en el que el alcance al final era bastante más del que decía el cliente al principio... y proyectos que se alargan una eternidad.

Estar en el barro estos días gestionando todo este volumen me ha llevado directo a una reflexión que quiero compartir contigo en esta entrega de CERO a SENIOR y trata sobre cómo valoramos nuestro trabajo. Sobre el arte (y la ciencia) de estimar y presupuestar bien.

Y es que, hace unos años, cuando trabajaba como consultor en Airbus, aprendí una lección a golpes que se me quedó grabada a fuego.

Y es que en ese entorno aeronáutico, los errores de estimación no significan “bueno, pues le echamos un par de horas más esta tarde”.

Significan cuellos de botella en cadena, sobrecostes, equipos enteros bloqueados y revisiones de seguridad infinitas.

Esos 3 años me sirvieron para entender que estimar no es adivinar el futuro con una bola de cristal, sino saber anticipar los problemas invisibles que el código todavía no te ha enseñado.

Y no es algo que sea específico de Airbus o de una determinada empresa, pues tiempo después, cuando me lancé de lleno al mundo freelance y al desarrollo web, me di cuenta de que el escenario cambia, pero el problema es exactamente el mismo.

Da igual si estás en una gran multinacional evaluando la magnitud de un proyecto o si estás en tu mesa como freelance preparando un presupuesto para un e-commerce: estimar mal te destruye.

Si estás en empresa privada, estimar mal destruye la confianza de tu equipo y quema a tus compañeros en sprints imposibles.

Si eres freelance, estimar mal se traduce directamente en trabajar gratis a partir del segundo mes y desangrar tu margen de beneficio.

Es por eso que hoy quiero hablarte de por qué la capacidad de estimar es uno de los mayores divisores entre un perfil Junior y un perfil Senior.

La ilusión del camino recto

Cuando alguien empieza en esta profesión (e incluso muchos perfiles intermedios), tiende a estimar pensando en el escenario ideal. El famoso Happy Path.

El proceso mental suele ser este:

1. Leo el ticket o la lista de requerimientos.

2. Pienso en cuánto tardaría en escribir esa lógica en un archivo limpio si nada fallara.

3. Multiplico por dos por si acaso.

4. Entrego la cifra.

Esto es un error clásico.

Es asumir que el desarrollo de software es como construir una pared de ladrillos, donde sabes exactamente cuánto tarda cada pieza.

Pero el software no es una pared; es un ecosistema vivo.

Lo que la experiencia me ha enseñado en estos años es que el tiempo de escribir código suele ser la parte más pequeña del proyecto. Lo que de verdad consume tiempo es todo lo demás:

• El contexto no documentado: la integración con esa API externa que resulta que no sigue la documentación oficial y devuelve errores aleatorios.

• Los casos de borde: qué pasa con los datos de clientes antiguos cuando migras un sistema heredado o cambias una estructura de base de datos.

• La falta de criterio del cliente/negocio: las reuniones para definir qué significa realmente “queremos que sea fácil de usar” o gestionar los cambios de opinión a mitad de desarrollo.

• La infraestructura: despliegues, permisos, entornos de staging que no replican producción y tests que fallan solo en el servidor de integración continua.

El efecto iceberg

En Airbus, cuando nos pedían estimar la implementación de un cambio en un sistema, la parte de código podía llevar dos días. Sin embargo, la estimación real era de tres semanas.

¿Por qué? Por el famoso efecto iceberg, donde la gran parte del trabajo está debajo del agua, sin ser visible.

La auditoría de impacto, las pruebas de regresión, las validaciones de seguridad y los procesos de despliegue... si solo estimas el código, te estás estrellando contra el hielo.

Años después, aplicando esto como freelance, me he reencontrado con el mismo iceberg.

Si un cliente te pide migrar una tienda online a otra plataforma tienes que plantearte preguntas como:

• ¿Qué pasa con la estructura de las bases de datos de origen?

• ¿Cómo mapeamos las colecciones y categorías sin perder lógica de negocio?

• ¿Qué hacemos con los 8.000 redireccionamientos URL para no hundir el SEO de un negocio que factura miles de euros al mes?

• ¿Cómo migramos el histórico de clientes sin interrumpir la facturación diaria?

La diferencia entre tardar una semana (y romper la web) o tardar un mes (y hacerlo bien) no está en lo rápido que tecleas. Está en la experiencia de haber lidiado con esto antes.

Cómo debemos estimar

Estimar bien no es un talento innato; es una habilidad que se entrena acumulando horas de vuelo y haciéndote las preguntas incómodas antes de empezar a picar código.

Si quieres empezar a estimar como un Senior, cambia tu enfoque mental a la hora de abordar un proyecto:

1. Separa la ejecución de la incertidumbre

Un Senior no da una cifra única. Divide el proyecto en bloques y evalúa el nivel de riesgo de cada uno. Lo que ya has hecho cien veces se estima con precisión. Lo que implica una tecnología nueva o una integración de terceros desconocida no se estima en horas de código; se estima asignando primero un bloque de investigación para reducir la incertidumbre.

2. Diseña antes de presupuestar

No puedes estimar lo que no entiendes. Si estás como freelance, nunca envíes una propuesta económica tras una llamada de 15 minutos. Dedica tiempo a auditar, a bajar a la base de datos, a revisar el sistema actual y a entender los dolores reales. Si no sabes qué hay debajo de la alfombra, vas a terminar pagando tú la limpieza.

3. Mide la complejidad de la comunicación

Si en el proyecto hay 5 departamentos implicados, 3 agencias externas y un cliente indeciso, el desarrollo va a tardar el triple. No por el código, sino por la burocracia y los bucles de feedback. Un Senior estima el factor humano de la misma forma que estima la arquitectura.

Suscríbete ahora

Compartir

Qué te debes quedar de esta entrega

Aprender a estimar el trabajo real es lo que te convierte en un profesional respetado.

En la empresa privada, es lo que hace que la directiva confíe en tus criterios técnicos porque sabes cumplir lo que prometes. En el mundo freelance, es lo que separa a quienes viven ahogados apagando fuegos por cuatro duros de quienes entregan proyectos sólidos, protegen su margen de beneficio y dan paz mental a sus clientes.

Deja de medir los proyectos por las líneas de código que vas a escribir. Empieza a medirlos por los problemas que vas a tener que resolver para que todo funcione sin hacer ruido.

Menos intuición y más criterio de ingeniería.

Nos leemos en la próxima,

Julián.

Yo recuerdo perfectamente, aunque haya pasado ya 4 años, las primeras veces que empecé a usar ChatGPT para que me ayudara con mi trabajo.

En esa época todavía trabajaba en una consultora de Francia, en proyectos de Airbus y fue una mezcla de fascinación absoluta y, para qué mentir, un punto de alivio.

Me gustaría decir que fui pionero y usaba la IA como un experto, pero mentiría.

Mi relación con la IA consistía en lo mismo que para el 99% de los desarrolladores: abrir una pestaña en el navegador, escribir un prompt y esperar con los dedos cruzados.

“Explícame este error”, “Refactoriza esta función”, “Optimiza esta consulta SQL”.

Y para qué mentir, eso ya parecía magia y veía que iba a ser una herramienta bastante útil (aunque tampoco me vi venir todo lo que ha ido pasando hasta ahora).

En esa época ya me ahorró horas de peleas con expresiones regulares y subconsultas cruzadas. Respuestas que antes nos costaba media tarde encontrar en Stack Overflow o buceando en documentación desactualizada…

De repente aparecían en la pantalla en tres segundos.

Pero mi romance idílico con Chatty (así, cariñoso) me duró poco. Al cabo de unas semanas, la fricción se hizo evidente: me di cuenta de que era imposible delegarle trabajo de verdad.

Me pasaba el día haciendo de niñera del chat: copiaba un archivo de mi editor, lo pegaba en la web, añadía contexto, corregía la alucinación de turno, me llevaba el código corregido de vuelta al IDE, ejecutaba los tests, fallaban, copiaba el error de la consola, volvía a la pestaña del navegador...

Sí, la IA respondía muy bien, pero el que seguía picando piedra y haciendo de “puente” era yo.

Me había convertido en un transportador de texto de lujo entre mi terminal y un chatbot.

Estaba usando una tecnología revolucionaria como si fuera un buscador un poco más espabilado.

Hasta que pasó el tiempo y llegó un punto inflexión.

Y no, el verdadero cambio de chip no me llegó cuando los modelos se volvieron “más inteligentes”.

Llegó cuando empecé a usar herramientas con acceso real a mi entorno: capaces de leer el repositorio, ejecutar comandos, corregir archivos, pasar la suite de tests y crear un commit por sí mismas.

Ahí es donde dejas de hablar con un chatbot y empiezas a colaborar con un agente. No porque tenga más memoria, sino porque ha dejado de limitarse a responder y ha empezado a trabajar.

El empleado brillante en la habitación vacía

Para entender la diferencia entre un LLM (un modelo de lenguaje) y un agente, me gusta usar una analogía muy de calle.

Imagina que contratas en tu equipo a un desarrollador junior que es un genio teórico absoluto. Se sabe de memoria las especificaciones del lenguaje, ha leído sobre todos los patrones de diseño y tiene una memoria fotográfica.

Sin embargo, el primer día de trabajo lo metes en una oficina completamente vacía. Sin mesa, ni ordenador, ni acceso a Slack, ni credenciales de GitHub, ni de bases de datos. Solo tiene una silla en el centro de la habitación y a ti, que entras de vez en cuando a hacerle preguntas.

Si le preguntas cómo implementar un algoritmo de ordenación complejo, te lo dirá al toque. Pero si le pides que arregle un bug en producción, no podrá hacer absolutamente nada. No puede ver el código, no puede ejecutar los tests, no puede experimentar. Ese desarrollador brillante en la habitación vacía es un LLM.

Un agente es ese mismo desarrollador, pero al que finalmente le hemos dado un escritorio, acceso al repositorio, una consola para ejecutar comandos y un entorno de pruebas.

Un agente no funciona mediante una única pregunta y respuesta, funciona mediante un bucle de retroalimentación continuo (Agentic Workflow):

• Recibe un objetivo: “Corrige el fallo en la pasarela de pago que duplica transacciones”.

• Planifica: desglosa la tarea en pasos pequeños para no perderse.

• Usa herramientas: lee archivos, busca referencias en el código y modifica lo necesario.

• Verifica: ejecuta los tests automáticamente para comprobar si ha roto algo.

• Corrige: si los tests fallan, lee el error, planifica y vuelve a intentar hasta que todo está en verde.

Los LLM responden, los agentes trabajan.

La trampa de la dependencia: mi mayor miedo para la nueva generación

Si estás empezando en esta profesión, tienes a tu disposición el mayor superpoder de la historia del desarrollo de software. Pero quiero ser muy sincero contigo: también tienes delante la trampa más peligrosa para tu carrera.

He visto a muchos desarrolladores junior usar la IA como un generador de código mágico.

Le piden una solución, copian el resultado sin mirarlo y lo pegan en su IDE cruzando los dedos para que funcione. Si funciona, pasan a otra cosa.

Hacer esto es pegarte un tiro en el pie: te estás convirtiendo en un mero operador de chat y estás delegando el pensamiento crítico, que es lo único que te da valor como profesional.

El día que tu empresa configure un agente autónomo real para que haga ese flujo de “copiar y pegar” de forma automática tu rol dejará de tener sentido.

¿Y cómo evitarlo? Dejando de ser el usuario perezoso del agente para convertirte en el ingeniero que sabe diseñarlo, guiarlo y auditarlo.

Para mí, entender cómo funcionan los agentes es la mejor escuela de ingeniería de software que existe hoy en día. Para interactuar de forma madura con ellos y no depender ciegamente de sus respuestas, necesitas aplicar en tu día a día tres hábitos que acelerarán tu camino a senior:

1. Diseña el arnés de pruebas antes de pedir código

Un agente no tiene criterio propio para saber si su trabajo es correcto a menos que tenga un marco objetivo contra el que contrastarlo. Si te acostumbras a escribir los tests unitarios, de integración y a configurar las reglas del linter antes de dejar que la IA proponga código, estarás haciendo verdadero trabajo de diseño. Estarás forzando a tu mente a entender el problema de raíz y a definir los casos límite. El código de producción acabará siendo un detalle de implementación que puedes delegar; el diseño del test es donde tú demuestras tu nivel.

2. Domina la gestión del contexto y la arquitectura

Un agente es extremadamente sensible al desorden. Si le inyectas un repositorio caótico, lleno de dependencias circulares y código ultraacoplado, el agente se perderá, alucinará y consumirá tu presupuesto de tokens en minutos.

Aprender a modularizar tu código, a separar responsabilidades (aplicando el principio de responsabilidad única) y a estructurar APIs limpias no solo hará que tus agentes trabajen mejor; te obligará a ti a pensar como un arquitecto de software. Si aprendes a estructurar el contexto para que lo entienda una máquina, habrás aprendido a estructurar el sistema para que lo entienda cualquier humano de tu equipo.

3. Aplica verificación determinista: confía, pero verifica

A veces nos da pereza leer código ajeno, y más si lo ha escrito una máquina que parece muy segura de sí misma. Pero el mayor error de un junior es asumir que si compila, está bien. Tienes que ser el revisor más estricto de tu agente.

¿Esta solución escala? ¿Maneja correctamente las excepciones de red? ¿Introduce problemas de seguridad?

Forzarte a auditar y corregir el código generado por la IA entrenará tu capacidad de lectura y análisis técnico mucho más rápido que si te pasaras el día picando código repetitivo a mano.

[Workshop Online] De Developer a AI Champion: Harness Engineering

Descubre cómo dar el salto de Developer a AI Champion aprendiendo a aplicar Harness Engineering para construir flujos agénticos reales, fiables y listos para producción. Verás cómo diseñar el sistema que rodea a tus agentes (contexto, herramientas, restricciones, memoria y mecanismos de verificación) para que dejen de improvisar y produzcan resultados consistentes. Construiremos un caso práctico en directo donde aprenderás a diseñar un Harness desde cero y a incorporar validaciones automáticas antes de llevar los cambios a producción. Además, te llevas el repositorio de código para aplicarlo en tus proyectos.

Regístrate gratis aquí

¡Plazas limitadas!

El arte del Harness Engineering y el protocolo MCP

Cuando aceptas que el LLM es una pieza probabilística (y a veces caótica) dentro de un sistema que necesita ser determinista, dejas de hacer Prompt Engineering y empiezas a hacer Harness Engineering.

El Harness es todo el andamiaje de software tradicional que construimos alrededor del modelo para guiarlo, limitarlo y protegerlo.

Es el sistema que levanta un contenedor aislado para que el agente ejecute comandos de forma segura, el que valida que la salida del modelo cumpla estrictamente con un esquema JSON y el que controla el presupuesto para que el bucle no se quede colgado gastando dinero en bucles infinitos.

Para que este arnés funcione sin tener que escribir integraciones personalizadas para cada herramienta, la industria está adoptando el MCP.

Aprender cómo funciona MCP y cómo exponer tus propios servicios bajo este protocolo es una de las habilidades más valiosas y con más futuro que puedes adquirir hoy como desarrollador.

La inteligencia necesita límites

Otra palabra clave que debes grabar a fuego en tu flujo diario es restricciones.

Al principio, esto puede parecer contradictorio. Si estamos construyendo sistemas autónomos e inteligentes… ¿por qué querríamos limitar lo que pueden hacer? ¿No estamos frenando su capacidad?

He aprendido que en la ingeniería de software ocurre todo lo contrario.

Un sistema robusto no depende de que los desarrolladores nunca cometan errores (porque los van a cometer), sino de las salvaguardas que impiden que esos errores tiren abajo el negocio.

En tu día a día no permites que nadie haga un push —force directo a producción, ni despliegas sin pasar por el pipeline de integración continua.

Con los agentes el enfoque es idéntico.

Diseñar restricciones claras (limitar los directorios donde pueden escribir, restringir sus llamadas de red o capar el acceso a credenciales sensibles) es lo que transforma un script débil en un sistema fiable apto para producción.

Suscríbete ahora

Compartir

Una reflexión para llevarte a casa

Hace no tantos años, cuando empecé en esto, pensaba que ser un buen programador consistía únicamente en picar líneas de código muy rápido y saber de memoria la sintaxis de un lenguaje. Me frustraba si no recordaba el nombre exacto de una función.

Con el tiempo, los errores y los proyectos caídos a las espaldas, descubrí la realidad: el verdadero trabajo de un ingeniero consiste en entender problemas ambiguos de negocio, diseñar arquitecturas limpias que toleren el cambio, automatizar lo repetitivo y construir sistemas mantenibles que no requieran que estés despierto a las tres de la mañana.

Con la llegada de los agentes va a ocurrir exactamente lo mismo.

Dentro de unos años, probablemente escribiremos muchos menos prompts de los que hoy imaginamos.

No pasaremos el día susurrándole palabras clave a una caja de texto. Lo que realmente diseñaremos y programaremos serán sistemas robustos capaces de decidir qué contexto inyectar, qué herramientas invocar bajo qué condiciones, qué verificaciones de seguridad ejecutar y cuándo dar un objetivo por cerrado de forma determinista.

El modelo de lenguaje seguirá siendo una pieza clave del engranaje, por supuesto. Igual que lo sigue siendo un compilador, una base de datos o un navegador. Pero dejará de ser el centro absoluto de nuestra atención.

La próxima revolución tecnológica no pertenece a quien mejor sabe hablarle a una IA en un chat, pertenece al desarrollador que sabe diseñar los sistemas para que la IA pueda, por fin, ponerse a trabajar de forma segura. Y ese es el peldaño de abstracción que te convertirá en el desarrollador senior que toda empresa querrá tener en su equipo.

Nos leemos en la próxima.

Julián

Llevaba desde 2022 con mi propia web pidiendo a gritos una actualización. Ya sabes cómo va esto: te pasas el día exigiéndole a tus clientes buenas prácticas, rendimiento brutal y código limpio, pero luego miras tu propio portfolio y... en fin. Mejor no mirar demasiado de cerca.

Hace medio año decidí que ya tocaba adecentar mi rincón en internet.

Y lo enfoqué como lo hacemos casi todos los desarrolladores cuando nos toca lidiar con lo nuestro: “Me abro el editor, monto un WordPress, hago un tema a medida, subo mis servicios y en un par de fines de semana lo tengo ventilado”.

Error.

He tardado 6 meses. Medio año para lanzar la nueva juliancampos.es.

Y lo más curioso de todo: la culpa no la ha tenido la programación. De hecho, tirar líneas ha sido la parte más rápida.

El problema fue darme cuenta de que estaba a punto de cometer el típico error de junior que intento corregir en los demás: pensar que hacer una web va de escribir código.

Empiezas a tirar del hilo y te das un golpe de realidad de los que duelen. La web no era el problema.

El problema era todo lo que tenía que tener claro antes de abrir siquiera el editor:

• Qué quería vender exactamente.

• A quién quería atraer (y a quién quería espantar).

• Cómo quería posicionarme en el mercado.

• Qué tenía que entender una persona en 10 segundos antes de pedirme presupuesto.

En definitiva: cómo hacer que la web dejara de ser un simple portfolio para salir del paso y se convirtiera en una herramienta real para mi negocio.

Suena exagerado dedicarle 6 meses a esto, lo sé.

Pero creo que precisamente ahí está el gran aprendizaje que quiero compartirte hoy. Porque el salto de junior a senior pasa, muchas veces, por levantar la cabeza del teclado.

La web no empieza en el código

Esto me ha costó en su día aceptarlo, porque la tendencia natural de muchos de nosotros es irnos directamente a programar.

Abrir el editor. Crear el tema. Montar bloques. Pensar componentes. Resolver el responsive. Optimizar imágenes. Hacer que todo vuele.

Lo típico.

Pero una web enfocada a negocio no empieza ahí. Empieza preguntándote cosas bastante menos cómodas:

• ¿Para qué quiero esta web?

• ¿Quién quiero que la lea y qué problema tiene esa persona?

• ¿Qué quiero que piensen de mí?

• ¿Qué conversación quiero generar?

Aunque suene muy de marketing, esto es vital para cualquier desarrollador que quiera crecer profesionalmente. Llega un momento en el que no basta con saber hacer cosas; tienes que saber explicar por qué esas cosas importan.

No es lo mismo decir desarrollo webs en WordPress que decir ayudo a empresas que tienen una web que ya no escala, que arrastra deuda técnica y que necesitan una base sólida para seguir creciendo.

Técnicamente ofreces lo mismo, pero la percepción cambia por completo. Y la percepción, aunque nos moleste admitirlo, también forma parte de tu valor.

El cliente no compra tu stack

Este es uno de los errores más habituales en nuestros primeros años. Construimos nuestra comunicación alrededor de nuestras herramientas: WordPress, Laravel, React, Docker, AWS...

Y ojo, todo eso importa. Pero el cliente no se levanta un lunes pensando:

“Ojalá encuentre hoy a alguien que me implemente una arquitectura con bloques personalizados y buenas prácticas de rendimiento”.

El cliente piensa en sus problemas reales:

• “Cada cambio en la web es un drama”.

• “Dependemos demasiado de una sola persona”.

• “Marketing necesita lanzar cosas y tecnología es un cuello de botella”.

Ese es su punto de partida. Si tu portfolio no habla de eso, estás obligando al cliente a hacer de traductor.

¿Traductor?

Si, porque lo que tú dices es: desarrollo a medida, optimización de rendimiento o arquitectura escalable.

Pero lo que el cliente necesita escuchar es: menos riesgo y más control, más velocidad y mejor conversión, menos dependencia técnica y más ventas.

Cuanto más obligas a alguien a traducir tu valor técnico a su idioma de negocio, más fácil es que te descarte.

La marca también es trabajo técnico

Sé que esto suena raro en una newsletter de código, porque solemos pensar que la marca es cosa de diseñadores o gente que habla de “tonos de voz” en reuniones eternas.

Pero si eres freelance, consultor, o simplemente quieres destacar en tu empresa, tu marca es lo que alguien entiende de ti antes de hablar contigo.

Es la diferencia entre parecer otro programador más o alguien con criterio.

En mi caso, quería transmitir tres cosas: solidez técnica, cercanía y orientación a negocio.

Quería que se entendiera que sé programar, por supuesto. Pero también que sé pensar en sistemas, entender el contexto, hablar con negocio y tomar decisiones que trascienden el editor.

Ahí es donde reside buena parte del salto de junior a senior. No en escribir más líneas, sino en entender qué líneas merece la pena escribir.

El diseño y el copy no son “la capa bonita”

Durante el proceso trabajé con profesionales de diseño y copy. Para mí, esto ha sido un antes y un después.

Cuando eres desarrollador y haces tu propia web, tienes un problema grave: sabes demasiado. Quieres contarlo todo, justificar cada decisión técnica y meter todos los detalles. Acabas construyendo una web para ti, no para quien te va a contratar.

El copy no es rellenar huecos en una maqueta con Lorem Ipsum. El copy es estrategia escrita. Es decidir cómo traduces tu trabajo técnico a valor real.

En lugar de decir algo como Implemento bloques personalizados en WordPress, puedes probar con Construyo una web editable sin convertir tu WordPress en un caos de plugins y parches.

La segunda frase le habla directamente a la herida del cliente.

WordPress no era el objetivo, era el sistema

Cuando llegó la fase de desarrollo, entró en juego lo que más dominamos: temas a medida, plantillas, responsive, rendimiento, integración de newsletter...

Y aquí surgió la gran pregunta: ¿Por qué WordPress?

Podría haber usado Astro, Next, Laravel, un CMS headless... y habría quedado algo técnicamente impecable. Pero el criterio de un perfil senior no es qué tecnología me apetece usar hoy, el criterio es qué necesita este proyecto.

Y este proyecto necesitaba:

• Facilidad absoluta para editar contenido sin romper nada.

• Estructura sólida para publicar artículos y newsletter.

• Velocidad para iterar sin depender siempre de tocar código.

• Una base conocida para integrar SEO y captación.

Para eso, WordPress tenía todo el sentido. No porque sea siempre la respuesta, sino porque aquí encajaba a la perfección.

A veces usamos una herramienta porque está de moda, o porque en Twitter parece que si no usas el último framework de JS estás haciendo arqueología. Pero el verdadero criterio técnico consiste en elegir lo que resuelve el problema con el menor coste razonable, el menor riesgo posible y la mayor facilidad de mantenimiento.

Yo no quería hacer una simple web. Quería construir un sistema: WordPress como CMS, el tema como sistema visual, los bloques como piezas de negocio y el formulario como inicio del proceso comercial.

Una web debe generar mejores conversaciones

No quería el típico formulario de Nombre / Email / Mensaje. Eso solo genera correos genéricos que te hacen perder el tiempo.

Quería un flujo que me ayudara a cualificar el proyecto antes de la primera llamada: qué necesitan, qué problema tienen, qué esperan conseguir.

Esto también es desarrollo.

Una buena funcionalidad no es solo la que no da errores; es la que mejora una decisión, reduce fricción o genera información útil. El objetivo no era recibir más mensajes, era recibir mejores conversaciones.

Suscríbete ahora

Compartir

Entonces, ¿merece la pena dedicar 6 meses a una web?

Depende.

Si tu web es solo una tarjeta de visita virtual, no.

Pero si tiene que explicar quién eres, vender tus servicios, filtrar oportunidades y construir tu autoridad, entonces sí. Porque no estás haciendo una web. Estás construyendo el motor de tu negocio.

Y esto conecta de lleno con lo que siempre defiendo en CERO a SENIOR: crecer como desarrollador no va solo de aprender el enésimo framework.

Va de entender de producto. De negocio. De comunicación.

La parte técnica sigue siendo vital, pero cada vez tengo más claro que el verdadero valor de un perfil senior está en unir las piezas:

Código + Arquitectura + Producto + Negocio + Comunicación = Criterio.

Mi nueva web ha sido una excusa perfecta para recordármelo. No te cuento esto para que te pases medio año con tu próximo portfolio, sino para recordarte que, a veces, lo importante no es hacer las cosas rápido, sino hacerlas con intención.

Un saludo,

Julián

También hace semanas que no te enviaba una entrega puramente técnica, y la verdad es que ya tenía ganas de explicar asuntos más técnicos, sobre todo si tiene que ver con arquitectura.

Pero antes de ir a los detalles de arquitectura, quiero contarte cómo me di de bruces con la realidad hace un tiempo.

Imagina la escena: estás construyendo tu producto. Tienes tu backend montado, tus controladores listos y las pruebas en local te muestran que todo está ok.

Todo parece ir sobre ruedas.

Entonces, decides probar el analizador de FácilSEO con una web real de un cliente.

Introduces la URL, le das a analizar, tu backend hace su magia y... el reporte vuelve casi vacío.

Sí, la funcionalidad principal de tu proyecto no funciona. Te encuentras con un desastre que tiene un total de cero palabras, cero enlaces y una estructura rota.

Miras el código y revisas los logs. Lanzas un par de maldiciones pensando que te has cargado algo en el último commit.

Pero no, tu código está bien. Abres el navegador, entras a esa misma web y la ves perfectamente: llena de texto, imágenes y diseño.

¿Qué estaba pasando?

Pues que me acababa de chocar de frente contra el muro invisible de las webs modernas.

Ese día me di cuenta de que resolver ese problema no iba de añadir un simple parche o cambiar una librería. Iba a requerir replantear cómo estaba diseñando el sistema.

Porque hay problemas (de los feos, de los que te hacen rascarte la cabeza) que simplemente no aparecen hasta que sacas tu producto a la calle.

Hoy quiero contarte cómo solucioné ese choque de trenes, y por qué me llevó a tomar una de las decisiones más importantes del proyecto.

El problema de las webs modernas

Cuando empecé a montar el sistema de análisis SEO, me topé con este escenario bastante incómodo.

Resulta que muchas webs actuales no devuelven todo su contenido en el HTML inicial. En su lugar, tiran de JavaScript para cargar datos, montar componentes y renderizar la página directamente en el navegador.

Para un usuario normal esto es transparente, pero para una herramienta SEO es un dolor de cabeza.

Si haces una petición HTTP tradicional, muchas veces recibes una página casi vacía: sin estructura real, sin información fiable y, lo peor de todo, llevándote a conclusiones equivocadas.

Separar sin complicarse (el Renderer)

Para solucionar esto, en FácilSEO creé un servicio separado que se encarga exclusivamente de renderizar las páginas usando Playwright.

Básicamente, abre la web como lo haría un navegador real, ejecuta el JavaScript, espera a que cargue el contenido y devuelve el HTML final.

Esto hace que el análisis sea muchísimo más fiable.

Pero más allá de la herramienta en sí, lo realmente importante es la decisión arquitectónica de separarlo.

Este renderer vive fuera del backend principal (no está dentro de Laravel), y no es casualidad.

Es un proceso pesado, consume recursos, tarda más y puede fallar por motivos completamente distintos.

Si una web tarda mucho en cargar o el renderer cae, la API principal debe seguir funcionando sin inmutarse y sin bloquear otras peticiones.

La lección aquí es clave: no todo lo que tu backend necesita hacer tiene que vivir dentro del mismo proceso.

El monolito modular

Ojo, esto no significa que tengas que volverte loco montando microservicios.

FácilSEO no está construido así; sigue siendo un backend monolítico en Laravel, pero de forma modular.

El código está organizado por áreas con sentido: SEO, Proyectos, Billing, Posicionamiento.

No se trata de hacer una arquitectura bonita por postureo o por modas, sino de evitar que toda la lógica acabe embutida en controladores gigantescos.

Un controlador no debería saberlo todo: solo recibe la petición, valida y delega en servicios o módulos donde realmente vive la lógica.

Un backend que trabaja solo y sabe cómo fallar

Otra cosa que suele pasar desapercibida es que un backend no solo responde a los usuarios; también trabaja solo.

Envía informes, sincroniza datos con Search Console, revisa suscripciones y reintenta procesos fallidos.

Todo esto lo gestiona el scheduler, convirtiendo al backend en un sistema activo que no depende únicamente de que alguien haga clic.

Y hablando de fallos... cuando haces una demo, todo es un caso feliz o de éxito.

Pero en la vida real, Stripe puede fallar, una web puede no responder o un webhook puede perderse por el camino.

Por eso, el sistema no está pensado solo para ejecutar acciones, sino para saber recuperarse.

Hay reintentos, timeouts, gestión de estados intermedios y logs. Y es que tu sistema nunca debe asumir que todo irá bien.

Aquí radica la diferencia entre programar y construir producto:

• Programar es conseguir que algo funcione.

• Construir producto es conseguir que siga funcionando cuando las cosas van mal, entender qué ha pasado y que un error aislado no arrastre todo el sistema.

Suscríbete ahora

Deja un comentario

La idea importante si estás empezando

FácilSEO podría haberse construido mucho más rápido metiendo todo dentro de la petición, con una sola cola y controladores enormes. Y probablemente habría funcionado... en local. Pero las malas arquitecturas siempre dan la cara cuando llega el uso real.

No necesitas usar Docker, Redis o Playwright desde el día uno.

Lo que sí necesitas entender cómo separar responsabilidades: qué debe ser rápido, qué puede ir en segundo plano, qué puede fallar y qué no debe bloquear al usuario.

En FácilSEO, la regla mental es sencilla: la API coordina, los workers ejecutan, el scheduler automatiza y el renderer se pelea con las webs modernas.

Cada pieza tiene su responsabilidad.

No es perfecto, pero es mantenible.

Al final, diseñar un sistema real se resume en aceptar el caos. Asumir que las cosas externas van a fallar y prepararte para que, cuando lo hagan, el impacto sea mínimo. No se trata de usar la tecnología más puntera, sino de tomar decisiones prácticas que te dejen dormir tranquilo por las noches.

Seguiremos usando FácilSEO (y mis propios tropiezos en producción) como excusa para seguir aprendiendo. Todavía queda mucho barro en el que meternos.

Nos leemos en la próxima,

Julián

P.D.: Durante el verano, las entregas de CERO a SENIOR pasarán a ser cada dos semanas, increíblemente, para ser verano, estoy hasta arriba de trabajo y bueno, así también todos podemos desconectar y descansar un poco.

Una newsletter de programación sin escribir sobre código, patrones, arquitectura… ¿pero eso qué es?

Y hasta aquí ha llegado esto… bueno, o eso me gustaría decir, porque hoy tampoco te voy a contar nada súper técnico, así que todavía estaré al menos una semana más sintiéndome un poco mal por ello 😅

Y no porque no piense que no es importante o que ya no sea necesario saber ciertas cosas de programación para llegar a ser Senior.

Nada de eso.

Creo que a día de hoy, y de cara al futuro próximo, saber programar bien, va a seguir siendo importante en tu carrera, haya o no haya IA de por medio… pero también creo que el desarrollo y la evolución de junior a senior está más allá del código.

Pero bueno, que me enrollo y lo que te quiero contar hoy no va sobre esto (creo que si sigues la Newsletter ya sabrás lo que opino de qué es lo que va haciendo falta para convertirse en desarrollador senior).

Lo que hoy te quiero contar es un poco de historia.

Sí, historia, has leído bien… historia para comprender la situación que estamos viviendo los desarrolladores hoy en día con la IA generativa y los LLM y mostrarte que, en realidad, esta situación no es del todo nueva en nuestro sector.

Sin duda estamos viviendo una época bastante curiosa y confusa en el sector con la llegada de la IA.

Nos hemos encontrado con una herramienta que nos ayuda a sacar código más rápido, reducir trabajo repetitivo y, en definitiva, generar código desde un lenguaje natural.

Se trata de una herramienta que ha puesto el desarrollo al alcance de mucha más gente, permitiendo que saber programar no sea un impedimento para lanzar algo (aunque habría que ver si el código que da y sin la supervisión técnica es suficiente para lanzar algo seriamente).

Ha sido un boom grande, muy grande, tan grande que mucha gente ha dado la profesión de la programación como muerta de cara al futuro.

Y ha sido gente de todos lados… gente fuera del sector de la programación y gente dentro de ella.

Parece que estamos en un punto de no retorno. Un punto que no habíamos vivido antes… ¿o sí?

En los 80 ya daban a los programadores por muertos

Si eres nuevo por el mundo de la programación y crees que es la primera vez que una tecnología ha amenazado con acabar con la carrera de los programadores… estás muy equivocado.

Seguramente muchos no conozcan esta historia, ya que se remonta a las décadas de los 70 y 80, tiempo en el que nació una tecnología que prometía reducir drásticamente la necesidad de programar manualmente.

Se trataba de las herramientas CASE.

Las herramientas CASE (Computer-Aided Software Engineering) fueron sistemas diseñados para ayudar a los ingenieros de software a analizar, diseñar, documentar y, en algunos casos, generar código automáticamente.

La idea era que el desarrollo de software evolucionara de una actividad artesanal a una actividad más industrial.

En lugar de escribir código directamente, el desarrollador trabajaba con modelos:

• Diagramas de flujo.

• Diagramas entidad-relación.

• Modelos de datos.

• Diagramas UML (más adelante, en la década de los 90).

• Especificaciones funcionales.

La herramienta generaba automáticamente parte del código, la documentación o incluso la base de datos.

Algunos ejemplos históricos de estas herramientas fueron Excelerator, Rational Rose, ERwin o Oracle Designer.

La promesa de estas herramientas era que describir el sistema visualmente era suficiente para que la máquina te desarrollara el software.

Pero no fueron capaces de cumplir…

Sí, como puedes imaginar, no fueron capaces de cumplir esas promesas y seguimos desarrollando software hasta el día de hoy.

¿Y sabes por qué no fueron capaces de cumplir esto?

Porque se descubrió que escribir código no era la parte más difícil del problema, la complejidad estaba en comprender el negocio y gestionar requisitos cambiantes.

Las herramientas CASE podían generar miles de líneas de código, pero:

• Los requisitos cambiaban constantemente.

• Los modelos eran difíciles de mantener.

• El código generado solía ser rígido.

• Modificar el código manualmente rompía la sincronización con los diagramas.

Al final, los desarrolladores acababan escribiendo mucho código a mano y muchos proyectos terminaban usando las herramientas únicamente para documentación y diseño.

Semejanzas y diferencias con la IA

Sí, la IA es bastante diferente y nos encontramos en un punto donde seguramente estas herramientas no se queden solo para escribir documentación. Pero, pese a esto, las herramientas CASE tienen algunas semejanzas con Codex o Claude.

Tenemos la promesa de automatizar la programación, las herramientas CASE generaban código desde modelos y los LLM lo hacen desde lenguaje natural, también reducen el trabajo repetitivo, requieren de supervisión humana, tienen dificultades para capturar requisitos reales y, por qué no, tienen mucho marketing alrededor.

Básicamente, ambas comparten la promesa de que la programación dejará de consistir en escribir código y pasará a consistir en describir lo que quieres.

¿Y las diferencias?

Aquí es donde las LLM son mucho más potentes y donde vemos que estamos en pleno 2026 y no en la década de los 70 y 80.

La primera diferencia es que las herramientas CASE eran demasiado deterministas:

Modelo → Generador → Código

Si el modelo no contemplaba algo, la herramienta no podía inventarlo. En cambio, los LLM son probabilísticos:

Descripción → Modelo entrenado → Solución propuesta

De esta forma, la IA enfocada a la programación puede inferir intenciones, completar huecos, proponer arquitecturas, explicar errores, generar tests y refactorizar código existente.

Mientras que CASE obligaba a formalizar el conocimiento mediante diagramas y modelos, los LLM trabajan sobre patrones aprendidos a partir de enormes cantidades de código y texto.

Una herramienta CASE no podía leer un proyecto de 100.000 líneas y sugerir mejoras… un LLM sí puede ayudar a hacerlo.

¿Qué lección nos llevamos de esto?

En ambos casos, el de las herramientas CASE y la IA, hemos escuchado algo parecido:

“Dentro de unos años ya no necesitaremos programadores”.

Y, lo curioso, es que con las herramientas CASE ocurrió lo contrario.

Las herramientas CASE, aunque no cumplieron las expectativas más ambiciosas, sí aportaron valor en determinados contextos. Y no solo eso, sino que como permitieron construir sistemas más grandes y complejos, aumentando la demanda de ingenieros.

Y hoy en día, con la IA, hay también argumentos razonables para pensar que los LLM podrían provocar algo similar:

• Menos tiempo escribiendo código rutinario.

• Más tiempo diseñando sistemas.

• Más software creado.

• Y más necesidad de personas que entiendan requisitos, arquitectura, negocio y validación.

La diferencia entre los LLM y CASE es que los LLM atacan una parte mucho más amplia del trabajo intelectual y es por eso que muchos consideran que representan un salto tecnológico bastante mayor que el que supusieron las CASE.

De aquí, de este análisis, está un poco fundamentada mi opinión sobre la IA y el futuro de los programadores.

Si te limitas a escribir código y ya, corres peligro.

Si aportas valor más allá de escribir código, estarás mejor posicionado para adaptarte a esos cambios.

Deja un comentario

Compartir

Es por ello que a menudo en esta newsletter de hablo de aspectos más allá del código y cada vez escribo menos sobre aspectos técnicos.

Creo que nuestro trabajo va a estar marcado por la IA: será más fácil generar código, pero también será cada vez más importante que los perfiles técnicos tengan cada vez más idea sobre producto, entendiendo requisitos, arquitectura, negocio y validación.

Yo, personalmente, estoy en ello y estoy intentando formarme cada vez más sobre producto para poder aportar más allá del código.

Creo que todavía tendremos que aprender a programar, los programadores serán necesarios ya que no podemos dejar toda la responsabilidad sobre la IA para el desarrollo de los sistemas.

Lo que pasa es que no nos podemos quedar solo en ello.

Dudo que la IA tenga un impacto tan limitado como el que terminaron teniendo las herramientas CASE, pero también dudo de que sustituya un perfil que entienda sobre todo esto.

En fin, hoy quería compartir contigo un poco de la historia de la programación y mi opinión.

¡Me encantaría leer la tuya en los comentarios!

Un saludo,

Julián

PD: sí, volveremos pronto a tener entregas más técnicas, no te preocupes.

No porque la IA sea mala ni porque piense que deberíamos volver a programar como hace diez años.

Todo lo contrario.

Si te soy sincero, yo la utilizo prácticamente todos los días y estoy convencido de que cualquier desarrollador que ignore estas herramientas estará en desventaja.

Lo que me preocupa es otra cosa: que estemos empezando a confundir avanzar rápido con aprender.

Y te lo digo porque hace unas semanas me encontré con esta reflexión mientras trabajaba en algo tan simple como la nueva versión de mi página web.

Era un proyecto personal y quizá precisamente por eso decidí desarrollarlo de una forma que cada vez hago menos: escribiendo prácticamente todo el código yo mismo.

Lo que ocurrió durante esas semanas me recordó una lección que me habría gustado aprender mucho antes en mi carrera.

Una lección sobre la productividad, el aprendizaje y una habilidad que, por mucho que avance la inteligencia artificial, sigue siendo responsabilidad tuya desarrollar.

Un experimento que nunca planeé hacer

Cuando empecé a desarrollar la nueva versión de mi web no tenía ninguna intención de convertir el proyecto en un experimento. Mi objetivo era simplemente actualizar una página que ya necesitaba una renovación importante.

Partía de un diseño realizado por un diseñador profesional y, en teoría, gran parte del trabajo ya estaba definido. Solo quedaba construirlo.

Sin embargo, por alguna razón, decidí hacerlo prácticamente sin apoyarme en herramientas de inteligencia artificial.

No fue una decisión ideológica ni una postura en contra de la IA. Simplemente me apetecía volver a sentarme delante del editor de código y desarrollar el proyecto de una forma más tradicional.

PHP, JavaScript, HTML, CSS y WordPress.

A la vieja usanza, como cuando empecé a hacer mis primeros desarrollos a medida de Wordpress y no tenía ChatGPT o Claude para ayudarme.

Y sí, la realidad es que en este desarrollo estaba (y estoy) tardando mucho más.

Muchas tareas que hoy puedo resolver en cuestión de minutos con Codex me estaban llevando bastante más tiempo.

Había problemas que requerían investigar documentación y otros me obligaban a probar diferentes alternativas antes de encontrar una solución. Y en muchas ocasiones simplemente necesitaba sentarme a pensar antes de escribir una sola línea de código.

Esto, a priori, puede parecer una desventaja ya que después de todo, vivimos en una época donde la velocidad parece ser la principal medida del éxito.

Si puedes hacer algo en una hora en lugar de tres, parece lógico pensar que la opción más rápida siempre es la mejor.

Pero conforme avanzaba el proyecto empecé a notar algo que no esperaba.

Estaba entendiendo mucho mejor lo que estaba construyendo.

Lo que descubrí al ir más despacio

Mientras desarrollaba cada sección de la web empecé a detectar pequeñas mejoras que no había visto durante la fase de diseño.

Encontraba detalles de experiencia de usuario que podían optimizarse.

Cambiaba algunas estructuras y ajustaba determinados contenidos.

Replanteaba comportamientos que sobre el diseño parecían perfectamente razonables pero que durante la implementación mostraban limitaciones o alternativas mejores.

No porque el diseño estuviera mal, y es que de hecho, el diseño era excelente.

Lo que ocurre es que el simple hecho de construir cada módulo manualmente me obliga a comprender mucho mejor el producto.

Y ahí fue donde apareció una idea que no he dejado de darle vueltas desde entonces.

Quizá la velocidad tiene un coste que no solemos tener en cuenta.

Cuando algo requiere más tiempo, también requiere más reflexión. Pasas más horas pensando en ello.

Lo observas desde más ángulos y detectas matices que de otra forma habrían pasado desapercibidos.

Y eso me hizo preguntarme si, en nuestra obsesión por producir cada vez más rápido, no estaremos sacrificando parte del aprendizaje que ocurre precisamente durante ese proceso.

La trampa de la hiperproductividad

Creo que esta es una reflexión especialmente importante para quienes estáis empezando en el desarrollo de software.

La inteligencia artificial nos está haciendo increíblemente productivos. Podemos generar código más rápido, investigar más rápido, documentar más rápido y resolver muchos problemas en una fracción del tiempo que necesitábamos hace apenas unos años.

Y eso es fantástico y sería absurdo ignorar una tecnología que nos permite trabajar mejor.

Sin embargo, existe una diferencia importante entre ser productivo y aprender.

La productividad consiste en obtener resultados en menos tiempo.

El aprendizaje consiste en desarrollar capacidades que te permitirán resolver problemas más complejos en el futuro.

A veces ambas cosas avanzan juntas… pero muchas otras veces no.

Cuando eres junior es muy fácil caer en la ilusión de que estás progresando porque completas más tareas y todo parece indicar que estás mejorando.

Pero la pregunta realmente importante no es cuánto avanza el proyecto.

La pregunta importante es cuánto avanzas tú.

Porque si cada vez que aparece una dificultad delegas el análisis, la investigación y el razonamiento en una herramienta, puede que estés construyendo software, pero no necesariamente estés construyendo criterio profesional.

Y el criterio es precisamente una de las habilidades más valiosas que puedes desarrollar durante los primeros años de tu carrera.

Lo que las empresas realmente pagan

Hay algo que tardé bastante tiempo en entender:

Las empresas no pagan por código.

Sé que puede sonar extraño viniendo de alguien que lleva años trabajando como desarrollador, pero es una realidad que he comprobado una y otra vez.

El código es únicamente una herramienta, lo que las empresas pagan es la capacidad de resolver problemas.

Pagan por personas capaces de analizar situaciones complejas, entender necesidades de negocio, tomar decisiones acertadas y construir soluciones que aporten valor.

Por eso muchas veces vemos desarrolladores técnicamente brillantes que tienen dificultades para crecer profesionalmente, mientras otros con conocimientos aparentemente más modestos avanzan hacia puestos de mayor responsabilidad.

La diferencia suele estar en la calidad de sus decisiones.

En su capacidad para entender el contexto y en su criterio.

Y cuanto más avanza la inteligencia artificial, más importante se vuelve esta diferencia.

Porque llegará un momento en el que casi todos tendremos acceso a herramientas similares.

Lo que marcará la diferencia será cómo pensamos, no únicamente cómo programamos.

El riesgo de delegar demasiado pronto

No quiero que interpretes esta reflexión como una crítica a la inteligencia artificial.

Sería bastante hipócrita por mi parte.

Yo utilizo ChatGPT prácticamente todos los días. También utilizo otras herramientas de IA para investigar, validar ideas, desbloquear problemas y acelerar muchas tareas de mi trabajo.

No creo que la solución sea dejar de utilizarlas, creo que la solución pasa por ser conscientes de qué estamos delegando.

Delegar tareas repetitivas tiene sentido.

Delegar búsquedas de información tiene sentido.

Delegar parte de la implementación puede tener sentido.

Delegar el pensamiento crítico no.

Porque precisamente ahí es donde sigue estando gran parte de nuestro valor como profesionales.

Cuando un desarrollador se acostumbra demasiado pronto a recibir respuestas instantáneas corre el riesgo de dejar de entrenar una habilidad fundamental: la capacidad de enfrentarse a la incertidumbre.

Y una gran parte de nuestro trabajo consiste precisamente en eso.

En resolver problemas para los que no existe una respuesta inmediata, en tomar decisiones cuando ninguna opción es perfecta, en navegar zonas grises.

Y esas habilidades solo se desarrollan pensando.

Suscríbete ahora

Compartir

Cómo usar la IA sin frenar tu crecimiento

Si estás empezando en el desarrollo de software, mi recomendación es sencilla.

Utiliza todas las herramientas que tengas a tu alcance. Aprende a sacar partido de ChatGPT, Claude, Copilot o cualquier tecnología que aparezca durante los próximos años.

Pero intenta reservar algunos espacios para pensar por tu cuenta.

Antes de pedir una solución, intenta plantear varias alternativas.

Antes de copiar código, intenta entender el problema.

Antes de aceptar una respuesta, pregúntate si realmente es la mejor opción.

No porque tengas que sufrir innecesariamente.

Ni porque exista algún mérito especial en hacerlo todo manualmente.

Sino porque el aprendizaje ocurre precisamente durante ese proceso de reflexión.

Es ahí donde se desarrolla el criterio.

Y el criterio será una de las habilidades más valiosas que podrás aportar durante toda tu carrera.

Después de estas semanas desarrollando mi nueva web he llegado a una conclusión bastante simple.

La inteligencia artificial seguirá mejorando. Cada año será más rápida, más capaz y más accesible. Muchas de las tareas que hoy hacemos nosotros terminarán automatizándose total o parcialmente.

Pero mientras todo el mundo se obsesiona con producir más deprisa, quizá una de las inversiones más inteligentes que puedes hacer en tu carrera sea dedicar tiempo a desarrollar aquello que ninguna herramienta puede aprender por ti.

Tu capacidad para pensar.

Tu capacidad para entender problemas.

Tu capacidad para tomar buenas decisiones.

Porque llegará un momento en el que casi todos tendremos acceso a las mismas herramientas.

Y cuando eso ocurra, el verdadero valor no estará en quién genera más código.

Estará en quién sabe qué código merece la pena generar.

Sin más, nos leemos en la próxima.

Julián.

Que si aprender un nuevo framework, hacer otro curso, probar la nueva IA de turno, memorizar patrones… y, en definitiva, consumir contenido de programación y desarrollo constantemente.

Es un comportamiento que lo conozco bien porque durante bastante tiempo yo también pensaba así.

Tenía en mi cabeza la errónea idea de que la diferencia entre un programador junior y uno senior estaba, principalmente, en la cantidad de conocimientos técnicos que acumulabas con los años y los estudios.

Y bueno, aunque evidentemente la parte técnica importa muchísimo (aún hoy en día con la IA) con el tiempo me empecé a dar cuenta de que había algo mucho más determinante en mi crecimiento profesional.

Y si, puedo decir sin miedo que la habilidad que más me ayudó a crecer no fue programar.

Fue aprender a comunicar.

Creo que ya te he hablado alguna vez de esto, pero permítame que insista.

Sí, así es, fue comunicarme.

Y no me refiero a dar conferencias, ni a convertirte en una persona extremadamente sociable, ni siquiera a hablar bien en público.

Me refiero a algo mucho más cotidiano y mucho más importante dentro de un equipo de desarrollo: aprender a hacer buenas preguntas, aprender a explicar problemas correctamente y aprender a entender realmente a las personas con las que trabajas.

Porque hay algo que muchas veces no vemos cuando estamos empezando: programar es una profesión mucho más social de lo que parece.

Durante mucho tiempo tuve la idea de que un buen desarrollador era alguien capaz de resolver cualquier problema por sí solo.

Cuanto menos dependieras de otros, mejor programador eras.

Cuanto más tiempo aguantabas bloqueado intentando sacar algo adelante sin pedir ayuda, más mérito tenía.

Pero la realidad de los proyectos profesionales es bastante diferente.

El problema empieza fuera del código

Con los años me he dado cuenta de que los mejores desarrolladores que he conocido no eran necesariamente los que más tecnologías sabían ni los que escribían código más complejo.

Eran los que sabían comunicarse mejor.

Personas que hacían preguntas constantemente.
Que validaban ideas antes de implementar.
Que sabían reconocer rápidamente cuando algo no lo entendían del todo.
Y, sobre todo, personas capaces de traducir problemas técnicos complejos en conversaciones simples y entendibles para el resto del equipo.

Porque en proyectos reales, muchas veces el problema no es la programación en sí, viene de otro lado:

Viene de haber entendido mal el requisito, de no haber detectado un malentendido a tiempo, de no haber preguntado suficiente contexto, de no haber comunicado una limitación técnica importante o de sabido explicar por qué cierta decisión podía convertirse en un problema dentro de unos meses.

Cuándo me di cuenta de esto

Todo esto que te estoy contando no es algo que te pueda enseñar un framework.

Por ejemplo, en mi carrera profesional, hubo un momento donde empecé a notar un cambio bastante grande en mi manera de trabajar y es que dejé de obsesionarme tanto con demostrar constantemente que sabía hacer las cosas y empecé a preocuparme mucho más por entender bien el problema que tenía delante.

Parece una diferencia pequeña, pero cambia completamente la manera en la que aprendes.

Porque cuando empiezas a hacer buenas preguntas, aprendes más rápido.
Cuando entiendes bien el contexto, tomas mejores decisiones técnicas.
Y cuando eres capaz de comunicar dudas pronto, evitas muchísimos errores que después son caros de corregir.

Creo que muchos programadores junior viven con miedo a pedir ayuda porque sienten que eso demuestra falta de nivel. Como si un buen desarrollador tuviera que resolver todo solo y rápidamente.

Pero la realidad es que en equipos profesionales ocurre justo al revés.

Las empresas suelen valorar muchísimo más a una persona que sabe colaborar bien, comunicar bloqueos y trabajar en equipo, que a alguien técnicamente brillante pero incapaz de compartir contexto o alinearse con los demás.

Y esto conecta con algo que me costó bastante entender al principio: comunicar no consiste solamente en hablar bien.

Consiste, sobre todo, en escuchar bien.

Aprende a escuchar antes de hablar

Sí, así es, para aprender a comunicar primero tienes que aprender a escuchar a otros desarrolladores, al equipo de producto, al cliente o, simplemente, es cuchar qué problema se intenta resolver realmente antes de pensar directamente en la solución técnica.

Porque muchas veces nos enamoramos demasiado rápido de la implementación y dedicamos muy poco tiempo a entender el problema de verdad.

Y aquí ocurre algo curioso.

Cuanto más senior se vuelve alguien, menos obsesionado está normalmente con las tecnologías concretas y más importancia le da al contexto, a las decisiones y a los trade-offs.

Por eso muchas veces los seniors parecen más lentos.

Porque antes de escribir código intentan entender correctamente qué merece la pena construir y cuál es la mejor manera de hacerlo en ese contexto concreto.

Y sinceramente, creo que esa mentalidad marca muchísimo más la diferencia profesional que saberse de memoria un framework nuevo cada seis meses.

Deja un comentario

Compartir

Si tuviera que darle un consejo a alguien que está empezando, probablemente sería este:

No centres todo tu crecimiento únicamente en aprender tecnologías.

Aprende también a comunicar ideas.
A explicar problemas.
A pedir ayuda sin sentir vergüenza.
A escuchar antes de implementar.
Y a entender realmente el problema antes de pensar en la solución.

Porque muchas veces la diferencia entre un programador junior y uno senior no está solamente en el código que escribe.

Está en cómo piensa, cómo se comunica y cómo trabaja con las personas que tiene alrededor.

Y, curiosamente, esa terminó siendo la habilidad que más hizo crecer mi carrera como desarrollador.

Nos leemos el próximo domingo.

Julián.

En esta entrega te conté de dónde había salido el proyecto, por qué lo había recuperado después de tenerlo meses aparcado y qué problema intentaba resolver: dejar de hacer análisis SEO y reportes a mano cada vez que entraba un cliente nuevo.

En esa edición te enseñé la parte visible del producto.

La parte que cualquier usuario puede entender rápido: añadir proyectos, analizar URLs, ver recomendaciones, conectar Search Console, generar informes y automatizar reportes.

Pero también te dije que me estaba dejando fuera toda la parte técnica.

Y precisamente de eso va esta entrega.

FácilSEO se trata una plataforma destinada a ayudar a los análisis SEO y de rendimiento web, con el objetivo de facilitarte los análisis, la búsqueda de mejoras en tu web, la elaboración de informes y automatizaciones para ti o tus clientes.

Puedes usar el código CEROASENIOR15 en el momento del registro para tener 15 días GRATIS del plan pro (no hace falta meter tarjeta alguna ni se te cobrará nada al acabar el periodo de prueba)

Pruebalo Aqui

Hoy quiero enseñarte cómo está montado el backend de FácilSEO y no para hacer una lista de tecnologías ni para venderte que usar Docker o colas te convierte en mejor desarrollador, porque esa sería una conclusión bastante pobre.

La idea es otra: un backend no se complica cuando tiene muchas rutas, se complica cuando no sabes qué responsabilidad tiene cada parte del sistema.

Y FácilSEO, aunque sea un MVP, no podía construirse como una simple API que recibe una URL, analiza una web y devuelve un JSON.

Sobre el papel suena sencillo: el usuario mete una URL, el backend la analiza y el frontend muestra el resultado.

Pero cuando te pones a construirlo de verdad, te das cuenta de que analizar una web no es una operación normal.

No es como hacer login. No es como guardar un proyecto. No es como actualizar un perfil de usuario.

Analizar una web implica depender de cosas que no controlas: webs lentas, errores inesperados, contenido que solo aparece tras ejecutar JavaScript, APIs externas que tardan o directamente fallan.

Y si metes todo eso dentro de una petición HTTP normal, estás comprando papeletas para tener problemas.

El backend no podía ser solo una API

Cuando empiezas en backend es normal imaginarlo así: el frontend hace una petición, Laravel la recibe, consulta la base de datos y devuelve una respuesta.

Para muchas partes de FácilSEO esto funciona perfectamente como para crear proyectos, consultar informes o actualizar configuraciones.

Todo eso encaja bien en ese modelo, pero el problema aparece con las tareas pesadas.

Un análisis SEO no debería competir con un login, un informe grande no debería afectar a la navegación del panel, un envío de email no debería bloquear una acción importante del usuario y una sincronización externa no debería ralentizar cosas que no tienen nada que ver.

Aquí apareció una de las primeras decisiones importantes: separar lo urgente de lo pesado.

La API tiene que responder rápido ya que su trabajo no es hacerlo todo, sino coordinar:

Recibe la petición, valida, guarda el estado inicial y delega el trabajo pesado.

Y esa otra parte son los workers.

Cuando un usuario lanza un análisis, el backend no lo ejecuta en ese momento, sino que registra que hay un análisis pendiente y manda un trabajo a una cola.

Después, un proceso en segundo plano recoge ese trabajo y lo ejecuta.

Cambio de mentalidad

Este cambio parece técnico, pero en realidad es de mentalidad.

Dejas de pensar en el backend como una máquina que responde a todo al instante.

Y empiezas a verlo como un sistema donde cada pieza tiene un papel claro.

La API coordina, los workers ejecutan, el usuario consulta el estado y el sistema puede seguir funcionando aunque haya tareas lentas en marcha.

Esto, cuando lo interiorizas, cambia completamente cómo diseñas backend.

FácilSEO está montado con varios servicios en Docker, pero no porque Docker sea arquitectura por sí mismo ya que docker solo te da contenedores.

La arquitectura aparece cuando decides qué responsabilidad tiene cada uno.

Aquí hay un backend principal en Laravel, una base de datos que guarda el estado persistente y luego Redis que ayuda con caché y datos temporales.

Hasta aquí, todo bastante estándar.

Lo interesante llega cuando miras las colas ya que no hay una única cola donde se mete todo, sino que hay colas separadas según el tipo de trabajo.

Análisis pesados, tareas generales, emails o s incronizaciones.

Esto, aunque parezca un detalle interno, es clave porque si metes todo en una única cola, cualquier pico de carga puede afectar a todo lo demás.

Unos cuantos análisis pesados pueden retrasar emails o una sincronización lenta puede bloquear otras tareas.

Separar colas permite aislar la carga.

Y eso no se nota en local, pero cuando hay usuarios reales ves realmente la optimización.

Suscríbete ahora

Compartir

Una idea importante si estás empezando

Si eres junior, aquí es fácil sacar una mala conclusión.

Pensar que necesitas Docker, Redis, colas y toda esta infraestructura desde el primer día.

Y no, esa no es la lección.

La lección es otra: antes de pensar en herramientas, piensa en responsabilidades.

Cuando estés diseñando una aplicación, hazte estas preguntas:

• Qué debe responder rápido.

• Qué puede ejecutarse en segundo plano.

• Qué puede fallar.

• Qué no debería bloquear al usuario.

Si entiendes eso, la arquitectura empieza a tener sentido y las herramientas dejan de ser postureo técnico para convertirse en soluciones a problemas reales.

Al final, todo esto no va de usar más cosas, sino que va de entender mejor el problema que estás resolviendo.

Y FácilSEO me está sirviendo justo para eso: para tomar decisiones reales, con problemas reales, y ver qué pasa cuando el sistema empieza a tener vida más allá de localhost.

En las próximas entregas vamos a seguir usando FácilSEO como excusa para aprender backend de verdad.

Iremos bajando más al detalle: cómo tratar webs modernas que dependen de JavaScript, cómo está montado el renderer y cómo se diseña un sistema que sigue siendo razonable cuando empiezan a fallar cosas.

Nos leemos en la próxima,

Julián

Hubo charlas de todo tipo, pero dos me marcaron: una sobre email marketing de Marga Camps y otra sobre marca y copywriting de Rosa Morel.

Fue en esta última donde tuve un momento de claridad.

Una reflexión que conecta directamente con lo que significa ser un programador hoy en día y cómo gestionar tu carrera profesional.

Por cierto… ¿Has visto mi último lanzamiento?

La semana pasada lancé FácilSEO, una plataforma destinada a ayudar a los análisis SEO y de rendimiento web, con el objetivo de facilitarte los análisis, la búsqueda de mejoras en tu web, la elaboración de informes y automatizaciones para ti o tus clientes.

Puedes usar el código CEROASENIOR15 en el momento del registro para tener 15 días GRATIS del plan pro (no hace falta meter tarjeta alguna ni se te cobrará nada al acabar el periodo de prueba)

Prúebalo aquí

Antes de empezar a contarte un poco sobre la reflexión que me llevé (y quiero compartir contigo) de la charla de Rosa Morel, déjame que te cuente quién es y por qué es importante hacerle caso (al menos en esto).

Rosa lleva 17 años siendo una de las voces más influyentes del copywriting en español. En su ponencia, soltó una frase que me quedó grabada a fuego:

“Las personas quieren trabajar conmigo.”

No dijo que quieren trabajar con una copywriter, ni con la más barata. Quieren trabajar con ella.

En un mundo donde la IA puede generar código y contenido en segundos, crear una voz y una identidad es lo único que te hace irreemplazable.

Cuando construyes tu marca personal, dejas de competir por habilidades técnicas y empiezas a competir por percepción, confianza y trayectoria.

Tu trabajo deja de ser lo que haces, para convertirse en lo que representas

Qué me llevó a crear mi marca personal

Porque, si te soy sincero, eso fue exactamente lo que yo intenté hacer hace unos años.

Si estás leyendo esta newsletter, probablemente vienes de Twitter (o alguien te la ha recomendado).

Y no es casualidad, ya que tengo ahí una comunidad de casi 25.000 personas interesadas en el mundo del desarrollo.

Ahí es donde he construido la mayor parte de mi marca personal.

Empecé en 2022, en un momento en el que decidí darle un giro completo a mi vida: mudarme a Francia, dejar atrás mi situación anterior y apostar por convertirme en programador.

Pero entendí algo rápido: buscar trabajo no era suficiente, si quería destacar, tenía que hacer algo más: tenía que diferenciarme.

No porque no creyera que mis habilidades técnicas (hard y soft skills) no fueran suficientes, sino porque veía cómo estaba evolucionando el mercado después de un par de años tras la pandemia del COVID y veía que saber programar, no iba a ser suficiente en el futuro.

Y ahí fue donde empecé a construir mi marca personal: creando contenido, compartiendo mi proceso y enseñando lo que iba aprendiendo en el camino.

¿Por qué deberías tú trabajar tu marca personal?

Todo esto suena muy bien en teoría. Pero… ¿qué significa realmente construir una marca personal?

Porque muchas veces se queda en algo abstracto.

Si eres junior, últimamente habrás escuchado (más con la poca oferta que hay actualmente) que hay que diferenciarse, ser auténtico, aportar valor.. pero nadie te explica qué cambia de verdad cuando lo haces.

Yo voy a intentar diferenciarme (de verdad) y darte motivos de por qué deberías trabajar tu marca personal para crecer profesionalmente, pero basados en mi experiencia.

En mi caso, el trabajar mi marca ayudó, con el tiempo, a que hubiera tres cambios muy claros.

1. Dejé de depender únicamente de buscar oportunidades

Las oportunidades empezaron a encontrarme a mí.

Durante los años que estuve trabajando mi marca personal y mi presencia online, me llegaron gracias a esto oportunidades para colaborar con empresas como creador de contenido y, también, oportunidades laborales.

Tienes que tener claro que el crear tu marca personal te va a aportar beneficios laborales tanto si eres freelance como si trabajas por cuenta ajena.

Si eres freelance, significa dejar de perseguir clientes constantemente. Empiezas a generar un flujo de personas que ya vienen con interés previo en lo que haces.

Y si trabajas en empresa, significa algo igual de valioso: visibilidad.

Recruiters, managers o incluso otros equipos empiezan a fijarse en ti sin que tengas que estar enviando CVs constantemente.

Y esto lo he visto no solo en mi caso, sino en varios creadores de contenido que siguen trabajando para empresas y que cuando han salido de una, han publicado un post en LinkedIn y al cabo de las semanas ya habían cerrado una oferta.

2. Empecé a generar confianza en los demás.

El trabajar mi marca personal también me ayudó a generar confianza antes incluso de hablar con alguien.

Cuando alguien llegaba, esta persona ya sabía cómo pensaba, cómo trabajaba y qué podía esperar.

No empezábamos desde cero. Esta persona tenía mucha información sobre mí y mi contexto.

Y esto, de nuevo, cambia mucho las reglas del juego.

Como freelance, reduces fricción en ventas: menos llamadas eternas, menos necesidad de convencer.

Y como empleado, te posiciona mejor en procesos de selección o incluso dentro de tu propia empresa.

No eres un desconocido, eres alguien con contexto.

3. Dejas de ser intercambiable

O al menos tan fácilmente, porque programadores hay muchos.

Pero mi forma de comunicar, de enseñar y de compartir… eso ya no es tan fácil de replicar, y aquí está uno de los puntos más importantes:

Sin marca personal, compites por precio o por CV.

Con marca personal, compites por quién eres.

Y eso aplica a todo: si eres freelance puedes justificar mejor tus tarifas y si buscas trabajo en empresa puedes diferenciarte más allá de tu experiencia técnica.

Cómo puedes construir una marca personal

Ahora bien. Todo esto suena muy bien, pero no ocurre por publicar dos hilos en Twitter o subir tres vídeos a YouTube.

Hay algo más profundo detrás.

En mi caso, hubo varias decisiones que marcaron la diferencia:

La primera fue dejar de intentar parecer experto y empezar a documentar.

Durante mucho tiempo pensé que tenía que saber más para poder enseñar. Pero la realidad es que lo que más conecta no es el resultado, es el proceso. Empecé a compartir lo que iba aprendiendo, los errores que cometía, las dudas que tenía…

Y eso hizo que muchas personas se vieran reflejadas porque lo que fui mostrando era el camino que iba recorriendo.

La segunda fue tener muy claro a quién le estaba hablando.

No escribía para todo el mundo, sino que lo hacía para un público muy concreto, para personas que estaban en un punto más inicial de su carrera.

Es por eso que si ves mis primeros hilos de Twitter, verás que se trataban la mayoría de hilos de cursos gratuitos para aprender las bases de programación.

Gente que quería empezar en programación, que estaba perdida o que estaba pasando por el mismo proceso que yo había pasado meses antes.

Y eso cambia completamente cómo comunicas.

La tercera fue entender que esto no va de viralidad.

Todo esto trata de repetición (esto, de hecho, lo he aprendido hace poco).

Durante los últimos meses he estado muy centrado en mi trabajo, en los proyectos de mis clientes y es por eso que he dejado las redes un poco (bastante) de lado, notando una bajada de todo: impresiones y oportunidades.

Y esto no ha pasado porque el contenido que haga sea menos interesante, sino porque he sido mucho menos constante.

Cada vez tengo más claro que redes y algoritmos premian que estés pasando tiempo en sus redes, nunca mejor dicho.

Así que además de hacer buen y útil contenido tienes que tener claro que esto también trata de estar ahí incluso cuando parece que nadie está mirando.

De publicar cuando no tienes feedback, de seguir cuando los números no acompañan y de construir algo que no da resultados inmediatos.

Porque la marca personal no crece en picos. Crece en acumulación.

Suscríbete ahora

Compartir

Y hay una última cosa que no se suele decir: tu marca personal no es solo el contenido que publicas.

Es cómo piensas, cómo explicas, cómo enfocas los problemas: es tu criterio.

Porque al final, lo que hace que alguien te siga o confíe en ti no es que sepas mucho, es cómo haces que lo que sabes tenga sentido para otros.

Cuando aplicas y asimilas esto, tu mentalidad empieza a cambiar y con el tiempo pasa algo curioso.

Dejas de pensar en “qué contenido hago hoy” y empiezas a pensar en “qué quiero decir realmente”.

Porque en un mundo donde la IA puede generar contenido en segundos… lo único que no puede replicar es esto: tu historia y tu manera de ver el mundo.

Y por eso, al final, la frase de Rosa Morel cobra todo el sentido:

“Las personas quieren trabajar conmigo.”

No por lo que sabes, sino por quién eres.

Ten esto muy claro y llévate este aprendizaje:

No esperes a sentirte preparado para empezar a construir tu marca personal. Empieza ahora.

Porque dentro de unos meses, o unos años… te alegrarás de haberlo hecho.

Julián

Sí, lo he hecho, aunque antes de que cierres enfadado este email, déjame que te expliqué qué he hecho, por qué lo he hecho y por qué el resultado de todo esto ha sido de que te he engañado sin quererlo.

Te prometo de que te va a sorprender un poco todo esto pero, primero, empezaré a explicar de qué va todo esto.

Durante unos cuantos meses, desde comienzos de noviembre, llevo compartiendo en la Newsletter el desarrollo de un producto, KPIAds.app

El objetivo era compartir contigo el desarrollo desde completamente cero, a partir de una idea, de un producto digital que pudiera diseñar, desarrollar, vender y enseñarte todo el proceso sin ningún filtro.

Te quería enseñar el desarrollo de mi primer MVP y… te he fallado y engañado.

Pero ojo, no es porque no esté desarrollando KPIAds o no te lo vaya a mostrar.

Aunque voy lento (el trabajo como freelance los últimos meses no va mal y me ocupa bastante tiempo), sigo con KPIAds.

Lo que pasa es que… no ha sido mi primer MVP ni el primer proyecto que lanzo en 2026.

Igual me he puesto un poco dramático con lo de que te he engañado, ya que intento ser siempre lo más honesto posible, ya sea en esta Newsletter, redes o la vida misma.

¿La verdad? En verano empecé a desarrollar un proyecto, hice todo el backend y… me olvidé hasta hace un par de semanas en la que me saltó la renovación del dominio.

Y bueno, pues me dije… ¿y por qué no lo continuamos? total, “solo” me queda el frontend y quizás, tirando con Codex, pueda sacarlo más o menos rápido.

Y aquí estoy, dos semanas y mucho trabajo después, sacando a la luz FacilSEO.com y, por supuesto, contándotelo a ti el primero de todos, que para algo estás suscrito a la Newsletter.

¿Qué es FacilSEO?

Empezaré por el principio explicando en qué consiste FacilSEO (aunque esto es el final de todo el desarrollo).

FacilSEO se trata de una herramienta que he ideado para facilitar todo el análisis SEO de una página web, tener todos los datos, recomendaciones, reportes… en fin, una herramienta para facilitarte toda la gestión SEO y de rendimiento de tu web.

El proyecto nació como una necesidad propia y es que durante un año he estado trabajando mano a mano con una agencia de Growth Partner y me cansaba de hacer análisis a webs y tener que pasar a mano reportes de cómo estaba la web a nivel SEO y a nivel de mejoras de rendimiento (pagespeed).

A cada cliente que entraba, me pedían un PDF con el análisis de la web y mejoras que se podían hacer y… a cada cliente que entraba, perdía mucho tiempo en hacer esto a mano.

Así que pensé en utilizar alguna herramienta para hacer esto pero.. ninguna me convenció.

No porque no haya herramientas que te hacen buenos análisis o no haya diferentes herramientas con las que pueda hacer las diferentes partes de estos reportes… sino porque no había una herramienta que me permitiera hacer todo en ella y tener un PDF listo para entregar.

Yo quería algo que me permitiera añadir un proyecto (para tenerlo así controlado a lo largo del tiempo), analizar y generar un PDF con todo sin dolores de cabeza.

Y bueno, ya sabemos el resultado… como soy desarrollador, me lo hice a mí mismo.

Las funcionalidades (por ahora) de FacilSEO

Te voy a enseñar lo que ya puedes hacer hoy con FacilSEO, pero no como una lista de cosas técnicas… sino como lo que realmente significa para ti:

• Detectar en minutos qué está frenando el SEO de una web, sin tener que revisar 10 herramientas distintas ni perder horas investigando.

• Saber exactamente qué mejorar en velocidad (móvil y escritorio), con acciones claras, no métricas vacías.

• Tener una puntuación SEO clara y accionable, para entender en segundos si una web está bien… o necesita ayuda urgente.

• Gestionar múltiples proyectos sin caos, puedes añadir URLs manualmente, importa sitemaps o CSV y ten todo organizado desde el minuto uno.

• Ver qué cambia entre análisis, para no trabajar a ciegas y saber si lo que haces realmente mejora algo.

• Trabajar con datos reales de Google Search Console, sin depender de estimaciones o datos poco fiables.

• Monitorizar keywords con histórico y detectar oportunidades sin estar entrando cada día a mirar.

• Automatizar informes para clientes o equipo. Semanal, quincenal o mensual… sin volver a hacerlos a mano nunca más.

• Enviar informes profesionales (con tu branding) para dejar de parecer uno más y empezar a parecer una agencia seria.

• Probar todo gratis con un análisis por URL y ver el valor en menos de 2 minutos.

Básicamente, lo que he construido es la herramienta que me habría ahorrado decenas de horas durante el último año.

Y ahora la tienes tú también.

Pero el desarrollo no acaba aquí

La verdad, tengo la sensación de que es una lista grande de funcionalidades… que aporta un valor muy minúsculo.

Creo, sinceramente, que FacilSEO tiene mucho más margen de mejora y muchas más funcionalidades que puedo desarrollar y con las que el valor de la herramienta aumentaría mucho.

Peeeeero.. es un MVP y hay que lanzarlo rápido.

Hay que lanzar rápido, ver si hay un mínimo interés, validar la idea y si esos primeros tests salen bien.. entonces seguir creciendo la herramienta.

Tengo una gran lista de ideas para desarrollar: desde el análisis de competidores, optimización global teniendo en cuenta de si un sitio tiene artículos o no… hasta la integración de la IA.

Todo dependerá del feedback que reciba en el proyecto.

Puedes probar FacilSEO desde hoy (early adopters)

Así que sí, he decidido abrir FacilSEO desde ya.

Pero no como un lanzamiento perfecto… sino como una versión early para los primeros que quieran probarlo, usarlo y ayudarme a mejorarlo.

Y si estás leyendo esto, estás dentro de ese grupo.

🆓 Tienes una versión gratuita para empezar

Puedes usar FacilSEO gratis desde el minuto 1, sin pagar nada.

Perfecto para probar cómo funciona, hacer algún análisis puntual y ver si encaja contigo.

🎁 15 días gratis + precio early exclusivo

Por ser miembro de CERO a SENIOR, puedes probar FacilSEO durante 15 días totalmente gratis con este cupón:

👉 CEROASENIOR15

Y además, si decides quedarte:

• Precio normal: 10€/mes (120€/año)

• Precio early adopters: 90€/año

Es decir, entras antes, pagas menos… y además puedes influir en cómo evoluciona el producto.

Lo que sí valoraría mucho es si usas

Me gustaría pedirte un favor…

Si decides probar FacilSEO, ya sea con el plan gratuito o con una suscripción, me gustaría pedirte el favor de pasarme feedback, de lo bueno y de lo malo.

Yo he creado esta herramienta sabiendo todo el contexto y aunque he intentado pensar en cómo usaría la herramienta alguien que viene de nuevas y no tiene ni idea de esto… igual no lo he conseguido.

Por eso he habilitado en esta primera versión una herramienta para mandarme Feedback.

Lo tienes disponible en la esquina inferior derecha: un botoncito con un formulario que me mandará el feedback directa al panel de administrador.

Soy consciente de que la herramienta está lejos de ser perfecta, tanto a nivel de diseño, usabilidad o de funciones.

No soy ningún experto en SEO (ni pretendo serlo), por lo que seguramente muchas personas que estén en la Newsletter sabrán mucho más que yo y valoraría mucho su opinión.

Compartir

Suscríbete ahora

Bueno, creo que ya me he explayado bastante sobre el lanzamiento de FacilSEO.

Me he dejado toda la parte técnica del desarrollo, pero no te preocupes, en siguientes ediciones de CERO a SENIOR te compartiré las entrañas técnicas tanto de infraestructura, backend y frontend.

Sin más, espero que te resulte útil la herramienta y me compartas qué te parece.

Nos leemos en la próxima,

Julián.

La IA está provocando despidos en el mundo de la programación… o al menos, eso nos quieren hacer creer mucha gente.

Si estás al tanto de las noticias, igual has sabido que Capgemini ha anunciado un ERE en España, justificándose en la necesidad de adaptarse al nuevo paradigma marcado por la Inteligencia Artificial.

Y si lo lees tal cual y sin pensar mucho sobre la noticia, los fácil es quedarse con la idea de que la IA está provocando despidos.

Pero, si rascas un poco más, puedes ver que la realidad es bastante más compleja.

Capgemini, una de las consultoras más importantes en España y también Europa, ha anunciado un ERE (despido selectivo) en España.

En su explicación oficial, la empresa justifica esta tanda de despidos por los cambios en el mercado, las nuevas demandas de los cliente, la necesidad de adaptarse rápido y el impacto de la IA en todo esto.

A priori, todo esto suena lógico e incluso inevitable.

De hecho, no hacemos más que leer este tipo de reflexión por LinkedIn y otras redes sociales.

Pero en esa noticia, hay un detalle importante:

Capgemini no es una empresa en crisis, tampoco está desapareciendo y no está dejando de ganar dinero…

Y aun así, quiere reducir plantilla.

Aquí empieza la parte incómoda

Porque no todos los despidos en empresas tienen la misma causa y no todo se puede explicar por la IA.

En muchos casos, y sobre todo en consultoras como Capgemini, lo que hay detrás también es una presión por mejorar márgenes, decisiones estratégicas, reestructuraciones internas e intereses de inversores.

Y sí, en este contexto, la IA puede ser una causa real para la reducción de empleos… pero también una excusa conveniente.

Recuerda, en este caso en concreto, estamos hablando de una consultora… y eso cambia bastante el contexto.

Y es que una consultora no gana dinero desarrollando software o creando un producto.

No, una consultora gana dinero vendiendo horas de personas.

Su modelo es, simplificando mucho, el siguiente:

• Contrata talento (normalmente personas con poca experiencia que le cuesta encontrar esas primeras oportunidades)

• Asignarlo a proyectos de clientes.

• Facturar esas horas a clientes.

Y aquí, en este modelo, hay dos variables clave:

1. La ocupación: tener gente trabajando en proyectos.

2. El margen: cuánto ganas por cada persona.

Cuando el mercado aprieta (menos proyectos, más competencia y clientes negociando precios) el problema no es técnico, es financiero.

Y si una consultora detecta que los proyectos pagan menos, los clientes exigen más por menos o tienen gente sin asignación de proyecto… Tienen varias opciones:

1. Subir precios (difícil en un mercado competitivo).

2. Reducir costes.

3. Reestructurar equipos.

Y es aquí donde aparecen los despidos.

No necesariamente porque sobre gente en términos absolutos, sino porque no encaja en la rentabilidad actual del negocio.

El papel de la IA en todo esto

Aquí es donde el asunto se vuelve interesante y donde tenemos que entender que, aunque la IA no vaya a hacer desaparecer a los programadores, sí tiene un impacto real:

La IA, a día de hoy, permite hacer tareas más rápido, reduce ciertas necesidades operativas y cambia los perfiles que se demandan.

Eso es así y no me canso de repetirlo: hay que adaptarse y empezar a aportar más valor que el desarrollo de código.

Pero en realidad, en este caso, el de una consultora que está despidiendo gente, el papel de la IA es muchas veces más indirecto.

La IA está permitiendo acelerar decisiones que ya eran económicamente deseables.

Es decir:

• Si puedes hacer lo mismo con menos gente, estás mejorando margen.

• Si puedes vender la IA como valor, reposicionas tu oferta.

• Y si necesitas ajustar estructura, tienes un argumento sólido.

Pero ojo, no quiero decir que la IA sea irrelevante, sino que tampoco es toda la historia.

En muchos casos el argumento de la IA funciona como catalizador para acelerar cambios reales, justificación legítima para decisiones internas y una narrativa que explica hacia fuera algo complejo de forma simple.

Porque sí, es más fácil decir que es por la IA que explicar en detalle decisiones de negocio, márgenes o estrategia.

Por qué esto importa (de verdad)

Entender todo esto significa que empiezas a entender la realidad.

Si te quedas con el titular de “La IA está quitando empleos” puedes sacar conclusiones equivocadas.

Pero si entiendes el contexto completo empezarás a ver cómo funcionan las empresas, entenderás por qué toman ciertas decisiones y, sobre todo, puedes anticiparte mejor.

Entender que no todas las decisiones son meramente técnicas es importante para ti, sobre todo si estás empezando en este mundo.

Porque esto cambia la pregunta que te puedes hacer en tus comienzos, ya que ahora no te preguntarás cómo aprendo a programar.

Sino que te tendrás que empezar a preguntar cosas como:

• ¿Dónde encajo yo en este modelo de negocio?

• ¿Qué tipo de perfil es rentable para una empresa?

• ¿Qué me hace menos prescindible?

Empieza a trabajar tu espíritu crítico y no te creas todas las narrativas.

Ni la narrativa catastrofista, ni la optimista, ni la empresarial… ni la mía en esta entrega.

Aprender a leer entre líneas, a analizar tu mismo la situación ya construir tu propio criterio.

Empieza también a construir valor más allá del código.

Porque el código, cada vez más, es accesible por todo el mundo.

Lo que marca la diferencia es entender problemas, pensar en producto y tener criterio.

Usa la IA con cabeza, no como un sustituto, sino como una herramienta.

La diferencia entre uno y otro perfil va a ser cada vez más evidente.

Y, por último, acepta que el mercado es más complejo.

Ya no vale con una explicación simple y eso, aunque incomode, te hace más fuerte si lo entiendes.

Compartir

Deja un comentario

Sí, la IA influye.

El mercado también.

Y las decisiones empresariales… aun más.

Pero aquí lo importante es entender que no estás compitiendo solo a nivel técnico, sino dentro de un sistema económico con sus propias reglas.

Y cuanto antes entiendas esas reglas… mejor sabrás jugar.

Nos leemos en la próxima,

Julián.

Es por ello que hace también ya algún tiempo que las entregas de la Newsletter están siendo de una a la semana, en lugar de las 2 que teníamos con el desarrollo del SaaS.

Pero, como te dije al principio, esto es sin prisa, pero sin pausa. El desarrollo de mi SaaS sigue adelante y hoy retomamos donde lo dejamos.

Hay un punto en el desarrollo de cualquier producto donde el código ya no cabe en la cabeza.

Al principio todo es sencillo: un par de controladores, algunos modelos, unas cuantas vistas... tienes la sensación de que controlas todos los hilos.

Pero, a medida que el producto crece, la realidad te explota en la cara:

• Ingestas de datos que tardan varios minutos.

• Peticiones a APIs externas que fallan o van lentas.

• Cálculos de métricas que devoran la CPU.

• Lógicas de negocio que dependen del estado de otros módulos (suscripciones, facturas…).

Si intentas meter todo eso en controladores, el sistema se convierte en lo de siempre: un monolito que funciona… pero que es un infierno mantener.

En esta fase de KPIAds, el objetivo es otro: que el monolito se hable bien por dentro. Que cada parte se entere de lo que pasa sin acoplarse a las demás y que lo pesado se mueva a un segundo plano.

Para lograrlo, vamos a usar cuatro piezas de artillería: Domain Events, Listeners, Jobs y Colas con Redis + Horizon.

Domain Events: contar lo que ha pasado

La idea de un Domain Event es sencilla: representa algo que ya ha ocurrido en el negocio. No es una orden directa (haz esto), es un hecho (esto ha pasado).

En KPIAds, he definido eventos que cuentan la historia del sistema: UserRegistered, ProjectCreated, IngestionRunStarted. En Laravel, esto es una clase limpia que lanza un mensaje al aire:

“Oye, se ha iniciado una ingesta. Quien necesite reaccionar, que reaccione”.

Separar la lógica: Listeners y Jobs

Aquí es donde separamos el grano de la paja. El Listener es el estratega y el Job es el obrero.

• El Listener: responde al evento. Su única responsabilidad es decidir qué hay que hacer. Si empieza una ingesta, el Listener decide qué fuentes preparar y manda a alguien a trabajar.

• El Job: es la unidad de trabajo pesada. Se ejecuta en background y no bloquea al usuario. En KPIAds, los Jobs se encargan de lo sucio: llamar a APIs de Ads o recalcular métricas.

El motor: Redis + Horizon

Si intentas hacer todo esto dentro de la petición del usuario, la web irá lenta y se romperá. Por eso usamos Redis como base de datos en memoria para gestionar las colas y Laravel Horizon para vigilarlo todo.

El flujo real en KPIAds cuando lanzas una ingesta es este:

1. Action: crea el registro en la DB y dispara el evento. El usuario recibe un “OK” al instante.

2. Listener: escucha el evento y despacha el ExecuteIngestionJob a la cola.

3. Worker (Background): el Job se despierta, llama a las APIs, guarda los datos y, al terminar, dispara un nuevo evento IngestionCompleted.

Resultado: el usuario nunca vio una pantalla de carga infinita.

Anatomía de un flujo asíncrono: Del evento al trabajo real

Para un Senior, el código no son solo instrucciones, son contratos entre capas. En KPIAds, hemos estructurado esta comunicación para que sea totalmente ciega: el que lanza el evento no sabe quién lo escucha, y el que hace el trabajo no sabe quién lo pidió.

Así se traduce esto al editor:

1. El Evento: es un simple objeto de transporte de datos (DTO). No tiene lógica, solo contiene la información mínima necesaria para que los demás entiendan el contexto.

2. El Listener: su trabajo es puramente orquestador. Aquí es donde desacoplamos módulos. Si mañana queremos que al empezar una ingesta también se envíe un mensaje a Slack, solo tenemos que añadir otro Listener, sin tocar una sola línea del código original.

3. El Job: aquí es donde vive la fuerza bruta. Este código se ejecuta en un proceso aparte gracias a Redis. Si la API de Google Ads tarda 30 segundos en responder, no importa: el usuario ya está navegando por otra parte de la App.

Deja un comentario

Compartir

La diferencia entre un programador Junior y uno Senior no está en cuántas líneas escribe, sino en cómo se hablan las piezas de su sistema.

• Un monolito bien diseñado es un conjunto de contextos que colaboran.

• Los Domain Events cuentan la historia de tu negocio.

• Las Colas hacen que el sistema sea rápido para el usuario sin dejar de ser potente por dentro.

Diseñar así es lo que te asegura que tu software esté preparado para escalar y, sobre todo, para que cuando vuelvas al código dentro de tres meses (después de estar absorbido por otros clientes), entiendas perfectamente qué está pasando.

¿Te ha quedado clara esta separación de conceptos? ¿Quieres que la semana que viene veamos cómo monitorizamos con Horizon que todo esto no explote en producción?

Nos vemos en la próxima entrega.

Julián

No va de backend, frontend, arquitectura o testing, sino que son preguntas que en algún punto de mi carrera me planteé y creo que si no lo has hecho, tú también deberías.

Porque cambia la forma en la que ves tu carrera y en cómo te adaptas al constante cambio al que estamos sometidos.

Y es que…

¿En qué punto podemos considerarnos programadores?

¿Es un punto que va cambiando con el tiempo y la evolución de la tecnología?

Igual parecen dos preguntas muy sencillas y tontas, pero es que hay algo que veo constantemente cuando alguien empieza en programación.

Algo por lo que yo también pasé.

Y se trata de una especie de checklist o roadmap mental:

Primero, aprender JavaScript (o pon la tecnología que quieras).

Luego, aprender React.

Para después aprender un framework de backend y hacer algunos proyectos.

Todo eso para llegar a ese momento en el que piensas:

Y entonces llega ese momento en el que piensas: ya sé programar.

Creo que es un proceso por el que muchos pasan y sí, yo también lo pensé en su día.

Y estaba bastante equivocado.

Programar no es escribir código

Y es que durante mucho tiempo confundimos estas dos cosas.

A menudo pensamos que programar es saber sintaxis, conocer un framework, montar componentes o saber hacer llamadas a una API.

Puede parecer lógico, pero sinceramente creo que eso no es programar.

Todo esto que he mencionado se trata de saber usar herramientas, procesos en los que el factor humano no es importante.

Sinceramente pienso que programar de verdad es otra cosa: se trata de entender el problema, de dividirlo en partes, es tomar decisiones y saber qué hacer… cuando nadie te dice qué hacer.

Esto es lo que diferencia el saber escribir código de ser programador.

Y cuando entiendes esto, es que todo cambia.

Cambia cómo trabajas, cambia tu valor para la empresa y cambia tu futuro profesional… sobre todo en tiempos de IA.

Porque hoy, herramientas como ChatGPT o Copilot ya hacen muy bien la parte fácil:

• Escribir código

• Montar estructuras

• Generar soluciones “válidas”

Es decir, lo que antes te hacía sentir que avanzabas o que aportabas como valor… ahora lo puede hacer una máquina en segundos.

Y ojo, que esto no es una amenaza: simplemente es un filtro.

La IA no sustituye programadores (no a todos)

No te voy a mentir, hay veces en las que yo también me pongo en modo pesimista con la evolución que puede tener la IA y cómo nos puede afectar a los programadores.

Pero en esos momentos, me pongo a analizar bien la situación y siempre llego a la misma conclusión:

La IA no te quita el trabajo por saber menos sintaxis. Te lo quita si solo sabes eso.

Porque si tu valor como programador es escribir código, no eres imprescindible.

La IA ya puede generar funciones, componentes, endpoints e incluso estructuras completas en segundos. Lo que antes te llevaba horas, ahora lo tienes en minutos.

Pero hay algo que no puede hacer por ti, y es entender el contexto real de un problema.

No sabe qué necesita de verdad el cliente, no entiende qué partes del sistema son críticas, ni qué decisiones técnicas te pueden explotar dentro de seis meses. Tampoco entiende los trade-offs que estás aceptando cuando eliges una solución u otra.

Y ahí es donde está la diferencia. Porque programar no es producir líneas de código, es tomar decisiones bajo incertidumbre. Es priorizar, simplificar y, muchas veces, saber qué no hacer.

Por eso, cuando tu valor está en pensar, diseñar y decidir, la IA deja de ser una amenaza y se convierte en una ventaja brutal.

Te permite ir más rápido, probar más opciones y centrarte en lo importante. Pero la dirección sigue dependiendo de ti. Y esa diferencia, cada vez, va a ser más grande.

La diferencia real

No me cansaré de repetirlo en las entregas de esta Newsletter, pero tu carrera cambia cuando entiendes la diferencia de pensamiento entre un programador junior a uno senior.

Y es que un junior piensa: “¿Cómo hago esto en X tecnología?”.

Un programador empieza a pensar: “¿Qué problema estoy resolviendo?”.

Y un senior va un paso más allá: “¿Cuál es la mejor forma de resolver esto con el menor coste y complejidad?”.

Esa diferencia no está en el lenguaje, sino que se encuentra en tu cabeza.

Cómo aplicar esto en tu trabajo (aunque solo te den tickets)

Aquí es donde mucha gente se queda atascada. Porque piensan: “vale, todo esto está muy bien… pero yo estoy en una consultora resolviendo tickets todo el día.”

Y es verdad. Tu día a día seguramente sea un ticket en Jira, una descripción más o menos clara, un trozo de código que no has escrito tú… y ejecutar.

Pero incluso en ese contexto puedes marcar una diferencia enorme.

Puedes hacer el ticket como un ejecutor: lees lo que te piden, haces lo mínimo para que funcione y pasas al siguiente.

O puedes hacerlo como un programador: entiendes qué problema real hay detrás, revisas si la solución encaja con el sistema, detectas posibles efectos secundarios y mejoras ligeramente el código que estás tocando.

Antes de escribir una sola línea de código, puedes empezar haciéndote mejores preguntas: ¿esto por qué está fallando realmente?, ¿hay más sitios donde pasa lo mismo?, ¿estoy arreglando el síntoma o la causa?, ¿esta solución va a escalar o es solo un parche temporal?

Ese pequeño cambio de enfoque ya te coloca en otro nivel.

Y mientras trabajas, puedes ir dejando el código un poco mejor de como lo encontraste.

No hace falta hacer nada espectacular: renombrar variables confusas, extraer lógica duplicada o simplificar una función ya es suficiente.

Son cambios pequeños, casi invisibles, pero que tienen un impacto enorme cuando los repites cada día.

Porque ahí está la clave: no es lo que haces en un ticket, es cómo lo haces.

Y cuando repites este enfoque durante semanas y meses, dejas de ser alguien que ejecuta tareas… y empiezas a ser alguien que entiende sistemas.

Compartir

Suscríbete ahora

Si estás empezando, este es el cambio clave: deja de medir tu progreso por las tecnologías que sabes y empieza a medirlo por los problemas que eres capaz de resolver.

Porque puedes saber cinco frameworks… y no saber programar.

O puedes entender cómo pensar… y aprender cualquier tecnología en semanas.

Si me preguntas qué haría hoy empezando desde cero, lo tendría claro: menos cursos, más problemas reales. Menos obsesión por herramientas y más foco en cómo pensar.

Porque al final, en un mundo donde la IA escribe código…

Tu valor no está en lo que escribes, está en lo que entiendes.

Nos vemos en la próxima.

Julián.

Un proyecto con bastantes horas de desarrollo ya detrás.

Con código difícil de leer, funciones enormes, duplicidad por todos lados y… una sensación constante de que todo estaba hecho un desastre.

Mi reacción fue inmediata.

No pasa nada. Esto lo arreglo yo en un par de días.

Spoiler: no lo arreglé. Lo rompí.

El impulso de querer rehacerlo todo

Cuando empiezas en programación, hay un momento en el que empiezas a ver lo que está mal.

Y eso es buena señal, ya que significa que estás creciendo.

El problema es lo que haces con esa información, porque lo más habitual es caer en la trampa de que la solución es rehacerlo todo desde cero.

Es un error muy de junior, vemos el código, vemos un desastre y empezamos a pensar en cambiar nombres, mover archivos, reestructurar carpetas, aplicar patrones de diseño..
Y ya que estás… “dejarlo bien de una vez”.

El famoso big bang.

Un cambio enorme que, en tu cabeza, va a solucionar todos los problemas.

Lo que no ves cuando haces un “big bang”

El problema de estos cambios no es la intención, es el impacto.

Cuando cambias demasiadas cosas a la vez:

No sabes qué ha roto qué.

No puedes probar bien cada parte.

El código se vuelve difícil de revisar.

Y el equipo pierde confianza en ese cambio.

Y aquí hay algo importante que muchos juniors no entienden al principio:

El problema no es solo que el código funcione, es que otros puedan confiar en él Porque en un entorno profesional, si tu cambio genera dudas… es un mal cambio.

La primera vez que entendí esto

Recuerdo perfectamente la primera vez que alguien me paró los pies con esto.

Abrí un Pull Request enorme.

De esos que te hacen sentir orgulloso ya que había “arreglado” medio módulo.

Al rato, un compañero más senior comentó algo que se me quedó grabado:

Esto no se puede revisar.

Ni siquiera entró a discutir si estaba bien o mal. Simplemente no era viable ya que era demasiado grande, demasiado arriesgado y demasiado difícil de entender.

Y ahí entendí algo que no te enseñan en cursos:

No todo lo que mejora el código… mejora el proyecto.

Cómo trabajan los seniors de verdad

Con el tiempo, empecé a fijarme en cómo trabajaban desarrolladores con experiencia.

Y me di cuenta de algo que al principio parecía contraintuitivo:

No hacían grandes cambios.

Hacían cambios pequeños, muy pequeños.

Igual parece que te lo estoy exagerando pero veía cambios de simplemente un nombre de variable, na función extraída.

De eliminar una duplicidad concreta o simplemente añadir un test unitario.

Nada espectacular.

Pero cada cambio tenía algo en común:

Era fácil de entender, era fácil de probar y era fácil de revertir.

Y eso lo cambiaba todo.

El poder de los pequeños pasos

Aquí está la clave:

Los sistemas complejos no se arreglan con grandes revoluciones Se arreglan con pequeñas mejoras constantes.

Cada pequeño cambio reduce un poco la complejidad y cada mejora deja el código un poco más limpio.

Cada refactor pequeño prepara el siguiente.

Y lo más importante:

No rompes todo en el proceso.

Refactorizar no es rehacer

Hay una diferencia enorme que me hubiera gustado entender antes:

Rehacer es destruir y volver a construir.

Refactorizar es mejorar sin cambiar el comportamiento.

Y eso, en la práctica, se hace así:

1. Tocas una parte del código.

2. La mejoras un poco.

3. Validas que todo sigue funcionando igual.

No hace falta más, no necesitas arreglar todo el sistema.

Sólo necesitas dejar mejor lo que has tocado.

Por qué los seniors no hacen “big bangs”

Porque entienden algo clave:

En programación, el riesgo importa más que la intención.

Los seniors no buscan hacerlo perfecto a la primera, sino que buscan avanzar sin romper.

Por eso trabajan en pasos pequeños.

Porque así pueden equivocarse sin consecuencias graves y eso les permite avanzar más rápido a largo plazo.

Compartir

Suscríbete ahora

Si estás empezando, quédate con esto:

No necesitas rehacer proyectos enteros para crecer como programador.

De hecho, muchas veces eso es lo que más te frena.

Aprende a mejorar poco a poco. A hacer cambios pequeños. A dejar el código un poco mejor de lo que lo encontraste.

Porque la diferencia entre un junior y un senior no está en hacer grandes cambios.

Está en saber dar el siguiente paso correcto.

Nos vemos en la próxima.

Julián.

Y no fue por falta de ganas.

Fue por algo mucho más común: y es que literalmente no tenía tiempo.

Ahora mismo estoy bastante metido en varios proyectos de clientes, con entregas, reuniones y bastante trabajo acumulado.

Y la realidad es que el domingo pasado, cuando normalmente envío esta newsletter, simplemente no llegué.

Además, ese mismo fin de semana estuve en la WordCamp Madrid, rodeado de desarrolladores, charlas, networking, cafés y conversaciones sobre WordPress, producto y tecnología.

Y por si fuera poco, los domingos estoy jugando un campeonato de ajedrez por equipos, así que tampoco tenía demasiado margen para sacar unas horas tranquilas para escribir.

Todo eso está muy bien.

Pero también me hizo pensar en algo que creo que muchos programadores olvidamos con facilidad:

No todo puede ser trabajar, aprender, programar y seguir programando.

Porque si no sabes parar… tarde o temprano el cuerpo te pasa factura.

El problema de querer correr demasiado

Cuando empiezas en programación, es muy fácil caer en una mentalidad peligrosa.

Quieres aprender todo lo antes posible.

Aprender un nuevo framework.

Hacer cursos.

Leer libros.

Practicar algoritmos.

Construir proyectos personales.

Trabajar en tickets.

Mirar código de otros.

Ver vídeos técnicos en YouTube.

Y si eres como muchos programadores que conozco (y como yo mismo he sido muchas veces), empiezas a sentir culpa cuando no estás programando.

Si descansas, sientes que otros están avanzando más rápido.

Si sales a dar un paseo, piensas que podrías estar aprendiendo Docker.

Si te tomas un día libre, imaginas a otro desarrollador aprendiendo y creando un vídeo de cómo está desarrollando un SaaS que le hará millonario.

Pero hay algo que casi nadie te cuenta cuando empiezas:

Esta carrera es una maratón, no un sprint.

Y el que intenta correr demasiado rápido al principio… normalmente no llega muy lejos.

Las redes sociales también pueden agotarte

Hoy en día hay otro factor que antes no existía tanto en nuestra profesión:

Las redes sociales.

Si estás en Twitter, LinkedIn o YouTube es muy fácil caer en una dinámica peligrosa.

Siempre parece que hay alguien que:

• Publica un hilo técnico cada día

• Lanza un vídeo nuevo cada semana

• Comparte tips de programación constantemente

• Crea cursos, artículos y proyectos sin parar

Y aunque muchas veces ese contenido es muy útil, también puede generar una sensación rara: la sensación de que nunca estás haciendo suficiente.

Además, si tú mismo creas contenido, el problema puede ser aún mayor.

Te lo digo por experiencia.

Durante mucho tiempo yo también he sido uno de esos programadores que no paran de crear contenido: vídeos, hilos, newsletter, ideas para nuevos proyectos…

Y hay momentos en los que sinceramente me entran ganas de quitarme todas las redes sociales.

Porque incluso cuando no estás trabajando para clientes, sigues conectado al mundo de la programación.

Sigues pensando en contenido.

Sigues leyendo sobre tecnología.

Sigues respondiendo comentarios.

Y al final nunca desconectas del todo.

El enemigo silencioso: el burnout

En el mundo del desarrollo hay una palabra que aparece cada vez más:

Burnout.

No es simplemente estar cansado, es algo más profundo.

Es esa sensación de abrir el editor de código y no tener ganas de escribir código, ver una nueva tarea en Jira y sentir rechazo inmediato, sentirte constantemente agotado, incluso después de dormir, perder la curiosidad por aprender cosas nuevas.

Y lo más peligroso es que el burnout no aparece de golpe.

Se construye poco a poco.

Meses trabajando sin parar.

Semanas sin desconectar del ordenador.

Fines de semana estudiando porque hay que ponerse al día.

Hasta que un día te das cuenta de algo inquietante:

La programación ya no te ilusiona.

Y eso es una tragedia en una profesión como la nuestra.

Porque si algo nos hace buenos desarrolladores es la curiosidad.

Cuando el burnout mata esa curiosidad, tu crecimiento profesional también se frena.

Incluso el ocio puede convertirse en otra obligación

Aquí viene algo curioso que me pasó la semana pasada.

Como te decía antes, los domingos estoy jugando un campeonato de ajedrez por equipos.

Y me gusta mucho el ajedrez, llevo jugando 27 años.

Pero cuando formas parte de un equipo ocurre algo interesante: no siempre puedes decir que no (y más si eres el presidente del club como yo).

Si faltas, estás dejando colgado al equipo.

Así que aunque en teoría sea ocio, también se convierte en un compromiso más en la agenda.

El domingo pasado, entre el campeonato, el trabajo acumulado y la semana que llevaba encima, simplemente no tenía energía mental para escribir la newsletter.

Y ahí me di cuenta de algo importante.

Para desconectar de verdad, muchas veces necesitas actividades que no impliquen compromisos fuertes.

Cosas que puedas hacer… o no hacer.

Sin presión.

Sin fechas.

Sin depender de otras personas.

El descanso también es parte de tu carrera

Hay algo curioso en programación y es que muchas veces las mejores soluciones no aparecen cuando estás programando.

Aparecen cuando te alejas del problema.

Mientras caminas, mientras haces deporte o mientras estás tomando un café.

Tu cerebro sigue procesando el problema en segundo plano.

Por eso muchos desarrolladores han tenido esa experiencia de:

Estar atascado durante dos horas.

Cerrar el portátil.

Y de repente, una hora después, entender exactamente cuál era la solución.

El descanso no es perder el tiempo, es parte del proceso mental que te hace mejor programador.

Deja un comentario

Compartir

Si he compartido esto contigo hoy es porque quiero que recuerdes algo si estás en los comienzos de tu carrera:

No necesitas programar todo el tiempo para llegar lejos, necesitas constancia durante años.

Y para mantener esas constancia necesitas descansar, desconectar y tener vida fuera de la pantalla.

Porque la carrera de un programador no se mide en semanas, ni meses ni años, se mide en décadas.

Y pienso firmemente que es mucho más fácil llegar lejos cuando sabes cerrar el portátil.

Piénsalo y mientras tanto, nos vemos en la próxima entrega.

Julián.

Aunque hay épocas que son mejores o más propicias para empezar en el mercado laboral que otras, no creo que haya una época en la que empezar sea realmente fácil.

Y bueno, hay situaciones en las que realmente no es que sea fácil, sino que es bastante complicado.

Esta reflexión (quizás algo obvia) te la estoy contando desde Faro, Portugal.

Aunque te la podía haber contado desde Córdoba, Barcelona, Menorca, Sofía (Bulgaria), Tarragona, Viena (Austria), Toulouse (Francia) o Madrid, que son muchos de los sitios que he visitado en el último año.

Desde que soy desarrollador Freelance.

Si me pongo a analizar en la situación que me encuentro hoy, la verdad, no me puedo quejar.

Muchos me dicen que vivo no bien, sino muy bien.

Porque me ven trabajando desde casa (remoto), eligiendo mis proyectos o clientes y con tiempo para otras cosas.

Aunque ojo, esto último no siempre, que el ser tu propio jefe también tiene su parte oscura.

Pero bueno, lo que no todo el mundo sabe es que mis comienzos no fueron para nada así.

Fueron mucho más confusos y duros.

Igual no lo sabes, pero mi camino no fue una línea recta. Si te lo resumo, se vería algo así:

• En 2018, empecé como programador freelance.

• En 2019, combiné mis proyectos freelance con mi trabajo como maestro de Educación Primaria.

• En 2020, el síndrome del impostor me pegó tan fuerte que decidí estudiar un Grado Superior de Aplicaciones Multiplataforma. Tenía conocimientos de sobra, pero necesitaba que un papel validara lo que yo sentía que me faltaba.

• En 2022, tomé la decisión que lo cambió todo: dejé el mundo freelance y el de maestro para irme a trabajar a una consultora en Francia (y bueno, a tener un golpe de realidad con el mercado laboral y lo que es trabajar en una empresa)

• En 2025, tras haber absorbido todo de esa etapa y haber trabajado en proyectos inmensos para gigantes como Airbus en Toulouse, volví a ser 100% freelance.

Y es en ese primer salto, entre el freelance de 2018 y el empleado de 2022, donde cometí el mayor error técnico de mi vida.

En 2018, tenía claro que me quería dedicar al mundo del desarrollo.

Había aprendido de manera autodidacta a programar con 14 años y ya tenía más de 6 años de experiencia por mi cuenta con PHP y desarrollo de Wordpress.

Lo tenía claro, pero también le tenía verdadero miedo a esa dureza inicial del mercado laboral.

A no tener un título oficial, a no tener experiencia demostrable y a las pruebas técnicas donde te desnudan los conocimientos y al síndrome de ser “el Junior” de la oficina.

Así que, por casualidades de la vida, tras presentarse un par de proyectos “gordos” de Wordpress para hacer como freelance, vi el camino fácil y me tiré de cabeza: decidí que iba a ser mi propio jefe desde el día uno.

Tenía proyectos que pagaban bien (bueno, hoy siendo objetivos ni levantaría la tapa del portátil para hacerlos).

Pensé que había hackeado el sistema ya que me salté las entrevistas de trabajo, a los Tech Leads exigentes y las jerarquías.

Trabajaba solo y mi única prueba de fuego era que el cliente (que no tenía ni idea de código) viera que la web funcionaba.

Entregaba los proyectos, cobraba, y la pantalla no daba error 500.

En mi cabeza, yo era un crack. Un desarrollador hecho a sí mismo.

Hasta que llegó 2022.

Ese año, tras compaginar el trabajo freelance con unos años de docencia, decidí que quería ir más allá.

Dejar los típicos proyectos de Wordpress y trabajar en proyectos grandes y reales.

Proyectos en los que me podía sentir realizado (cosas de hacer solo landings en WP).

Así que dejé esa burbuja en la que vivía y entré a la consultora en Francia y me integré, por primera vez, en un equipo de desarrollo de verdad.

Y ahí me llevé la mayor bofetada de realidad de toda mi carrera.

Mi primera semana me asignaron un ticket.

Escribí mi código (exactamente igual que lo hacía en mi casa), abrí mi primer Pull Request de la historia, y me fui a por un café sintiéndome intocable.

Al volver a mi sitio, vi la notificación de mi compañero más Senior.

Había decenas de comentarios en rojo destrozando mi código:

“¿Por qué haces una consulta a la base de datos dentro de este bucle?”

“Este controlador tiene demasiadas responsabilidades, sácalo a un servicio.”

“¿Dónde están los tests?”

“Esto no va a escalar cuando entren 1.000 usuarios de golpe.”

Sentí que me hervía la sangre, pero sobre todo, sentí una vergüenza terrible.

Ahí me di cuenta del precio que había pagado por tomar el camino fácil en 2018.

No era un buen programador.

Era un solucionador de problemas con años de vicios acumulados, que dejaba un rastro de deuda técnica en los proyectos.

Como había estado solo todo ese tiempo, mis malas prácticas eran mi estándar.

Como nunca tuve a nadie por encima, carecía de humildad técnica.

Al evitar la dureza de empezar como el novato de una empresa, me había privado del mayor acelerador profesional que existe: aprender de los errores de gente que sabe más que tú.

La ventaja de empezar tu carrera en una empresa

Aquel equipo en Francia me enseñó a base de palos (y muchísima paciencia) lo que significaba de verdad la ingeniería de software.

Tragarme el ego y sentarme a aprender de los que sabían más que yo me dio unas ventajas que jamás habría conseguido por mi cuenta:

• Entender el impacto del tráfico real: en mi casa, mis proyectos los usaban 10 personas al día. En la consultora, vi lo que pasa cuando entran miles de usuarios de golpe. Aprendí sobre sistemas de caché, race conditions y por qué una mala consulta a la base de datos te puede tirar el servidor entero en segundos.

• Escribir código para humanos, no para máquinas: como mis compañeros tenían que revisar y mantener mi trabajo, aprendí a nombrar variables con sentido, a aplicar principios SOLID y a separar responsabilidades. Descubrí cómo escribir realmente código limpio sin tener que leerme un libro.

• Flujos de trabajo y despliegues seguros: adiós a subir cosas a lo loco al repositorio. Me enseñaron a usar Git en equipo, pipelines de Integración Continua (CI/CD) y a hacer despliegues automatizados donde nadie tenía que cruzar los dedos y rezar para que producción no explotara.

• Arquitecturas a prueba de balas: me pasé horas y horas leyendo los repositorios de mis compañeros con más experiencia. Descubrí cómo aplicaban patrones de diseño para construir sistemas modulares que no se caían a pedazos cada vez que el cliente pedía un requerimiento nuevo. Cosas que en mi burbuja de freelance habría tardado una década en deducir.

Esa experiencia, esas horas leyendo código ajeno y entendiendo arquitecturas complejas, fue la que, tiempo más tarde, me permitió enfrentarme a la bestialidad técnica que es trabajar en proyectos para Airbus y sentirme cómodo con ello.

Entrar a repositorios gigantescos con estándares estrictos ya no me daba miedo, porque me habían enseñado la habilidad más importante de todas: a leer, entender y respetar el código a nivel profesional.

El retorno al mundo freelance (esta vez, de verdad)

Y es exactamente esa madurez técnica la que me permitió en 2025 volver a ser 100% freelance, pero esta vez por la puerta grande.

Ser freelance ahora no tiene absolutamente nada que ver con la ruleta rusa que era mi vida en 2018.

En mis inicios, mi supuesta libertad y el valor que aportaba a un cliente era una ilusión.

Hoy, cuando un cliente me contrata, no le vendo líneas de código: le vendo ingeniería y tranquilidad.

• Duermo tranquilo: monto los proyectos con una arquitectura sólida desde el primer commit. Configuro mis propios pipelines (CI/CD) y puedo hacer un despliegue a producción un viernes desde una cafetería en Viena sin que me suden las manos.

• Mantengo sin sufrir: si tengo que retomar el proyecto de un cliente seis meses después, mi código está estructurado y limpio. Ya no me dan ganas de llorar al leer mis propios archivos.

• Hablo de tú a tú con los grandes: haber pasado por una empresa y haber tocado código de gigantes como Airbus me dio el criterio para saber decir no a malas decisiones de producto y poder justificarlo. Ahora hablo el mismo idioma que los Tech Leads de mis clientes.

• Tarifas de Senior: ya no cobro por hacer una web, cobro por diseñar soluciones escalables que no van a dejar tirado al cliente cuando su negocio crezca. Y eso se paga (y se valora) muchísimo mejor.

Por eso hoy puedo viajar por Europa y escribirte desde Faro con una paz mental absoluta.

Esa libertad idílica que buscaba en 2018 no me la dio el hacerme autónomo. Me la dio haber aprendido en una empresa.

Deja un comentario

Compartir

La moraleja de mi historia

No me malinterpretes. La vida que tengo hoy, viajando y eligiendo mis proyectos como freelance no está mal.

No es lo idílico que muchos piensan, pero eso da para otra entrega de la newsletter.

Si quieres ser freelance, no te quiero desanimar.

Simplemente advertirte que si quieres ser un desarrollador sólido, es un estilo de vida que debes desbloquear después de haber pasado por las trincheras de trabajar en una (o varias) empresas).

Ser freelance no es algo que te aconseje para los inicios de tu carrera profesional.

¿Puedes hacerlo? Claro, pero te vas a perder un crecimiento profesional bastante grande.

Nos vemos en la próxima entrega.

Julián

Así está siendo el desarrollo de KPIAds.app.

Por suerte o por desgracia, estoy hasta arriba de trabajo y no le estoy pudiendo dedicar el tiempo que me gustaría al desarrollo de mi side project.. pero tampoco lo abandono.

Si sigues las entregas sobre el desarrollo de KPIAds, sabrás (o te intuirás) que estamos acabando la fase de diseño de todo el sistema.

Aunque está siendo bastante lento, es crucial para que luego el desarrollo vaya fluido y las cosas estén claras.

Que no nos toque improvisar en temas tan importantes como la arquitectura de nuestro futuro SaaS.

También sabrás, si leíste la última entrega sobre KPIAds, que en esta última entrega dimos un paso gigante en el diseño de KPIAds: decidimos sacar la lógica de negocio de los controladores y encapsularla en Actions.

Dejamos bien claro cómo sería el flujo de nuestro SaaS , un flujo bien precioso donde todo gira entorno a Route → Controller → Action → View.

Cada pieza tiene una única responsabilidad. Todo parece perfecto.

Pero hay una trampa mortal en la fase de diseño en la que es muy fácil caer. Una trampa que dejará tu código muy limpio, pero que destrozará la experiencia de tu usuario.

Déjame plantearte este escenario.

¿Qué pasa cuando un usuario crea un nuevo proyecto en la plataforma?

1. Guardamos el proyecto en la base de datos.

2. Generamos las métricas por defecto.

3. Le enviamos un email de bienvenida.

4. Notificamos al administrador por Slack.

Si en nuestro diseño metemos todo esto de forma secuencial dentro de la caja del Action CreateProjectAction… ¿sabes qué va a pasar cuando programemos esto?

Que el usuario hará clic en “Crear”, y se quedará mirando la pantalla de carga durante 4 o 5 segundos mientras el servidor espera a que las APIs de correo y Slack respondan.

Sí, acabamos de diseñar un cuello de botella.

El problema del acoplamiento oculto

Cuando diseñas una Action para que haga su trabajo principal (crear el proyecto) pero además le otorgas la responsabilidad de disparar efectos secundarios (emails, notificaciones, sincronizaciones), estás violando el principio de responsabilidad única por la puerta de atrás.

La solución para diseñar un sistema que escale, sin que los tiempos de respuesta se disparen, se llama Arquitectura Orientada a Eventos o Event-Driven Architecture.

En lugar de que la Action se encargue de todo, su única responsabilidad será hacer su trabajo principal y comunicar al resto que lo ha hecho.

Estos son los 3 pilares de comunicación interna que he dejado definidos en el documento de arquitectura de KPIAds:

1. Domain Events

Un Evento de Dominio no es una acción, es un hecho. Describe algo que ya ha pasado en el sistema.

En nuestro diseño, por ejemplo, hemos definido el evento ProjectCreated.

A partir de ahora, la Action guarda el proyecto y simplemente “dispara” este evento.

Inmediatamente después, devuelve la respuesta al usuario.

Tiempo de espera diseñado: 0.1 segundos, de esta forma el usuario no espera por procesos de terceros.

2. Listeners y Jobs

Pero claro, el email hay que enviarlo… ¿Quién lo diseña?

Para esto tendremos que definir Listeners (oyentes).

Se tratan de cajas en nuestra arquitectura que están escuchando por si alguien grita ProjectCreated.

Es decir, es un trozo de nuestro sistema que está todo el rato pendiente de que alguna otra parte del sistema comunique que ha creado el proyecto (Domain Event).

Pero como enviar un email bloquea el sistema, el Listener no lo envía directamente.

Su única función es empaquetar esa tarea en un Job y tirarlo a una cola de trabajo para que se procese luego.

3. Colas con Redis + Horizon (La infraestructura asíncrona)

Esos Jobs no se ejecutarán en el mismo proceso que atiende al usuario.

Para KPIAds, la decisión de diseño es usar Redis (una base de datos en memoria ultrarrápida) para gestionar estas colas.

Por detrás, habrá Workers (procesos en segundo plano) cogiendo esos trabajos uno a uno.

Y para gobernar todo esto sin ir a ciegas, la pieza clave de monitorización que hemos elegido es Laravel Horizon.

Diagrama y Contratos de Diseño

Como aún no hemos escrito una sola línea de código en el IDE, así es como se ve este flujo en nuestros documentos de diseño. Fíjate en la diferencia entre el tiempo que espera el usuario y lo que pasa por detrás:

Y para que las distintas capas se comuniquen sin acoplarse, en lugar de código PHP, lo que definimos en esta fase son los contratos: qué información viaja en cada paso para que los servicios sean independientes.

[ Acción ] -> CreateProjectAction
Responsabilidad: Escribir en BBDD y emitir evento.

[ Evento de Dominio ] -> ProjectCreated
Payload requerido:
  - project_id (UUID)
  - user_id (UUID)
  - timestamp_creacion

[ Listener ] -> SetupProjectDefaults
Responsabilidad: Escuchar 'ProjectCreated' y despachar Jobs.
Acciones:
  - dispatch(GenerateMetricsJob, payload: project_id)
  - dispatch(SendWelcomeEmailJob, payload: user_id)

Compartir

Deja un comentario

Y bueno, hasta aquí la entrega de hoy del desarrollo de mi SaaS para controlar el gasto y rendimiento publicitario.

Quiero que tengas claro con esta entrega en una (de muchas) diferencias entre un programador Junior y uno Senior.

Un perfil Junior se pone a escribir código y mete el envío del email en el controlador para ver si funciona.

Un perfil Senior se sienta primero con un papel, dibuja las cajas y se asegura de que el envío del email no hunda el rendimiento de la aplicación entera.

Diseñar el sistema con Eventos y Colas desde el principio marca la diferencia entre una aplicación frágil y un software preparado para miles de usuarios.

¿Te ha quedado clara esta separación de conceptos en la fase de diseño?

¿Quieres que la semana que viene pasemos ya a ver cómo se traduce esto a código real en el editor?

Nos vemos en la próxima entrega.

Julián

Si algo me he dado cuenta a lo largo de los últimos años trabajando en el mundo del desarrollo es de una verdad incómoda.

Y es que saber la sintaxis de un lenguaje o el último framework de moda no te hace Senior.

Lo que realmente te convierte en desarrollador Senior es tu criterio.

Cómo tomas decisiones.

Cómo gestionas tu tiempo.

Cómo te enfrentas a la frustración técnica y cómo entiendes que el código es solo una herramienta para resolver problemas.

Los desarrolladores que se estancan en la etapa Junior/Mid suelen ser los que se obsesionan solo con la tecnología y olvidan el contexto.

Por eso, hoy te traigo otros 10 consejos (o más bien, verdades) que separan a los que simplemente escriben código de los verdaderos profesionales del software.

1. No aprendes solo empezando proyectos, aprendes terminándolos.

Empezar es fácil. Terminar es lo que de verdad te forma.

Es cuando aparecen los problemas reales: decisiones incómodas, bugs, recortes, simplificaciones…

Ahí es donde empiezas a desarrollar criterio. Algo que ningún tutorial puede darte.

2. Automatiza lo aburrido.

Si haces algo más de dos o tres veces, probablemente deberías automatizarlo.

Cada minuto que ahorras en tareas repetitivas es tiempo que puedes dedicar a pensar mejor.

Y tu valor no está en escribir código rápido, sino en pensar bien.

Aquí la IA es una gran aliada.

3. La organización personal también es una skill técnica.

Esto se subestima muchísimo.

Cuando no tienes claro qué hacer, en qué orden o por qué… tu código lo refleja.

Ordenar tus tareas, tu entorno y tu cabeza es parte de programar mejor.

4. La humildad técnica te hace avanzar más que el ego.

No creces demostrando lo que sabes.

Creces estando abierto a lo que no sabes.

Escuchar en una code review, aceptar feedback o cambiar de opinión es incómodo…
pero es lo que te hace avanzar.

5. No midas tu progreso por horas, mídelo por claridad.

Puedes estar 8 horas delante del ordenador sin avanzar nada.

Y otros días, en una sola idea, avanzar muchísimo.

Muchas veces, progresar es entender qué NO hay que hacer.

6. No te sobrecargues de tutoriales. Aprende menos, aplica más.

Consumir contenido da sensación de progreso.

Pero si no aplicas, no sirve de nada.

Lo que construyes, lo que rompes y lo que arreglas… eso es lo que se queda.

7. Los logs son tu mejor aliado.

Esto parece básico, pero marca una diferencia enorme.

Antes de tocar código sin rumbo, mira qué está pasando realmente.

Aprender a leer logs con calma te ahorra horas (y frustración).

8. Tu portafolio no son tus proyectos, es tu criterio.

En una entrevista técnica no importa cuántos repositorios tengas en GitHub, sino cómo piensas en ellos. Las decisiones que tomaste, lo que priorizaste y lo que decidiste descartar es lo que realmente demuestra tu nivel al que te está evaluando (y lo que deberías aprender a documentar y vender, mírate las entregas de KPIAds y cómo estamos documentando todo).

9. La IA no te sustituye, te expone.

Si solo sabes escribir código de forma mecánica, la IA te puede reemplazar.

Pero si sabes pensar, decidir y entender el problema… la IA te multiplica.

La diferencia está ahí.

10. Refactorizar no es perder el tiempo, es invertir en tu futuro yo.

El código que no limpias hoy, te lo encontrarás mañana… pero peor.

Más bugs, más deuda técnica y más frustración.

Refactorizar no es perder el tiempo. Es invertirlo.

Deja un comentario

Suscríbete ahora

Para acabar, te voy a dejar otro consejo extra:

No intentes aplicar estas 10 cosas de golpe mañana por la mañana. Eso es receta segura para agobiarse y no hacer nada.

Elige solo una y aplícalo.

Si esta semana te centras simplemente en aprender a leer mejor los logs antes de tocar código, o en por fin terminar y desplegar ese side project que tienes a medias desde octubre, ya habrás dado un salto enorme en tu carrera.

La experiencia no se gana calentando la silla durante años, se gana acumulando buenas decisiones y aprendiendo de las malas.

Me encantaría saber cuál de estos 10 consejos te ha resonado más o cuál te cuesta más aplicar en tu día a día.

Nos vemos la semana que viene.

Julián

Creía que en Twitter, donde más activo estoy, era donde se concentraban los haters y los fanboys radicales de cualquier tecnología. Pero esta semana, LinkedIn me ha dado una bofetada de realidad.

Y no, no te escribo esto para contarte un salseo de redes sociales.

Te lo cuento porque detrás de esta pequeña polémica se esconde un error de mentalidad muy grave que diferencia a un Junior que se estanca de un Senior que avanza.

Déjame ponerte en contexto.

Llevo un tiempo cruzándome con publicaciones de LinkedIn (de desarrolladores y agencias de marketing) con un patrón recurrente.

Una táctica muy vieja y muy poco elegante: destrozar una tecnología para vender otra.

El argumento era el clásico “WordPress es inseguro, está lleno de plugins, cuesta escalar… y por eso nosotros usamos Next.js (o Astro, o cualquier otra cosa moderna)”.

Cansado de ver esto, decidí hacer una publicación en mi perfil. Algo con educación y datos técnicos.

No para justificar WordPress per se, sino para explicar que esa comparación era tramposa.

Les dije que estaban comparando un WordPress amateur hecho con plantillas de 50€ (o constructores visuales pesados) contra un desarrollo a medida en React idealizado.

(Por cierto: sí, en WordPress puedes desarrollar con React, bloques personalizados y bien optimizados, pero ese no es el tema de hoy).

¿Sabes qué respuesta obtuve?

Lejos de aceptar el debate técnico, me acusaron de ser terco, de parecer una secta y siguieron repitiendo sus dogmas sin leer mis argumentos.

Lo peor de todo es que yo no estaba defendiendo WordPress y que no solo trabajo con WordPress como freelance (también lo hago con React, Prestashop, Shopify, Laravel…).

Estaba defendiendo que cada tecnología tiene su contexto y que no hay herramientas buenas o malas, solo herramientas adecuadas o inadecuadas.

Y aquí es donde quiero aprovechar esta polémica para darte tres consejos que diferencian a un Junior enfadado de un Senior pragmático.

No uses la crítica de A para justificar B

Si tu único argumento para vender una tecnología (sea Next.js, Astro, Go o Wordpress) es decir que la otra es una mierda, tienes un problema de argumentación.

Cada tecnología tiene su propósito.

• WordPress mueve el 43% de la web porque democratizó la publicación de contenido. Bien usado, es robusto y permite que equipos de marketing vuelen solos.

• Next.js es una maravilla para aplicaciones complejas, interactividad y estado global.

• Laravel es el rey de la productividad en backend.

Un buen ingeniero no dice WordPress no sirve.

Un buen ingeniero dice: para este proyecto en concreto, donde necesitamos renderizado dinámico masivo y escalabilidad horizontal, WordPress no es la herramienta adecuada. Usemos Next.js por X, Y y Z ventajas.

Vende por las virtudes de tu solución, no por los defectos (reales o inventados) de la competencia.

Las herramientas no son una religión

Uno de los errores más graves que puedes cometer en tu carrera es casarte con una tecnología.

Cuando empiezas, es normal sentir pasión por el lenguaje que estás aprendiendo.

Si aprendes React, todo lo que no sea React te parece obsoleto.

Si aprendes PHP, todo lo moderno te parece humo.

Pero un Senior sabe que no existen las balas de plata.

Criticar una tecnología llamándola “ineficiente” porque tú prefieres otra, te cierra puertas y demuestra falta de visión.

Conoce los Trade-offs (Pros y Contras)

El mercado no te paga por defender un framework a capa y espada. El mercado te paga por tener el criterio técnico para elegir la herramienta más eficiente para cada problema.

Un buen arquitecto de software no dice que una tecnología es una mierda.... un buen arquitecto analiza el contexto:

¿El cliente necesita un blog autogestionable y el equipo de marketing quiere editarlo todo sin llamarte?

Aquí WordPress es una bestia imbatible. Montar esto en Next.js desde cero es reinventar la rueda y crearle una deuda técnica al cliente que no necesita.

¿Necesitas una aplicación web compleja, con estado global, mucha interactividad y sensación de App nativa?

Aquí Next.js o Laravel con Inertia son la mejor opción. Intentar forzar esto en un WordPress con 50 plugins es un suicidio.

¿Es un sitio puramente estático de contenido?

Aquí Astro brilla por su rendimiento.

Compartir

Suscríbete ahora

Para cerrar la entrega de hoy, algo curioso de este debate fue la nula capacidad de la otra parte para leer mis argumentos técnicos.

Cuando les hablé de problemas reales de ingeniería en JS (como el dependency hell), su cerebro filtró esa información y solo respondió con ataques personales.

Y esto es peligroso.

En nuestra profesión, la comprensión lectora es vital. Si no eres capaz de leer la documentación de una librería, o el comentario de un compañero en una Code Review sin sesgos y con atención, vas a cometer errores muy caros.

Sé agnóstico.

Aprende de todo.

Usa de todo.

Y critica con datos y contexto, nunca con dogma.

Nos vemos la próxima semana.

Julián