Esta página es para responsables técnicos que quieren sacar a su equipo del bucle de tickets y darle un espacio donde equivocarse sea parte del trabajo. Aquí contamos cómo se ve ese espacio en la práctica: retos acotados, revisiones de código entre pares y demos internas donde el resultado importa menos que las decisiones que se tomaron por el camino.
Siguiente paso
Si coordinás un equipo que programa por gusto, la forma más directa de probar el formato es entrar a un reto en curso. Se publica el enunciado, se comparte la solución y se revisa el código de otros sin ceremonia. En una sesión de trabajo ya se ve si el ritmo encaja con vuestras prioridades.
Antes de escribir, conviene mirar cómo funciona una entrega y qué se espera en la revisión.
Acción concreta
Escribinos con el tamaño del equipo y el lenguaje que usan. Te pasamos el reto activo y el hilo de revisión para que lo prueben esta semana.
Contactar con el colectivoTambién podés ver cómo se organiza un reto o volver a la portada.
No es una plataforma cerrada ni un curso con temario fijo. Es un ritmo de trabajo que ya funciona en equipos pequeños: retos semanales, revisión entre pares y material publicado sin edulcorar. Estos son los puntos donde se nota la diferencia al cabo de unas semanas.
Cada reto llega con un enunciado corto, un conjunto de pruebas y una fecha de entrega. Se puede resolver en horas sueltas entre reuniones, sin bloquear al equipo ni exigir dedicación completa.
Los hilos de revisión se centran en decisiones concretas: por qué un bucle se reescribió como recursión, qué coste tiene ese shader en móvil, dónde se coló un off-by-one. Sirve para que la gente junior vea criterio, no solo sintaxis.
Hay retos en JavaScript, Python y Processing, pero también katas de algoritmos en cualquier lenguaje que el equipo quiera probar. Es una excusa barata para que alguien explore Rust o GLSL sin montar un proyecto entero.
Las soluciones publicadas incluyen tiempos de ejecución, errores frecuentes y capturas de perfilado. Cuando alguien del equipo retoma un reto antiguo, encuentra el contexto y no tiene que reconstruirlo desde cero.
Los fragmentos comentados y las katas por dificultad se usan tal cual en sesiones de onboarding técnico. No hace falta preparar ejercicios nuevos cada trimestre: se eligen tres retos y se adaptan al stack del equipo.
Varias personas resuelven el mismo reto y se comparan los caminos: una versión con canvas 2D, otra con WebGL, otra en línea de comandos. El equipo aprende del contraste y no de un único modelo correcto.
Si queréis ver cómo encajan estos retos en un flujo de trabajo real, el proceso paso a paso y la página de quiénes estamos detrás dan el contexto que aquí solo se resume.