Thoughts on Software Reflexiones sobre cómo dearrollar software y no morir en el intento

Reflexiones sobre cómo organizar un code retreat

El pasado sábado tuve la oportunidad de organizar un code retreat con la comunidad Scala de Madrid donde, además, hice de facilitador. La idea de un code retreat es tomarse un tiempo para hacer una práctica deliberada y mejorar nuestras habilidades de desarrollo de software en un entorno sin el estrés cotidiano que tenemos en nuestro trabajo. El principal ingrediente para conseguir esto es que, durante el code retreat, no existe ningún objetivo excepto el probar cosas nuevas, practicar y aprender, sin ninguna necesidad de tener algo “terminado” al final del día.

El code retreat en sí está organizado de la siguiente forma:

  • Se trabaja en un único problema durante todo el día (normalmente, el code retreat tiene un formato de ocho horas con una pausa para comer)
  • El trabajo se organiza en sesiones de 45 minutos seguidos de una discusión de unos quince minutos sobre cómo ha ido la sesión
  • Se trabaja siempre en parejas (esto es de suma importancia ya que facilitará que aprendamos unos de otros y hará más difícil que alguien se quede bloqueado)
  • Antes de cada sesión se organizan nuevas parejas
  • Al final del code retreat, se hace una sesión retrospectiva general sobre todo el día

En sí, el formato del code retreat es sumamente interesante y ha sido puesto en práctica muchas veces, habiendo incluso un día global del code retreat, en el que se celebra este evento simultáneamente en diferentes partes del mundo (participé en unos de ellos cuando estaba en Berlín y me resultó de lo más interesante). Ciertamente, recomiendo participar y, si puedes, incluso, organizar alguno, para lo que puedes tomar como punto de partida la información disponible en coderetreat.org.

En nuestro caso, decidimos trabajar sobre el Juego de la Vida, que es posiblemente el problema que más se ha utilizado en un code retreat. Si te gusta la programación y nunca lo has probado, te recomiendo que intentes hacer tu propia implementación del juego de la vida. Una vez tienes cierta familiaridad con el problema, te puede servir también para practicar cuando quieres aprender un lenguaje de programación nuevo, por ejemplo.

Aquí van algunas de mis notas finales una vez el code retreat hubo terminado.

Ten en cuenta el nivel de programación de los asistentes

Es recomendable que, antes de empezar a trabajar en el problema por primera vez, hagas una pequeña encuesta entre los asistentes y sepas qué nivel de programación tienen. Esta información me resultó útil para emparejar en la primera sesión a gente con más conocimiento de programación con gente que está empezando. Esto resulta de ayuda para que nadie se quede atascado en cosas triviales al principio, lo que puede desanimar bastante.

Conforme el día fue transcurriendo, fue también un acierto el emparejar a gente con un nivel de programación más alto, sobre todo en las últimas sesiones. Esto hizo que algunas parejas tuvieran tiempo de implementar soluciones más creativas y sofisticadas, lo que elevó el nivel de la conversación después de cada sesión de trabajo. Cuando los asistentes avanzados explicaban sus soluciones, todos aprendimos bastante.

No te preocupes si no todo el mundo consigue terminar el problema

Como ya dije, éste no es el objetivo de las sesiones y, de hecho, lo más normal es que no se termine el problema, sobre todo, durante las primeras sesiones, en las que los asistentes están familiarizándose con el mismo. Mientras la gente trabaja en el problema, lo normal es que estés paseando y viendo qué hacen, dando alguna explicación si alguien pregunta o incluso ayuda.

Pero no te apresures en dar demasiadas pistas ni ideas sobre cómo hacer el problema porque influirás demasiado en cómo trabajan las parejas. Llevado al extremo, podrías encontrarte con que todas las soluciones que se discuten tras la sesión se parecen demasiado entre sí porque, básicamente, se parecen a tu propia solución, así que no lo hagas.

No te cortes al introducir variantes

Existe un catálogo amplio de variantes que puedes utilizar en cada sesión y normalmente tiene bastante sentido utilizarlo como guía, ya que estas variantes están muy bien pensadas para conseguir que la gente interiorice mejor algunos conceptos. Pero no es necesario que te ciñas únicamente a ellas. De hecho, si no lo haces, tendrás la satisfacción de que le has dado a los asistentes algo más especial si introduces algo que se salga de las variantes más comunes.

En nuestro caso, como queríamos centrarnos en utilizar Scala (normalmente en un code retreat se puede utilizar cualquier lenguaje de programación que los asistentes quieran, pero éste era un evento organizado para la comunidad Scala por lo queríamos utilizar únicamente Scala para resolver el problema) decidimos usar una variante que consistía en resolver el problema haciendo el código puramente funcional. Esto resultó un reto para muchos de los asistentes y, al mismo tiempo, les permitió explorar algunas de las posibilidades del lenguaje que normalmente no utilizaban en su práctica diaria.

Además, en nuestra última sesión, decidimos improvisar respecto a lo que teníamos originalmente preparado, ya que había habido asistentes que tuvieron dificultades y no se terminaban de encontrar cómodos haciendo TDD (esto ocurrió, sobre todo, en las primeras sesiones). Así que decidimos probar en la última sesión lo siguiente:

  • Durante los quince primeros minutos, escribir todo el código posible para terminar el problema sin hacer ningún test
  • Cambiar de parejas: uno continuaría trabajando su propio código y otro trabajaría con una nueva pareja sobre un código que no conoce
  • Terminar el problema, esta vez haciendo TDD

La idea es que, en los primeros quince minutos, generemos algo de legacy code y ver cómo la gente reacciona al cambiarlo sin tener la red de seguridad de los tests. Tengo que decir que, para cuando hicimos esta sesión, la gente ya estaba más cómoda con TDD e incluso protestaron un poco al sugerirles que escribiese la máxima cantidad de código que pudieran sin ningún test.

Al final, cuando tuvimos la discusión después de esta sesión, el tema más repetido por quienes llegaron a un código nuevo fue lo difícil que había sido modificar el código y continuar con el problema sin tener ningún test, incluso teniendo la ayuda de otra persona que sí conocía dicho código al lado.

Así es como resultó ser nuestro code retreat:

  • Introducción al formato de code retreat y al problema sobre el que trabajaríamos (25 minutos)
  • Primera sesión: resolver el problema sin ningún tipo de restricción (una hora)
  • Segunda sesión: no usar estructuras de control condicionales ni pattern matching y mantener todos los métodos/funciones lo más reducidos posibles (no más de 3 líneas de código) (una hora)
  • Pausa para almorzar
  • Tercera sesión: hacer el código puramente funcional (una hora)
  • Cuarta sesión: trabajo sobre código hecho por otros y sin tests (una hora)
  • Discusión final acerca de todo lo que hicimos durante el día, lo que habíamos aprendido y lo que nos había sorprendido más (45 minutos)

En resumen, fue una experiencia de lo más gratificante y enriquecedora. Al final, creo que todos aprendimos algo y pudimos conocer a gente muy interesante. Espero poder repetir en el futuro, ya sea como asistente o facilitador. En cualquier caso, será divertido. ¡Anímate tú también!