Hilos que empezaron como tweets y terminaron siendo ensayos.

Dejé de usar React Query en mi último proyecto después de 3 años usándolo a diario. No porque sea mala librería. Es excelente. Pero el equipo se estaba complicando por razones que nada tienen que ver con el fetching de datos. Te explico qué pasó 🧵

El problema: React Query te resuelve el fetching + caching + sincronización. Pero en apps con mucho estado derivado, acabas con una mezcla de useQuery + useReducer + useMemo que es difícil de razonar. No es culpa de RQ. Es que el patrón no escalaba.

¿Cuándo usarlo sin dudar? • APIs REST con muchos endpoints • Datos que cambian con frecuencia • Equipos que recién arrancan con React • SSR que necesita cache compartida Ahí React Query brilla. Es la mejor herramienta para ese job.

¿Cuándo reconsiderar? • Estado local complejo que no viene del server • Mucha lógica de derivación (no de fetching)• GraphQL (mejor usar Apollo/urql que ya cachean) • Apps pequeñas donde el overhead de RQ no se justifica

En mi caso, migré a SWR + Zustand. SWR para lo simple (fetching GET), Zustand para el estado de UI. El bundle bajó 40KB. El código es más legible. El equipo lo entiende más rápido. No es mejor ni peor. Es lo que funcionó para este proyecto.

Moraleja: la mejor arquitectura no es la que más features tiene. Es la que tu equipo puede mantener el lunes a las 9am cuando algo se rompe. Eso es engineering real.

7 trucos de TypeScript que ojalá conocieras antes (probablemente llevas años programando sin ellos) Te van a ahorrar horas de debugging 🧵

1️⃣ `satisfies` operator const config = { api: '/api', timeout: 5000 } as const satisfies Config TypeScript verifica que tu objeto cumple el tipo PERO preserva los literales. Antes tenías que elegir entre `as Config` (perdías info) o nada (sin validación). Ahora tienes ambas.

2️⃣ Type predicates para guards reutilizables function isError(x: unknown): x is Error { return x instanceof Error } El `x is Error` le dice al compilador que dentro del if, x es Error. Sin casts manuales. Sin `any`. Puro type safety.

3️⃣ Utility type: Omit por valor, no por key type StringKeys<T> = { [K in keyof T as T[K] extends string ? K : never]: T[K] } Extrae solo las keys cuyos valores son strings. Útil para formularios dinámicos.

4️⃣ `const` type parameters function first<T const>(arr: readonly T[]): T | undefined { return arr[0] } El `const` previene que TypeScript ensanche el tipo. Si pasas `['a', 'b']`, T es `'a' | 'b'`, no `string`.

5️⃣ Discriminated unions con `never` type Result = | { status: 'ok'; data: string } | { status: 'error'; error: Error } | { status: 'loading' } En un switch con exhaustive check, TypeScript te avisa si olvidaste un caso. Tu código es literalmente imposible de romper.

6️⃣ Template literal types type Endpoint = `/${string}` function fetch<T>(url: Endpoint): Promise<T> TypeScript valida que el string empiece con /. Tiny pero poderoso.

7️⃣ `in` operator como type guard function hasProp<K extends string>(x: object, k: K): x is Record<K, unknown> { return k in x } Type narrowing dinámico. Útil con APIs que devuelven objetos con props opcionales.

Bonus: si usas TypeScript todos los días y no conocías `satisfies`, estás escribiendo código 30% más frágil de lo necesario. La diferencia entre un senior TS y uno mid no es que sepa más cosas. Es que usa las herramientas correctas para el contexto correcto.

Docker sin miedo: del caos al deploy en 7 tweets Sin tutoriales de 40 minutos. Sin teoría que no vas a usar. Solo lo que necesitas para empezar a correr tu app 🧵

1. ¿Qué es Docker realmente? Es una caja sellada con tu app + todo lo que necesita para funcionar. Tu app funciona en tu máquina? Funciona en producción. Fin del 'works on my machine'.

2. Los 3 comandos que necesitas docker build -t miapp . # construye la caja docker run -p 3000:3000 miapp # arranca la caja docker ps # ve qué cajas están corriendo Eso es el 80% de lo que vas a usar día a día.

3. El Dockerfile mínimo viable FROM node:20-slim WORKDIR /app COPY package*.json ./ RUN npm ci --production COPY . . CMD ["node", "server.js"] 7 líneas. Tu app empaquetada. No necesitas nada más para empezar.

4. Docker Compose para no volverte loco version: '3' services: web: build: . ports: ['3000:3000'] db: image: postgres:16 Un archivo. Dos servicios. `docker compose up` y todo funciona junto.

5. El truco del .dockerignore node_modules .git .env *.md Si no pones .dockerignore, Docker copia todo tu node_modules al contexto de build. Cada build tarda 30 segundos más. Pequeño cambio, gran impacto.

6. Multi-stage builds para imágenes pequeñas FROM node:20 AS build COPY . . RUN npm ci && npm run build FROM node:20-slim COPY --from=build /app/dist ./dist CMD ["node", "dist/server.js"] Tu imagen pasa de 1.2GB a 180MB. Mismo resultado.

7. La regla de oro No aprendas Docker memorizando comandos. Aprende Docker haciendo deploy de algo real. Toma cualquier app que tengas, hazle un Dockerfile, súbelo a Fly.io o Railway. La teoría se olvida. La práctica se queda.

Docker no es complicado. Es intimidante porque hay demasiado ruido alrededor. La realidad: necesitas ~7 conceptos y 5 comandos para el 90% de los casos. El resto lo aprendes cuando lo necesitas.

CSS que probablemente no conocías y deberías estar usando en 2026 Propiedades que eliminan librerías enteras de JavaScript 🧵

1️⃣ `:has()` — el selector del padre .card:has(img) { padding: 0; } Estiliza un elemento según sus hijos. Antes necesitabas JS. Ahora es CSS puro. Soporte global: 92%+. Úsalo.

2️⃣ `container queries` .card-container { container-type: inline-size; } @container (min-width: 400px) { .card { display: grid; } } Tus componentes responden a su contenedor, no al viewport. Responsive design de verdad.

3️⃣ `text-wrap: balance` h1 { text-wrap: balance; } Balancea el texto en múltiples líneas automáticamente. Tus titulares se ven como un diseñador los pensó. Sin JS.

4️⃣ CSS nesting nativo .card { padding: 1rem; & .title { font-size: 1.5rem; } &:hover { background: #f5f5f5; } } Adiós Sass. El nesting es nativo en todos los browsers modernos.

5️⃣ `subgrid` .grid { display: grid; grid-template-columns: 1fr 2fr; } .item { display: grid; grid-template-columns: subgrid; } Los hijos pueden heredar el grid del padre. Grids perfectos sin math.

6️⃣ `accent-color` input[type=checkbox] { accent-color: #3E45EB; } Colorea checkboxes, radios y range sliders nativos. Sin CSS hack. Sin librería.

7️⃣ `scroll-snap` .gallery { scroll-snap-type: x mandatory; } .item { scroll-snap-align: start; } Carruseles con scroll snap nativo. Sin JS. Sin librería. Touch-friendly por defecto.

El CSS de 2026 hace cosas que en 2020 requerían React, una librería de animación y 200 líneas de JS. Si sigues usando jQuery o JS para cosas que CSS ya resuelve, estás escribiendo código innecesario.

PostgreSQL vs MongoDB en 2026: la respuesta honesta (sin fanboyism) He usado ambos en producción. Esto es lo que aprendí 🧵

El mito: 'MongoDB es mejor para datos no estructurados' La realidad: PostgreSQL tiene JSONB desde hace 10 años. Puedes hacer queries GIN indexadas sobre JSON, validar schemas, y hacer joins con tablas relacionales. Postgres es mejor MongoDB que MongoDB.

¿Cuándo MongoDB tiene sentido REAL? • Eventos con schema que cambia constantemente • IoT con millones de writes/segundo • Documentos jerárquicos muy profundos (>3 niveles de nesting) • Cuando tu equipo ya lo conoce bien Fuera de eso, Postgres probablemente es mejor opción.

Cosas que PostgreSQL hace mejor de lo que la gente cree: ✅ JSON (JSONB + GIN indexes) ✅ Full-text search (mejor que Mongo) ✅ Arrays y operaciones nativas ✅ Geospatial (PostGIS es bestial) ✅ Pub/Sub (LISTEN/NOTIFY) ✅ Time series (con TimescaleDB)

Cosas que MongoDB hace mejor: ✅ Horizontal scaling (sharding es más simple) ✅ Schema flexibility real (sin migrations) ✅ Aggregation pipeline (más expresivo que SQL a veces) ✅ Replica sets más fáciles de configurar No es que Mongo sea malo. Es que la mayoría de apps no necesitan lo que Mongo ofrece.

Mi framework de decisión: 1. ¿Necesitas joins complejos? → Postgres 2. ¿Tienes schema estable? → Postgres 3. ¿Tu equipo conoce SQL? → Postgres 4. ¿Necesitas escalar a petabytes horizontalmente? → Considera Mongo 5. ¿No estás seguro? → Postgres El 80% de las apps caen en 1-5.

Un dato que sorprende: el stack más popular en 2026 para startups no es Mongo+Node. Es Postgres+Prisma+Next.js. La gente votó con sus repos. Y Postgres ganó.

Moraleja: no elijas tu base de datos por lo que leíste en un blog de 2015. El landscape cambió. PostgreSQL de 2026 es un motor diferente al de 2018. Si no lo has mirado últimamente, míralo.

Trabajo remoto vs presencial: lo que nadie te dice después de 3 años haciéndolo No es lo que lees en LinkedIn 🧵

Mito #1: 'El remoto es más productivo' La verdad: depende totalmente de ti. Si te distraes fácil, la oficina es mejor. Si tienes disciplina, el remoto te da horas que no sabías que tenías. No hay respuesta universal. Hay que ser honesto con uno mismo.

Mito #2: 'El remoto aísla' Parcialmente cierto. Pero la oficina también aísla de forma diferente: small talk obligatorio, reuniones innecesarias, interrupciones constantes. La conexión real requiere intención, sin importar dónde estés.

Lo que SÍ cambia con el remoto: ✅ Recuperas 1-3 horas de commute diarias ✅ Controlas tu ambiente (ruido, temperatura, comida) ✅ Puedes ver a tu familia al mediodía ❌ La línea trabajo/vida se difumina ❌ Tienes que sobrecomunicar todo ❌ El onboarding es más difícil

Lo que la gente no menciona: el remoto recompensa a los proactive y castiga a los que esperan instrucciones. En la oficina, alguien te dice qué hacer. En remoto, tienes que averiguarlo. Si no eres autónomo, vas a sufrir.

El mayor error que vi en equipos remotos: tratar de replicar la oficina online. Reuniones de 1 hora que pudieron ser un mensaje. Stand-ups diarios que pudieron ser async. Calendarios llenos que no dejan tiempo para pensar. El remoto no es la oficina en Zoom. Es otra cosa.

Si tuviera que dar un consejo a alguien empezando remoto: 1. Documenta todo (si no está escrito, no existe) 2. Sobrcomunica tu progreso 3. Crea rutinas de cierre de jornada 4. Sal de casa aunque sea 20 minutos 5. Invierte en tu setup (silla, monitor, audio) Lo simple funciona.

El trabajo remoto no es mejor ni peor que el presencial. Es diferente. Y como toda herramienta, funciona mejor cuando entiendes sus trade-offs y diseñas tu vida alrededor de ellos. No hay modelo perfecto. Hay el modelo que funciona para ti.

Migré 3 apps de Pages Router a App Router en Next.js. Esto es lo que aprendí (y los errores que cometí para que tú no los cometas) 🧵

Lección 1: No migres todo de golpe Migrar Pages → App Router no es un refactor. Es una re-arquitectura. Server Components, data fetching, caching, metadata. Todo cambia. Migra una página a la vez. Aprende. Luego la siguiente.

Lección 2: 'use client' es tu mejor amigo y peor enemigo Es fácil poner 'use client' en todo para que funcione. Pero eso mata el punto de Server Components. Meta: mínimo 70% de tus componentes deberían ser Server Components. Si tienes más de 30% client, algo estás haciendo mal.

Lección 3: El caching te va a sorprender App Router cachea agresivamente. fetch() se cachea por default. Las navigaciones se cachean. Esto es increíble para performance. Pero durante el desarrollo te va a confundir cuando los datos no se actualicen. export const dynamic = 'force-dynamic' es tu救救命稻草.

Lección 4: Layouts vs Templates Layouts persisten entre navegaciones (state se mantiene). Templates se re-renderizan en cada navegación (state se resetea). La mayoría usa Layouts siempre. Pero a veces quieres Templates para reset de estado.

Lección 5: Error boundaries son obligatorios En Pages Router, un error rompía la página. En App Router, un error en un Server Component puede romper toda la app. Agrega error.tsx en cada route segment. No es opcional.

Lección 6: Loading UI cambia la experiencia loading.tsx no es decorativo. Es funcional. Muestra un skeleton inmediatamente mientras el Server Component carga datos. La app se siente instantánea.

Lección 7: Metadata API es lo mejor del App Router Antes: next-seo + configuración manual. Ahora: export const metadata. Tipado. Autocompletado. SEO perfecto. Solo esto ya justifica la migración.

¿Vale la pena migrar? Si tu app funciona bien en Pages Router: NO migres ahora. Si estás empezando un proyecto nuevo: usa App Router. La migración es dolorosa. Empezar nuevo es natural. Next.js 15+ está optimizado para App Router.

El síndrome del impostor en tech es real. Y nadie habla de él abiertamente. Llevo años en esto y todavía me pasa. Esto es lo que aprendí a hacer al respecto 🧵

Primero: no es un 'síndrome'. Es la respuesta normal de un cerebro que aprende cosas nuevas. Si nunca te sientes impostor, probablemente no estás creciendo. El discomfort es señal de que estás en el borde de tu capacidad. Eso es bueno.

El problema no es sentirte impostor. El problema es paralizarte por ello. La diferencia entre un senior y un junior no es que el senior no dude. Es que el senior duda y hace el deploy igual.

Cosas que me ayudaron: 1. Documentar lo que sé (escribir me obliga a estructurar) 2. Enseñar lo que aprendo (si puedes explicarlo, lo sabes) 3. Trackear logros concretos (no confíes en tu memoria emocional) 4. Hablar con otros devs (todos lo sienten, nadie lo dice)

La trampa del 'todo el mundo sabe más que yo': Ves a alguien hablar fluidamente de Kubernetes y piensas que sabe todo. La realidad: sabe Kubernetes. No sabe CSS. No sabe bases de datos. No sabe de lo que tú sabes. Comparas tu interior con el exterior de otros.

El secreto que nadie te dice: la mayoría de seniors googlean todo. No memorizan. Entienden patrones. La diferencia entre 'saber' y 'no saber' no es cuánto tienes en la cabeza. Es si puedes encontrar la respuesta rápido.

Si te sirve: mi checklist mental cuando siento que soy un fraude ✓ ¿Resolví un problema esta semana? ✓ ¿Alguien aprendió algo de mí? ✓ ¿Mi código está en producción? Si respondes sí a cualquiera, no eres fraude. Punto.

El síndrome del impostor no se cura. Se maneja. Y la forma de manejarlo no es con frases motivacionales. Es con evidencia acumulada de que sabes lo que haces. Construye cosas. Deploy. Repite. La confianza sigue a la acción.

Uso IA para programar todos los días desde hace 2 años. Esto es lo que realmente funciona (y lo que es puro marketing) 🧵

Lo que SÍ funciona: ✅ Autocompletado de código (Copilot/Cursor) ✅ Generar tests unitarios ✅ Explicar código legacy ✅ Debugging (pegar stack trace) ✅ Boilerplate y scaffolding Estos casos te ahorran horas reales. Medible.

Lo que NO funciona (todavía): ❌ Arquitectura de sistemas complejos ❌ Debugging de race conditions ❌ Optimización de performance ❌ Decisiones de diseño de API ❌ Cualquier cosa que requiera contexto del negocio La IA no sabe por qué tu código existe. Solo sabe cómo se ve.

El error más común: delegar demasiado. Si le pides a la IA que escriba un feature completo sin entender qué genera, vas a tener código que 'funciona' pero que no puedes mantener. La IA es un acelerador, no un reemplazo. Si no entiendes el output, no lo deploy.

Mi workflow actual con Cursor + Claude: 1. Escribo el esqueleto de la función (yo) 2. Le pido que complete los detalles (IA) 3. Reviso cada línea (yo) 4. Le pido tests (IA) 5. Corro y ajusto (yo) El loop humano-IA es donde está la productividad real. No el 'genera todo'.

Un dato: los developers que más productividad ganan con IA no son los juniors. Son los seniors. ¿Por qué? Porque saben qué pedir, cómo evaluar la respuesta, y dónde están los límites. La IA amplifica lo que ya sabes. No reemplaza lo que no sabes.

Lo que va a pasar en los próximos 2 años: • Juniors van a necesitar aprender fundamentals más rápido • El valor de 'saber arquitectura' va a subir • El valor de 'saber syntax' va a bajar • Code review humano se vuelve más importante, no menos Adáptate o quedate atrás.

La IA no va a reemplazar developers. Pero developers que usan IA van a reemplazar a los que no. La pregunta no es '¿debería usar IA?'. Es '¿estoy usando la IA de la forma correcta?'. Si aún no la integraste a tu workflow, estás perdiendo tiempo.

Mi side project falló después de 4 meses de trabajo. Esto es lo que aprendí (para que tu próximo proyecto no fracase igual) Hilo honesto 🧵

El proyecto: una app de gestión de gastos para freelancers. Tecnología impecable. Next.js + Prisma + Postgres. Diseño pulido. Deploy en Vercel. 0 usuarios después del lanzamiento. Cero. Nadie la quiso.

Error #1: Construí para mí mismo, no para el mercado Yo era el usuario. Yo tenía el problema. Pero asumí que otros lo tenían igual. Nunca validé con personas reales. Construí 4 meses sobre una suposición no confirmada.

Error #2: Perfeccionismo antes de lanzar Puse demasiado tiempo en animaciones, dark mode, integraciones que nadie pidió. Debí lanzar una versión fea pero funcional en 2 semanas. Obtener feedback. Iterar. El código perfecto que nadie usa no vale nada.

Error #3: No tener canal de distribución Construí la app. ¿Y luego qué? No tenía audiencia. No había hecho content. No tenía lista de espera. Construir sin audiencia es como abrir un restaurante en el desierto.

Error #4: No cobrar desde el día 1 La hice gratis para 'validar'. Nadie la usó gratis. ¿Por qué iban a pagar? Si tu producto es bueno, alguien paga desde el principio. Si nadie paga, no es tan bueno como crees.

Lo que aprendí para el próximo proyecto: 1. Validar ANTES de construir (landing + lista de espera) 2. Lanzar feo y rápido (2 semanas máximo) 3. Cobrar desde día 1 (validación real = tarjeta de crédito) 4. Construir audiencia mientras construyes producto 5. Iterar con feedback, no con suposiciones

No me arrepiento del fracaso. Aprendí más en esos 4 meses que en 2 años leyendo tutoriales. El fracaso es data. Y la data es lo que te hace mejor para el próximo intento. El mejor momento para empezar tu próximo proyecto es ahora.