Cómo acelerar tu progreso con retroalimentación

Un bucle de retroalimentación es una parte esencial de todos los sistemas de control, excepto los más sencillos. Y si te preocupas por conseguir algún objetivo, como, por ejemplo

• aprender,
• la creación de una aplicación de trabajo, o
• ganar dinero,

entonces se trata de un sistema de control no trivial. Echemos un vistazo a las características clave de un ciclo de retroalimentación efectivo y cómo puedes usarlo en tu carrera de TI.

Cuanto más rápido, mejor

Cuanto antes sepas si las cosas van bien o mal, mejor. No hay ninguna ventaja en avanzar en la oscuridad. Si ya estás en un buen camino, la retroalimentación reforzará tu compromiso con lo que haces ahora. Si estás haciendo algo mal, puedes corregir tu curso cuando recibas comentarios. Imaginate lo complejo que sería conducir o andar en bicicleta si tu visión se retrasara incluso una fracción de segundo. Sería suficiente para producir efectos similares a conducir ebrio.

Dependiendo de la complejidad del sistema, actuar sobre ese conocimiento aún puede requerir tiempo. Si notas que tu carrera actual no es para ti , aún necesitarás algunos años para obtener una nueva. Pero preferirías saber esto durante tu primer semestre en la universidad en lugar de después de graduarte.

Tus bucles de retroalimentación diarios

Pensemos por un momento en todos los ciclos de retroalimentación de los que formas parte todos los días como desarrollador.

Cambios en el código

A medida que trabajas en el código, debes verificar el impacto de tus cambios en el comportamiento del código. Las pruebas automatizadas son una forma rápida y sólida de obtener retroalimentación. Escribir pruebas lleva tiempo al principio, pero te permite ser más productivo a largo plazo. Eso es incluso sin considerar el impacto de calidad a largo plazo de mantenerlos cerca.

Con lógica compleja, a menudo prefiero comenzar con pruebas. Simplemente entender todos los detalles internos es difícil, y preferiría hacerlo una vez mientras escribo las pruebas y no cada vez que cambio algo en el código.

Trabajo diario en un ticket

Si estás trabajando en un equipo bien organizado, algunos otros miembros del equipo revisarán tu trabajo. Tener tu trabajo revisado es una excelente manera de aprender la forma en que el equipo hace las cosas, así como aprender más sobre el arte de la programación. Pero puede ser frustrante si pasas uno o dos días trabajando en un ticket y luego recibes más de 40 comentarios en la solicitud de extracción.

Puedes acelerar los comentarios que recibes dividiendo el trabajo en pequeños pasos y solicitando comentarios después de cada uno de ellos:

1. Después de leer un ticket, explicalo a alguien que entienda bien de qué se trata. Si no lo entendiste bien, podrán corregirte.
2. Escribe cómo planeas abordar la solución—y haz que otro desarrollador la revise antes de dedicar tiempo a implementarla. Tal vez te señalen algo que no sabías.
3. Sin embargo, lo más importante es la retroalimentación sobre la lógica del programa. Solicita una revisión mientras aún estás realizando las pruebas.

Versión de la aplicación

A medida que avanza el sprint, hay una pila creciente de cambios inéditos que esperan ser publicados. Tendría sentido esperar solo si tiene un protocolo de prueba elaborado y si este tiempo está bien empleado. Si no se realizan pruebas significativas, solo está retrasando los comentarios de los usuarios. Cuando sea posible, intente implementar con la mayor frecuencia posible. De esta manera, en lugar de un gran lanzamiento con todos los cambios (y errores) que realizó su equipo en unas pocas semanas de sprint, publica una pequeña parte cada pocos días.

Adecuación al mercado del producto

Incluso en una escala mayor, esto todavía se aplica. Con metodologías como Agile o Lean Startup, el objetivo es sacar tu producto lo antes posible y obtener retroalimentación del mercado.

¿Qué pasa con la calidad de la retroalimentación?

No toda la retroalimentación es igual. Siempre está en algún lugar del espectro—desde los resultados precisos de las pruebas, hasta la opinión subjetiva de la persona que la escribió. En el caso de información objetiva, como

• las pruebas fallan o las funciones fallan,
• las aplicaciones son perceptiblemente lentas, u
• otros indicadores de desempeño están fuera de los valores esperados,

a menudo es una buena idea comenzar a abordarlo de inmediato.

En caso de opinión subjetiva:

• manera de codificación
• denominación de variables o métodos
• cualquier otra cosa que diferentes desarrolladores puedan arreglar de una manera diferente

Aquí las cosas son más sutiles. Podría estar yendo en contra de una convención bien establecida en el proyecto, o su nombre podría ser confuso—cosas que es mejor arreglar pronto. Por otro lado, a veces las personas comparten cómo harían las cosas, pero más teniendo una conversación sobre cómo se deberían hacer las cosas en el proyecto.

¿Y tu?

¿Alguna vez has recibido comentarios que dieron forma a tu carrera? Por favor comparte tu historia en los comentarios; ¡Me encantaría oírlo!