💪 Open source como entrenamiento
Hace ya un tiempo, hice mi primera toma de contacto con el open source en Pytest, este artículo se basa en recordar que es importante colaborar y tener poner nuestro granito de arena como desarrolladores, sin dedicarnos todo nuestro tiempo a nosotros mismos o nuestros proyectos. Llevo ya 1 año y medio sobre la misma base de código trabajando y he notado la falta que me hace empezar a ver cosas nuevas, un ejemplo de esto es que gracias al código donde colaboré vi en Python el operador walrus.
Volviendo un poco al tema del título, si veo potencial de entrenar de esta manera, actualmente hago 2 entrenamientos para mejorar:
- Adquisición de nuevos conocimientos (leer libros, cursos, etc.) de forma reiterada e iterativa.
- Aplicación de conceptos (katas, revisiones de código, etc.)
Aquí el problema que he tenido es en segundo punto, ya que las katas son código nuevo de usar y tirar, pero no le he dedicado el suficiente tiempo a trabajar en códigos más complejos y fuera del ámbito del hacer lo que ya sabemos. He descubierto una página donde se recopilan “good first issue” para empezar en el open source, hay mucho donde elegir, pero me he basado en los siguientes criterios:
- Tiene que tener algún test (si voy a añadir o eliminar funcionalidades pondré un test o varios, así que con esto me aseguro que esa persona que lo mantiene está alineada conmigo).
- La base de código no puede ser muy grande (así cuesta menos esfuerzo entender el contexto).
- El paradigma o enfoque del código no puede ser de algo en lo que trabajado anteriormente. (así me aseguro de ir con el vaso lo más vacío posible).
- La solución no es obvia ni está superbién documentada paso a paso.
Voy a dejar la issue aquí por si tenéis curiosidad, lo primero que hay que hacer es preguntar por el setup si no hubiese suficiente documentación, lo siguiente es reducir la incertidumbre y acotar el problema.
![given-when-then](/_next/image?url=%2Fassets%2Fblog%2Fopen-source-as-a-training%2Fgiven-when-then-example.webp&w=1080&q=75)
Para mí esta parte es fundamental, sobre todo como consultor, ser capaz de pasar algo incierto a concretar en el código es una skill en sí misma. La parte restrictiva del ejercicio es literalmente hacerte pasar por el propio autor, la persona que lea el código no se debe percatar de quién lo hizo, además de que pienso que muy probablemente no sea yo quien lo mantenga, así que en este contexto es mejor adaptarse. Ahora, dentro de la restricción, hacerlo lo mejor posible, incluso si el código es complejo de entender o reproducir el problema.
Me he llevado mucho de este videojuego, he aprendido bastante, no soy un experto en patrones de diseño en videojuegos, pero está claro que ya se estaba empezando a mutar el estado de los objetos dónde no se debía, etc. Estoy seguro de que su autor se preocupa mucho por él, me contestaba casi a cualquier hora, me alegro de ver gente con la valentía de decir, no me gusta lo que estoy jugando, me voy a hacer un juego para pasármelo bien sin buscar un beneficio. Os recomiendo echarle un ojo a la página y darle a algo pequeño siempre será bien tratado, al menos en mi experiencia en la comunidad.