Son casi las 6am cuando empiezo a escribir esto (5.58, para ser precisos) y es porque acabo de renovar la suscripción del blog, el cual tiene más de veinte años desde que lancé la primera versión en Blogger. Esa época ya sucedió y he visto pasar más de una red social, páginas de tecnología que ya no existen y cuentas de personas que admiro y que, bueno, ya no publican.
No sé cuándo dejaré de publicar cosas, regularmente lo hacía en Twitter, Facebook, incluso ahora, dejo algunas piezas en LinkedIn, pero veamos si uso este espacio para algunas cosas que están, como llamo a veces “work in progress”, que, claro, se puede compartir.
Opciones gratuitas que valen la pena considerar (en caso de no poder usar Claude Code) – OpenCode + Big Pickle – Gemini CLI + Gemma4
No termino de probar diversas opciones que siguen y siguen apareciendo, pero hasta el momento las que les cuento me parecen adecuadas para trabajar, mucho mejor si agregas reglas para mejorar la precisión. Aunque de eso hablaremos más adelante.
Hace poco descubrí una entrevista muy interesante entre Allen Holub y Robert “Uncle Bob” Martin. Quizá el segundo sea más conocido por Clean Code o la saga de libros Clean, pero Allen cuenta con la experiencia necesaria para darle muy buen curso a la conversación con preguntas, acotaciones y puntos de vista que hacen que la media hora pase sin que nos demos cuenta.
En la entrevista se tocan puntos como: – Lo que debemos hacer si nos interesa evolucionar como desarrolladores de software – Libros que deberíamos leer y la importancia de los fundamentos que encontraremos en estos – La práctica hace al maestro, pero podría tomar algo de tiempo – Liderazgo y su impacto en el aprendizaje y productividad del equipo – El trabajo remoto y la necesidad de las interacciones personales – Puedes invertir tiempo enseñando y te irá bien con eso, pero tienes que aceptar que no vas a convencer a todo el equipo – Disciplina, estándares y ética
No entraré en detalles de la importancia de esta práctica, creo que ya es sabido y se tienen muy buenos artículos al respecto, pero yendo del dicho al hecho… ¿qué hacemos?
Aquí una lista de consideraciones a tener en cuenta:
1. Roles claros: El código se escribe (autor), se revisa (revisor) y aunque al principio no parezca, le pertenece a todos (dueño). Además, el autor no puede ser juez y parte de lo que propone, el revisor puede incluir a otro revisor en caso de que alguna revisión/observación se extienda más de la cuenta, y como dueños somos responsables de la calidad del código.
2. Reglas claras: Para no depender de opiniones y gustos, debe existir un checklist y este debe ser de conocimiento –y uso– general. Además hay que aceptar que –salvo posibles excepciones– no hay nada nuevo por inventar (estilos, nomenclatura, estructuras, etc.), así que el equipo debe acordar el conjunto de reglas a seguir (existen muchas, con casos ya comprobados), las excepciones del caso y cómo abordar cada una de estas.
3. Tiempos de entrega: El tiempo de revisión, entrega de feedback y correcciones no debe comprometer los avances del trabajo, pero de darse el caso, debemos ser conscientes y empáticos sobre las consecuencias del volumen de código a revisar. En caso de no haberse conversado, volver al punto 2.
4. Esquema de revisión: Se deben abordar aspectos de arquitectura (¿se cumple con la estructura y/o diseño propuesto?), estilos (¿se respetan los estándares de nomenclatura, formato, programación o pruebas?), legilibilidad (¿se entiende sin tener que preguntar al creador?), ubicuidad (¿se usa el lenguaje y terminologías del producto?), funcionalidad (¿cumple con lo requerido?) y cobertura (¿las pruebas automatizadas incluyen los casos no exitosos?). Aquí es importante tener en cuenta que cada uno de estos esquemas de revisión deben reflejarse de manera explícita en las reglas respetadas por el equipo. Caso contrario, volver al punto 2.
5. Feedback concreto, respetuoso y de atención rápida: Siempre hay que tener presente que por más que uno desee, no todos tenemos el mismo nivel de conocimiento y entendimiento, así que para acortar esa brecha, cada observación debe ser lo más clara posible. Incluir código de ejemplo y observar de manera propositiva ayudan mucho, pero ayuda mucho más proponer una sesión de revisión conjunta.
Antes de hablar, sea para explicar o responder algo, recuerda que no todos experimentaron lo mismo que tú. Y así hayan estudiado o tengan conocimiento de los mismos temas, cada persona tiene su proceso, su forma de entender las cosas y claro, podrías estar equivocado.
Clare Sudbery (she/her) plantea muy bien este tipo de situaciones en The Stupidity Manifesto, el cual por cierto, a pesar de tener un título algo crudo y directo, creo que refleja muy bien el punto al que quiero llegar.
Antes de despedirme les comparto una captura que tomé hace un tiempo en un O’Reilly Live Event, una publicación de Clare y claro, contarles que cada cierto tiempo evalúo situaciones por las que he pasado, reflexiono sobre mi comportamiento y creo que, como es natural, hay cosas en las que debo seguir trabajando.
Jersson on the block 2.0 