Como desarrolladores, parte de nuestro trabajo diario es opinar sobre el trabajo de los demás miembros de nuestro equipo. Esto se vuelve muy evidente al hacer "code review", instancia en la cual revisamos el código desarrollado por alguien más y entregamos nuestra opinión.
El proceso de opinar sobre el código ajeno es clave para un equipo de desarrollo, porque cuando escribimos código no solo estamos plasmando las reglas que harán funcionar bien (o mal) nuestro sistema de software, sino que también estamos plasmando nuestro conocimiento del negocio, y construyendo un documento (el código) que será leído, masticado y modificado en el futuro, por personas que quizás ni siquiera han llegado al equipo.
¿Sobre qué opinamos cuando revisamos el código ajeno? Sobre muchas cosas distintas. Algunas están relacionadas con cómo funcionará lo que hicimos: ¿Resuelve el código el problema descrito? ¿Hay casos de borde que no se consideraron? ¿Se incluyeron las pruebas automáticas necesarias para validar lo que se hizo? Otras veces opinamos sobre la "calidad" del código: ¿Se puede leer y entender el código que se escribió? ¿Qué tan mantenible será este código a largo plazo, cuando queramos hacer alguna modificación? ¿Cumple con nuestras convenciones y estándares de como escribir código?
Como buenos opinólogos, es fácil a veces quedarnos solo con dar nuestra opinión sin argumentos: "No se entiende lo que escribiste", "no me gusta como hiciste esto", "creo que esto no va a funcionar". Pero dar un buen feedback es ir más allá de una opinión, necesitamos agregar un argumento que respalde nuestra opinión: feedback = opinión + argumento
Si decimos algo como "creo que esto no va a funcionar", tenemos que complementarlo con un argumento: "Si pruebas con estos datos específicos, tu solución no funciona".
O si damos la opinión "no me gusta como hiciste esto", podemos complementarlo con un "en mi experiencia cuando este tipo de problemas se resuelve así, es muy difícil de mantener a largo plazo".
Hay distintas formas de argumentar que podemos usar a la hora de dar feedback sobre código. Una forma poderosa es argumentar usando evidencia empírica: "Probé tu código y no funciona para este caso" o "te falta una prueba automática para este caso" o "nuestro estándar de como hacemos esto es tal, y esto no está así".
A veces no es posible tener evidencia empírica de una opinión y tenemos que argumentar de otras formas menos "objetivas". Podemos, por ejemplo, argumentar desde la experiencia: "En mi experiencia..." o desde la evidencia anecdótica: "La última vez que hicimos algo parecido a esto pasó que ...".
En cualquier caso, cualquiera sea el tipo de argumento, la opinión debe ser considerada como un punto de partida en una conversación. Si soy quien recibe la opinión, tengo que estar abierto a escuchar lo que mi compañero de equipo dice. Si soy quien opina, tengo que estar dispuesto a recibir un argumento contrario a mi opinión y que mi argumento pueda ser cuestionado.
¿Cuándo terminamos de opinar, argumentar y contra argumentar? Si estuviéramos en un foro de internet, la discusión podría no terminar nunca. Pero parte de un buen trabajo en equipo es transar y llegar a acuerdos. No podemos olvidar que como equipo estamos juntos en esto.
Poder escuchar realmente la opinión de mis compañeros y lograr llegar a estos acuerdos es una señal de que existe confianza en el equipo. Y esa confianza se construye día a día, opinión a opinión.
Si quedaste con ganas de convertirte en opinólogo, en Buda.com estamos contratando desarrolladores.
Join the conversation.