Repite, aprende cuándo debes dejarlo y busca siempre la retroalimentación
Todos intentamos a veces asumir tareas más significativas de las que podemos cumplir, lo que se deriva directamente de nuestra incapacidad humana para evaluar correctamente las tareas complejas. Veamos cómo puede abordar esto en su viaje de software.
Iterar
Avanzar en pasos pequeños y manejables es una piedra angular en muchas metodologías comunes en nuestra industria:
- Ágil – se trata de iterar con los cambios del producto para descubrir lo que los clientes necesitan.
- Producto mínimo viable (MVP) – tiene como objetivo crear la primera versión que se pueda contrastar con el mercado, y luego se itera a partir de ahí.
Veamos cómo utilizar un enfoque similar en tu día a día.
Mientras aprendes
La mejor idea sería:
- Aprender un material, y luego
- Utilizarlo
El material de trabajo le presentará regularmente retos para aplicar y poner a prueba sus conocimientos en un curso o libro bien organizado. Si aprendes sin ese lujo, tendrás que crear esos ejercicios por ti mismo.
En ambos casos, la mejor retroalimentación que puedes obtener es que tu código funcione como se espera, por lo que deberías utilizar lo que estás aprendiendo de tu proyecto paralelo o empezar uno nuevo.
Mientras trabajas en un ticket
¿Te quedas atascado a menudo en un ticket? Lo más probable es que esté tratando de hacer demasiadas cosas simultáneamente. Normalmente, puedes dividir una tarea en:
- refactorizar el código en el que vas a trabajar
- agregando métodos de ayuda de infraestructura de código, tipos de actualización, etc.
- realizar los cambios en la lógica de la aplicación
- añadir pruebas de extremo a extremo para la nueva función
En la mayoría de los casos, es mejor hacer cada parte en un commit separado: no quieres revisar o revertir las refactorizaciones con una nueva implementación. Dividir las cosas en commits separados, y quizás incluso en pull requests, te permite obtener una revisión de tu código más rápidamente, acelerando así tu progreso.
¿Qué debes hacer si no conoces el código lo suficientemente bien como para planificar tus acciones con antelación, o simplemente te has olvidado y tienes todos los cambios hechos simultáneamente? No te preocupes, el conocimiento que ganaste durante el primer intento no se desperdiciará ahora, puedes dar un paso atrás, empezar una nueva rama, y aplicar o rehacer alguna parte del gran commit que empezaste.
Mientras haces proyectos
No importa si trabajas en proyectos comerciales o en código abierto, escuchas el mismo mantra en todas partes:
- “Libera pronto, libera a menudo”.
- “Muévete rápido y rompe cosas”.
Incluso si estás trabajando en algún proyecto personal de aprendizaje, puedes aplicar esta mentalidad. En lugar de planificar una gran versión final de tu proyecto, intenta simplificar lo que estás construyendo a un mínimo completo.
Evita caer en un agujero de conejo
Tu principal objetivo al hacer las cosas en iteraciones es evitar caer en una madriguera de conejo. Es bueno dedicar tiempo a investigar cosas; y como desarrollador, tienes que ser resistente a la frustración de no saber cómo funciona algo o cómo solucionar un error. Lo malo es que esa misma fortaleza ante la frustración a veces se vuelve en tu contra. En algún momento, el rendimiento de la inversión de dedicar más tiempo disminuye hasta el punto de que sólo estás perdiendo el tiempo. Estarás muy metido en el asunto y ya habrás invertido en solucionarlo cuando ocurra, así que dejarlo pasar no será fácil. ¡Veamos cómo puedes evitar estas trampas!
No estás solo
En la mayoría de los casos, no estás trabajando solo: hay otras personas alrededor que pueden ayudarte. Como principiante, tienes dos modos potenciales de fracaso
- buscar ayuda demasiado temprano
- buscar ayuda demasiado tarde
¿Qué es demasiado tarde o demasiado temprano? Bueno, eso depende de la situación en la que se encuentre su equipo. Puedo imaginar fácilmente dos extremos
- Tu equipo está bajo mucha presión, una emergencia de algún tipo, por lo que no hay ningún desarrollador experimentado disponible para ayudar
- Estás tomando el relevo de un desarrollador que se va en dos semanas, así que la prioridad es obtener el mayor conocimiento posible de él
Mi consejo es que establezcas reglas explícitas con tu equipo y que te ciñas a ellas. Así, si está de acuerdo en que cuatro horas de golpearse la cabeza contra la pared en un ticket es demasiado, entonces después de cuatro horas, busque ayuda.
Aprende a dar por terminado el trabajo
La idea no es mejor sólo porque hayas pasado muchas horas aplicándola. En todo caso, has demostrado que el planteamiento no es viable o no es tan fácil como se esperaba. Evita la falacia del coste hundido: la estrategia excelente es estimar antes de empezar cuánto tiempo quieres dedicar a una tarea antes de dejarla, y luego ceñirte a esa estimación. Dependiendo del ticket, dejarlo puede significar dejar que otro desarrollador lo retome o no hacerlo del todo, al menos en este momento.
Busca siempre la retroalimentación
Cada paso de la interacción es un punto en el que podemos y debemos obtener retroalimentación. Nos permitirá corregir el rumbo y asegurarnos de que vamos por el buen camino. Hay un montón de tipos de retroalimentación que podríamos buscar:
- Pruebas automatizadas que pasan localmente o en CI
- Un colega más experimentado o tu mentor revisando el código
- Presentación de nuestro producto en el exterior y recopilación de comentarios
