Práctica 01Timeboxing y la regla 15 / 30 / 60.
Asignar bloques fijos de tiempo a una actividad, y usar la regla 15/30/60 para decidir cuándo cambiar de modo: investigar, escribir, pedir ayuda.
Qué es
El timeboxing es una técnica formal de gestión del tiempo popularizada por James Martin en Rapid Application Development(1991). Consiste en asignar un bloque fijo de tiempo a una actividad. La regla 15/30/60 aplicada a “pedir ayuda” es una convención de la industria documentada en guías de onboarding de empresas como GitLab y Stack Overflow.
Cómo se aplica
- 15 minutos atascada: releer el error, buscar en documentación oficial, googlear el mensaje exacto.
- 30 minutos: escribir el problema en un canal o doc personal (rubber duck escrito).
- 60 minutos: pedir ayuda formal a un compañero o mentor, usando el formato del punto 2.
- Minuto 0: empieza la tarea, lee la documentación de la librería.
- Minuto 12: el componente no renderiza, ve un error de hooks en consola.
- Minuto 15: copia el error literal en Google. Revisa issues del repo.
- Minuto 30: no encontró nada. Abre un doc personal y escribe el problema con formato (ver práctica 02).
- Minuto 35:mientras escribe el “ya probé”, se da cuenta de que tiene dos versiones de React instaladas. Problema resuelto sola.
Si no se hubiera resuelto, el doc ya está listo para pegarlo en Slack al mentor al minuto 60.
- ¿Estoy mirando el reloj o llevo perdida la noción del tiempo?
- ¿Cuándo fue la última vez que cambié de approach? Si fue hace mucho, ¿por qué sigo con este?
- Si tuviera que explicar ahora qué probé, ¿podría hacerlo de forma ordenada?
- ¿Estoy probando cosas o estoy investigando? Probar al azar no cuenta como avance.
Práctica 02Formato estructurado para pedir ayuda.
Convertir un “no me anda” en un pedido que la otra persona puede responder. Cuatro líneas alcanzan.
Qué es
Convención conocida como “How to ask a good question”, la guía oficial de Stack Overflow desde 2010. Está relacionada con el concepto XY Problem: cuando alguien pregunta cómo hacer Y (su intento de solución) en vez de preguntar cómo resolver X (el problema real).
Estructura recomendada
# Cuatro bloques, en este orden: 1. Qué estoy intentando hacer // objetivo de negocio o técnico 2. Qué esperaba que pasara 3. Qué pasa en realidad // con error literal, no parafraseado 4. Qué ya probé // y qué resultado dio cada intento
Comparativa
“Hola, no me anda el login. ¿Me podés ayudar?”
Genera 4 idas y vueltas antes de empezar a resolver. Obliga a la otra persona a hacer la investigación inicial.
Objetivo:que al hacer click en “Sign in with Google” se abra el popup de OAuth y, después del consent, se redirija al dashboard.
Esperaba: que el callback de NextAuth devuelva el session token.
Pasa en realidad: el popup abre, hago login, pero al volver la URL queda en /api/auth/error?error=OAuthCallback y la consola tira [next-auth] state cookie was missing.
Ya probé:
- Revisar env vars (ID y SECRET están bien).
- Borrar cookies y reintentar.
- Cambiar
cookies.stateasameSite: 'lax'. - Probar en incógnito.
Sospecho que es por el dominio del callback en Google Cloud.
El segundo formato suele recibir respuesta en 5 minutos. El primero genera 4 idas y vueltas antes de empezar a resolver.
- ¿Estoy preguntando por mi intento de solución (Y) o por el problema real (X)?
- ¿La persona que lee esto puede reproducir mi problema con lo que escribí?
- ¿Incluí el error literal o lo parafraseé?
- ¿Mi pedido demuestra que ya hice mi parte, o suena a "resuélvemelo"?
Práctica 03Rubber Duck Debugging.
Explicarle el problema, paso a paso, a un objeto inanimado o a un texto escrito. Verbalizar fuerza al cerebro a estructurar el pensamiento.
Qué es
Técnica formal documentada en The Pragmatic Programmer (Andy Hunt, Dave Thomas, 1999). El acto de verbalizar fuerza al cerebro a estructurar el pensamiento, y muchas veces la solución aparece sola.
Está debuggeando por qué un useEffect se ejecuta en loop.
Sin rubber duck: prueba cosas al azar. Saca dependencies, agrega un ref, comenta líneas.
Con rubber duck, escribe en un doc:
“Tengo este useEffect que hace un fetch cuando cambia userId. Las dependencies son [userId, setData]. Espero que se ejecute solo cuando cambia el usuario. Pero veo que se ejecuta en loop infinito.
Si pienso bien: setData viene del padre como prop. El padre lo redeclara en cada render. Entonces setDataes una referencia distinta en cada render. Entonces el effect detecta cambio y se vuelve a ejecutar.”
Ahí encontró el bug sin pedirle nada a nadie. La sola acción de escribirlo le obligó a seguir la lógica completa.
- ¿Puedo explicar este problema en voz alta sin usar muletillas tipo "es que… no sé… algo raro"?
- ¿Entiendo lo que está haciendo cada línea, o asumo que "hace lo que tiene que hacer"?
- Si tuviera que enseñarle esto a alguien que recién empieza, ¿en qué paso me trabaría?
Práctica 04Spike y Design Doc liviano.
Pensar antes de codear. Quince minutos de plan ahorran medio día de refactor.
Qué es
Dos prácticas formales que apuntan a “pensar antes de codear”.
- Spike: término oficial de Extreme Programming, introducido por Kent Beck. Tarea acotada en tiempo para investigar una solución antes de comprometerse a implementarla. El output es un documento corto, no código de producción.
- Design Doc / RFC: convención usada por Google, Amazon y Stripe. Versión liviana para tareas chicas: un comentario en el ticket antes de empezar.
Estructura del mini-plan
# Tres bullets antes de abrir el editor › Archivos que voy a tocar › Approach en 2-3 bullets › Riesgos o dudas que tengo
Comparativa
Abre el componente de la lista, agrega un useState. Después se da cuenta de que el filtro tiene que vivir más arriba en el árbol y refactoriza.
Llega un PM y dice que el filtro tiene que persistir en la URL. Refactoriza otra vez.
Total: 2 días.
Archivos a tocar:
app/products/page.tsxcomponents/ProductFilters.tsx(nuevo)lib/products.ts
Approach: filtro como query param (?category=shoes) compartible y persistente; componente controlado con useSearchParams; la API ya acepta category.
Riesgos: validar SSR con query, confirmar si es una o varias categorías a la vez.
Total: medio día.
El mentor lee el plan en 5 minutos y confirma el approach. La junior arranca con dirección clara.
- ¿Tengo claro qué archivos voy a tocar antes de abrir el editor?
- ¿Pensé al menos dos formas posibles de resolver esto, o agarré la primera que se me ocurrió?
- ¿Hay algo que estoy asumiendo que debería confirmar antes con el mentor, producto o diseño?
- Si tuviera que estimar esto ahora, ¿en cuánto lo termino? ¿Y si lo estimo después de hacer el plan?
Práctica 05Estimación previa vs tiempo real.
No hace falta acertar al inicio. La meta es que la diferencia entre estimado y real se achique con el tiempo.
Qué es
Práctica estándar de metodologías ágiles. La forma más conocida es Planning Poker (Mike Cohn, Agile Estimating and Planning, 2005), pero para mentoría 1 a 1 alcanza con una estimación simple en horas.
Concepto clave: la falacia de planificación (Kahneman y Tversky, 1979) explica por qué los humanos subestimamos sistemáticamente cuánto va a llevar una tarea.
Planilla de seguimiento
Después de un mes, la planilla muestra patrones: “siempre me olvido del testing”, “los bugfixes los sobreestimo”, “las migraciones me cuestan el triple”.
- ¿Mi estimación incluye testing, code review y posibles cambios pedidos en review?
- En las últimas 5 tareas, ¿mi estimación fue corta, larga o variada? ¿Hay un patrón?
- ¿Estoy estimando "el código feliz" o "el código real con problemas"?
- Cuando me paso del estimado, ¿cuál fue la causa más común?
Práctica 06Stand-up asincrónico.
Tres preguntas, cinco minutos al día. El mensaje hace visibles los loops y los bloqueos sin que el mentor tenga que preguntar.
Qué es
Ceremonia formal de Scrum, en su variante async stand-up popularizada por GitLab y empresas remote-first. Tres preguntas clásicas: qué hice ayer, qué voy a hacer hoy, dónde estoy trabada.
Ayer:
- Terminé el filtro de categoría (PR #234, listo para review).
- Empecé la integración con Stripe, hice el setup del SDK.
Hoy:
- Seguir con Stripe: implementar el checkout session.
- Revisar el PR de Mariano si tengo tiempo.
Bloqueos:
- Necesito las credenciales de Stripe de staging. ¿Quién las tiene?
- Si falla el pago, ¿redirigimos o mostramos modal? @producto
Beneficios concretos
- Si “Stripe” aparece 5 días seguidos, el mentor ve el loop sin tener que preguntar.
- Los bloqueos quedan visibles para todo el equipo, no solo para el mentor.
- Entrena la comunicación escrita, que es la habilidad más subvalorada en dev.
- ¿Lo que escribí ayer y hoy muestran avance, o estoy con lo mismo hace varios días?
- ¿Estoy reportando bloqueos reales, o solo "estoy haciendo X"? Si nunca tengo bloqueos, probablemente no los estoy viendo.
- Si alguien externo lee mi update, ¿entiende qué hago y en qué estado está?
Práctica 07Pair programming dirigido.
Dos personas, una computadora. La junior es siempre Driver. El mentor pregunta, no resuelve.
Qué es
Práctica formal de Extreme Programming (Kent Beck). Para mentoría, la variante más útil es Driver / Navigator con roles fijos.
- Driver: escribe el código. Acá va siempre la junior.
- Navigator: guía, pregunta, sugiere, pero no toca el teclado.
Esto fuerza a la junior a verbalizar lo que hace y al mentor a no resolverle el problema, cosa que tiende a pasar cuando toma el control del teclado “para ir más rápido”.
Comparativa
Junior:“No me funciona el fetch.”
Mentor:“A ver, dame el teclado.” Tipea 10 minutos, lo arregla. “Listo, era el header de auth.”
Resultado: la junior no aprendió nada. Mañana se va a trabar con lo mismo.
Junior:“No me funciona el fetch.”
Mentor:“Mostrame el network tab. ¿Qué status code está devolviendo?”
Junior:“401.”
Mentor:“¿Qué significa 401?”
Junior:“No autorizado.”
Mentor:“¿Qué headers manda el request?”
Junior:“Ah… no estoy mandando el token de auth.”
Resultado: resolvió el problema con guía. La próxima vez mira el network tab antes de pedir ayuda.
- ¿Qué hice yo y qué hizo el mentor? Si el mentor tipeó más que yo, algo falló.
- ¿Hubo algún momento en el que entendí algo nuevo? ¿Puedo explicarlo ahora?
- Si mañana me toca un problema parecido, ¿lo podría resolver sola?
MediciónCómo medir el progreso.
Para que no sea solo sensación. Métricas simples primero, DORA cuando haya más rodaje.
Cycle time por tarea
Desde “in progress” hasta “done” en el sistema de tickets (Jira, Linear). Si baja con el tiempo, hay mejora en planificación y desbloqueo.
Ratio estimado vs real
La planilla de la práctica 05. La meta no es que el gap sea cero, sino que se achique mes a mes.
Tiempo hasta el primer pedido
Cuando se traba, cuánto tarda en escribir el pedido. Track informal. Meta: 30 a 60 minutos.
Calidad del pedido
Checklist al pedir ayuda:
- Incluye objetivo
- Incluye error literal
- Incluye intentos previos
- Incluye contexto reproducible
PRs con plan vs sin plan
Los PRs que arrancaron con mini-plan suelen tener menos rondas de review. Buena proxy de calidad de planificación.
DORA Metrics
Lead time, deployment frequency, MTTR, change failure rate. De equipo, no individuales, pero buen marco para más adelante.
RitualReflexión semanal.
Diez minutos cada viernes, seis preguntas. No responder en la cabeza: escribir las respuestas, aunque sean cortas.
Las seis preguntas.
Tocá cada pregunta para marcarla cuando la respondiste esta semana. Se guarda en tu navegador.
- Pregunta 01¿Qué tarea me llevó más de lo que esperaba esta semana? ¿Por qué?
- Pregunta 02¿Cuántas veces pedí ayuda? ¿Esperé demasiado o muy poco en alguna?
- Pregunta 03¿Qué aprendí esta semana que no sabía el lunes? Si es "nada", revisar.
- Pregunta 04¿Hay algo que estoy evitando porque no lo entiendo? Ser honesta acá es clave.
- Pregunta 05¿Hubo algún momento en el que estuve en loop más de una hora sin avanzar? ¿Qué hubiera hecho distinto?
- Pregunta 06¿Mi mentor sabe en qué estoy trabajando y dónde estoy trabada, o tendría que preguntármelo?
AnexoRecursos recomendados.
Libros y referencias con nombre propio que cubren estos temas. Lectura opcional, no requisito.
Blindar el espacio para pedir ayuda.
Si la primera vez que aplica la regla de los 30 minutos el mentor responde con tono apurado o le hace sentir que “eso era fácil”, el sistema se rompe.
Las primeras semanas el costo lo paga el mentor: responder rápido, validar el formato del pedido, y recién después exigir más autonomía en el diagnóstico.