El arte de revisar

No exagero si digo que pasamos al menos una hora al día revisando el trabajo de los demás. ¿Por qué tanto? La respuesta es clara. Gracias a la revisión entre compañeros, mantenemos la calidad de nuestros productos. Además, aprendemos mucho como receptores y revisores. Pero realizar una revisión no es tarea fácil. Tienes que criticar de forma constructiva el trabajo de tus compañeros, parte del cual te ha costado sangre, sudor y lágrimas. ¿Cómo hacer que los comentarios sean constructivos y claros? Analizamos tres métodos de revisión por pares, incluido nuestro favorito.

Soluciones, soluciones, soluciones 

Para optimizar la calidad de tu trabajo, es necesaria una retroalimentación profunda. Una forma de hacer la revisión por pares es lo que yo llamo el método de saberlo todo. Haces tuyo el código o el texto. Has visto cada palabra, cada frase, cada interpunción o cada cadena varias veces, y sugieres alternativas para las partes que no cumplen los estándares de calidad. A veces esto va acompañado de una explicación de por qué lo has cambiado;

En el pasado, utilicé este método. Mira cómo cambié la introducción que mi colega Jeroen escribió para su artículo "Por qué no hacemos horas extra" 

Reconoces esto: estás en un proyecto con un plazo ajustado. Haces horas extra para llegar a la fecha límite. Después de unos días de horas extra, llegas a casa tarde y cansado, comes poco sano y te vas directamente a la cama. A la mañana siguiente te levantas temprano, aún sin haberte recuperado de la corta noche. Sé fuerte y heroico y cumple el plazo. Te prometes a ti mismo que la próxima vez será diferente. Que planificarás mejor, que harás esas mejoras que te has saltado esta vez. Saldrás de la oficina a tiempo y comerás con tu familia o tomarás una copa con tus amigos. Sólo que la próxima vez hay otro proyecto importante con fecha límite. Y se repite.

_{Borrador de introducción del artículo "Por qué no hacemos horas extra", escrito por Jeroen.}

Sugerí cambiarlo por esto para hacerlo más atractivo como introducción:

En la mayoría de los trabajos, la mayoría de las veces se esperan horas extra. No creemos que las horas extraordinarias sean la solución para hacer el trabajo y cumplir los plazos. Una y otra vez. De hecho, creemos que es contraproducente. Por eso terminamos las cosas después de una jornada de ocho horas, una jornada laboral normal en los Países Bajos. 

_{Introducción final del artículo, "Por qué no hacemos horas extra", escrito por Jeroen.} 

En mi opinión, la introducción de Jeroen era demasiado larga y contenía información que se repetía en el cuerpo del texto. Dediqué bastante tiempo a elaborar una nueva introducción, y Jeroen la aceptó;

Sustituir el trabajo propio por el ajeno reduce el sentimiento de propiedad total.

¿Qué salió mal? Inmediatamente di la solución. Este método de revisión no es mejor que limitarse a pedir aprobación. Por supuesto, como receptor de los comentarios, vislumbras el motivo del cambio. Pero al no reescribirlo tú mismo, pierdes la oportunidad de mejorar tus habilidades de redacción. Además, sustituir tu propio trabajo por el de otros reduce la sensación de propiedad total. Ya no parece tu trabajo. Por otra parte, sus niveles de inseguridad pueden aumentar, lo que puede provocar una peor calidad del trabajo futuro. El método de saberlo todo también puede facilitar algo totalmente distinto: usted da por sentado el feedback y deja de ser crítico con él. Esto es algo que tampoco queremos porque cada punto de feedback debería ser también una oportunidad de aprendizaje. En nuestra opinión, revisar el feedback que recibes es clave para tu propio desarrollo como desarrollador o escritor (front-end o back-end);

Rápido y sucio 

En el otro extremo del espectro, tenemos el método rápido y sucio. Consiste en pedir a tus compañeros que aprueben el trabajo que has hecho para pasar al siguiente paso del proceso. En realidad, no quieres feedback. Sólo quieres algo en línea porque: 

1. Habéis desarrollado el trozo de código juntos (programación en parejas). 

2. Es un cambio tan pequeño que nada puede salir mal. 

3. Sientes la presión del tiempo y los comentarios provocan un retraso.

4. Has discutido la solución con un colega y la has implementado después.

5. Has desarrollado la pieza de código juntos.

En el caso de las razones A y B, la vía rápida y sucia está permitida. En nuestro trabajo diario, lo hacemos muy a menudo. Forma parte de nuestro proceso. Pero esto no cuenta para la razón C, D y otras tareas complejas. De hecho, es necesario un par de ojos más, porque el diablo está en los detalles;

Encontrarse en el medio 

Los dos métodos de revisión por pares mencionados no son ideales en términos de aprendizaje. Por eso, nuestro querido método se encuentra en algún punto intermedio. En nuestra opinión, un valioso feedback entre iguales:  

• Es constructivo. Tratamos a los compañeros y su trabajo con respeto. 

• Te hace pensar. Te ayuda a reflexionar sobre tu trabajo y te anima a pensar en otras soluciones. 

• Consiste en preguntas. ¿Por qué lo has hecho así? Cuál es el motivo de esta configuración? ¿Pensaste en la opción X e Y en lugar de sólo en la Z?

• Hace posible que la gente lo procese por sí misma. Les indica la dirección correcta, sin dar la solución completa. Aunque, a veces, es muy difícil contenerse, sobre todo cuando se trata de errores menores. Por ejemplo: funciones y variables con nombres inconvenientes (código) o errores gramaticales (contenido). 

Consideramos que los comentarios de los compañeros sirven para iniciar una conversación. Joan, un desarrollador de back-end en Easy LMS, explica:  "No revelo toda la solución, a veces sólo una parte, pero principalmente discuto cómo se puede lograr una alternativa mediante la refactorización. Y esto a veces significa simplemente sentarse literalmente al lado de alguien para guiarle, en lugar de jugar al ping pong a través de GitHub o BitBucket, las herramientas que utilizamos para las revisiones de código."

"Lo que yo también hago a veces Ofrezco varias alternativas y dejo que el receptor decida cuál le conviene más. Es un rompecabezas porque hay que considerar detenidamente varias opciones".

 _{Ejemplos de conversación de revisión de código en GitHub.}

Según Joan, el feedback conversacional no siempre es necesario. Depende del tipo de código. "Supongamos que alguien ha puesto accidentalmente una vulnerabilidad (de seguridad) en el código, entonces está claro que hay que eliminarla. Por supuesto, explicaré por qué debe eliminarse y cómo puede evitarse a partir de ahora, pero no es el momento ideal para una gran conversación. Entonces el método de saberlo todo se adapta mejor".

Anna, nuestra asesora de implantación y hablante nativa de inglés, revisa todos los textos en inglés antes de ponerlos en línea y aplica también el método de conversación. Hace sólo unas semanas, ella misma corregía los errores gramaticales. Ahora se remite más a menudo a nuestra Guía de Estilo, para que la gente pueda arreglarlo por sí misma.  "Y cuando alguien cambia de tiempo constantemente, simplemente le pregunto qué tiempo debe usar".

Lleva más tiempo, pero al final compensa .

Cuanto más procese usted mismo los comentarios, mejor lo hará y menos tardará en ofrecer la calidad adecuada la próxima vez.

Este último método de revisión por pares requiere mucho tiempo, sobre todo al principio. Probablemente sea una de las razones por las que a veces volvemos a caer en nuestros viejos y cómodos hábitos. Pero nos lo repetimos una y otra vez: cuanto más te hagan pensar los comentarios y más los proceses tú mismo, mejor harás tu trabajo. Así, la próxima vez tardarás menos en ofrecer la calidad adecuada. Los beneficios son dobles. En última instancia, el revisor también tardará menos tiempo en revisar. Aun así, es importante seguir siendo crítico y aportar comentarios valiosos porque ayudan a:

• Involucrar a tus compañeros en tu trabajo diario. No hay islas aisladas de trabajo.

• Aumenta la confianza en el trabajo que creas porque otra persona piensa que merece la pena mirarlo.

• Mejora la calidad del trabajo. Es una inversión a largo plazo que evita errores (costosos).

• Mejorar la calidad del trabajo.

Este artículo fue revisado de forma conversacional?