Por qué armé este espacio

Podés llenar un CV con tecnologías. No dice nada sobre cómo llegaste a elegirlas.

Podés poner Next.js, TypeScript y Docker en todas las líneas que quieras. No le dice a nadie qué pasa cuando tenés que elegir entre la solución que funciona hoy y la que vas a poder mantener en seis meses, cuando una dependencia que instalaste sin pensarlo empieza a pudrirse en producción, o cuando el diseño que parecía limpio en papel se convierte en una trampa apenas crece el proyecto.

Esas decisiones son las que importan. Y rara vez aparecen en el código final.

Este blog existe para documentarlas. El Radar —el newsletter que te acompaña— también.

De dónde vengo

Estuve casi una década en gestión comercial antes de pasarme al desarrollo. No vine de un bootcamp de tres meses ni de una carrera universitaria clásica — vine de años entendiendo cómo las empresas convierten inversión en resultado, cómo los equipos toman decisiones bajo presión, y por qué los proyectos bien intencionados fracasan igual.

Cuando empecé a programar de verdad, esa historia cambió cómo veía el código. Nunca fue solo sintaxis. Siempre fue: ¿qué consecuencias tiene esta decisión para el producto, para el equipo, para el negocio?

Eso es lo que trato de transmitir acá.

Qué vas a encontrar

Tres ejes, sin relleno:

Performance — No "cinco tips para mejorar tu LCP". Sino qué decisión arquitectónica tomé en un producto real, qué métricas cambió, qué sacrifiqué en el proceso. En FerrelonStock, un sistema de inventario que construí con Django y React, pasamos de 4.2s a 1.8s de carga inicial. El cambio no fue heroico — fue code splitting, caching y eliminar una dependencia que nadie había cuestionado en dos años. Lo interesante no es el número. Es el proceso de encontrar el cuello de botella correcto.

Producto — La intersección entre ingeniería y criterio de negocio. Cuándo agregar complejidad tiene sentido y cuándo no. Por qué algunos sistemas bien escritos fracasan igual. Cómo diseñar algo que el equipo pueda mantener cuando el desarrollador original ya no está.

Automatización — La aplicada con criterio, no por tendencia. Cuándo automatizar acelera de verdad y cuándo agrega una capa de magia que nadie entiende seis meses después.

El Radar — el newsletter

Una vez por semana llega El Radar: un análisis breve de una decisión técnica real, un tradeoff que encontré en el camino, o algo del mundo del desarrollo que vale la pena pensar dos veces.

No es un resumen de noticias. No es un tutorial. Es una conversación — el tipo de cosa que compartirías con un colega tomando un café, si ese colega tuviera años de experiencia y ganas de ser honesto.

Cada edición termina con una pregunta abierta. Porque el objetivo no es que leas y cierres la pestaña — es algo de lo que escribo que te quede dando vueltas.

Suscribite abajo si querés recibirlo directo en tu casilla.

Para quién es esto

Para devs en transición que saben que aprender un framework no alcanza para construir productos sólidos. Para founders técnicos que toman decisiones de arquitectura bajo presión. Para equipos que están evaluando sumar alguien — acá podés ver cómo razono antes de escribir una sola línea de código.

No tengo diez años de commits en producción. Sí tengo casi una década viendo cómo las empresas convierten — o destruyen — valor con sus decisiones. Eso no se aprende en ningún bootcamp, y cambió completamente cómo aprendí a programar.

Si buscás tutoriales, hay mejores lugares. Si te interesa entender el razonamiento detrás del código — por qué algo se construye así, qué se sacrificó, qué consecuencias tiene — estás en el lugar correcto.

Una pregunta antes de cerrar

¿Cuándo fue la última vez que tomaste una decisión técnica que sabías que iba a ser difícil de explicar — y la tomaste igual porque era la correcta?

Eso es exactamente lo que quiero documentar acá. Me interesa mucho saber cómo la responderías vos.

Dejá tu respuesta en los comentarios o respondé el primer número de El Radar cuando llegue.