Un circuito de retroalimentación es una parte esencial de todos los sistemas de control, excepto los más sencillos. Y si te preocupas por conseguir alguna meta, como por ejemplo:

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

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á en un buen camino, la retroalimentación reforzará su compromiso con lo que hace ahora. Si está haciendo algo mal, puede corregir su curso cuando reciba comentarios. Imagínese lo complejo que sería conducir o andar en bicicleta si su 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 te enteras de que tu carrera actual no es para ti, aún necesitarás algunos años para obtener una nueva. Pero preferirías encontrar 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 bucles de retroalimentación de los que forma parte todos los días como desarrollador.

Cambios de código

A medida que trabaja en el código, debe verificar el impacto de sus 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 por adelantado, pero le 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á trabajando en un equipo bien organizado, algunos otros miembros del equipo revisarán su trabajo. Tener su 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 pasa uno o dos días trabajando en un ticket y luego recibe más de 40 comentarios en la solicitud de fusión.

Puede acelerar los comentarios que recibe dividiendo su trabajo en pequeños pasos y solicitando comentarios después de cada uno de ellos:

1. Después de leer un boleto, parafraséelo a alguien que entienda bien de qué se trata. Si su comprensión es incorrecta, podrán corregirlo.
2. Escriba cómo planea abordar la solución y haga que otro desarrollador la revise antes de dedicar tiempo a implementarla. Tal vez te indiquen algo que no sabías.
3. Sin embargo, lo más importante es la retroalimentación sobre la lógica del programa. Solicite una revisión mientras aún está actualizando las pruebas.

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 los comentarios?

No todos los comentarios son iguales. Siempre está en algún lugar del espectro, desde los resultados precisos de las pruebas hasta la opinión subjetiva de una persona que da la retroalimentación. En el caso de entrada objetiva, como

• las pruebas fallan o las características no funcionan como se esperaba,
• las aplicaciones son perceptiblemente lentas, o
• otros indicadores de desempeño están fuera de los valores esperados,

En caso de opinión subjetiva:

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

Want to Connect?
Originally published at https://how-to.dev.