Cómo practicar sin engañarte

Este documento es el “cómo”, no el “qué”. El qué está en el laboratorio, Kontor y el currículo.

La rutina diaria

45–60 minutos

20 minutos

Si solo tienes 20 minutos, haz esto:

1. 5 min: repaso.

2. 10 min: un test.

3. 5 min: explicación en voz alta.

No intentes “avanzar” en 20 minutos. Intenta no romper la cadena.

La regla del test primero

Cada ejercicio empieza con un test que falla. No escribas la implementación antes de leer el test.

1. Lee el test.

2. Escribe la firma.

3. Devuelve el caso más simple.

4. Ejecuta.

5. Añade el siguiente caso.

6. Refactoriza.

Si no sabes por dónde empezar, escribe TODO() y haz que compile. Luego sustituye una parte.

La regla de los 20 minutos

Si llevas 20 minutos atascado:

1. Escribe en papel qué entra y qué sale.

2. Reduce el caso a un ejemplo mínimo.

3. Busca el error exacto en la documentación, no la solución completa.

4. Pide una pista, no la respuesta.

5. Mira la solución solo si has entendido el problema y quieres comparar enfoques.

6. Al día siguiente, reescribe la solución desde cero.

Copiar la solución sin haber sufrido el problema es entretenimiento, no aprendizaje.

Repetición espaciada

No hace falta inventar las tarjetas: el banco de preguntas de docs/ASSESSMENT.md ya tiene 53 con respuesta. Pásalas a Anki (o a una tabla) y añade a cada una:

• un ejemplo de código de tu laboratorio o de Kontor;

• la fecha del último repaso y si la acertaste sin mirar.

Empieza solo por las ⭐ y añade el resto cuando las domines.

Repasa 10 minutos al día. No añadas tarjetas que no puedas explicar con un ejemplo.

Recuperación activa

No releas. Intenta recordar.

• Cierra el editor y escribe la firma de una función de memoria.

• Explica un archivo de Kontor sin mirarlo.

• Dibuja el flujo de una transferencia en papel.

• Graba un audio de 90 segundos explicando Flow y escúchalo.

• Haz un mini-podcast de 3 minutos por tema. Si te lías, vuelve al código.

El curso de audio te da el modelo; tú tienes que producir el tuyo.

Interleaving

No hagas 20 ejercicios seguidos de lo mismo. Mezcla:

• un ejercicio de sintaxis;

• uno de colecciones;

• uno de dominio;

• una lectura de Kontor;

• una explicación oral.

Eso obliga a discriminar qué herramienta usar, que es lo que harás en una entrevista y en el trabajo.

Debugging

Cuando un test falla:

1. Lee el mensaje completo. No lo ignores.

2. Comprueba el valor esperado y el actual.

3. Aísla la entrada mínima que falla.

4. Usa println con etiquetas, no diez println sueltos.

5. Comprueba tipos y nulabilidad.

6. Si es una coroutine, comprueba el dispatcher y el scope.

7. Si es Compose, comprueba el estado y las claves.

8. Escribe una hipótesis antes de cambiar código.

Un bug no se arregla probando cosas al azar. Se arregla entendiendo la diferencia entre lo que crees que pasa y lo que pasa.

Code review de tu propio código

Cada viernes, revisa lo que has escrito esta semana:

• ¿Los nombres explican la intención?

• ¿Hay !! evitables?

• ¿Hay var que podría ser val?

• ¿Hay Any que podría ser un tipo concreto?

• ¿Hay lógica de negocio en la UI?

• ¿Los tests prueban comportamiento, no implementación?

• ¿La API pública es pequeña?

• ¿Hay código copiado que podría ser una función?

• ¿El error se trata o se esconde?

• ¿Se entiende sin abrir el resto del archivo?

Escribe tres mejoras y aplícalas. No reescribas todo.

Cómo usar la IA sin depender de ella

Pide:

• “Dame un test que falle para este concepto, no la solución.”

• “Revisa este código y señala tres problemas, sin reescribirlo.”

• “Hazme tres preguntas de entrevista sobre este archivo.”

• “Explícame este error de compilación sin darme el código final.”

• “Compara mi solución con una idiomática y señala diferencias.”

Evita:

• “Hazme el ejercicio.”

• “Dame la solución completa.”

• “Genera 100 archivos que no voy a leer.”

La IA es un compañero de práctica, no un sustituto de la práctica.

Cómo usar Kontor

No leas el repo entero. Haz una de estas tres cosas cada día:

1. Leer: un archivo, tres frases: datos, reglas, fallos.

2. Probar: ejecuta la app y sigue un flujo.

3. Cambiar: un ticket pequeño con test.

Orden recomendado:

1. core/domain/model y core/domain/validation.

2. core/data/local y core/data/repository.

3. feature/accounts y feature/transfer.

4. app y core/designsystem.

5. Tests.

Cómo usar el audio

• Primera pasada: solo audio.

• Segunda pasada: audio + tarjeta de código.

• Tercera pasada: pausa y explica tú.

• Cuarta pasada: intenta escribir el ejemplo sin mirar.

No escuches 90 minutos seguidos. 15–20 minutos y un ejercicio.

Anti-tutorial hell

Señales de que estás consumiendo en vez de aprendiendo:

• Ves vídeos y todo te parece lógico, pero no escribes nada.

• Copias código y funciona, pero no sabes por qué.

• Empiezas cinco cursos y no terminas ninguno.

• Lees sobre KMP antes de saber data class.

• Cambias de recurso cada vez que aparece una dificultad.

Antídoto:

• Un recurso principal por fase.

• Un ejercicio por concepto.

• Un test por ejercicio.

• Una explicación oral por sesión.

• Un proyecto por fase.

Retro semanal

Cada viernes responde:

1. ¿Qué he aprendido a hacer sin mirar?

2. ¿Qué he copiado sin entender?

3. ¿Qué test me ha costado más y por qué?

4. ¿Qué archivo de Kontor he leído?

5. ¿Qué explicaría a otra persona?

6. ¿Qué haré la semana que viene?

Guarda las respuestas en notas/retro-semana-N.md.

Evaluación mensual

Cada cuatro semanas:

• repite un ejercicio antiguo sin mirar;

• explica un archivo de Kontor en 90 segundos;

• resuelve un test nuevo en 20 minutos;

• revisa docs/ASSESSMENT.md;

• ajusta el plan.

Si no puedes explicar algo que “ya hiciste”, vuelve a practicarlo. Avanzar no es lo mismo que consolidar.