A veces, intentamos asumir tareas más importantes de las que podemos cumplir—esto se deriva directamente a nuestra incapacidad humana para evaluar tareas complejas correctamente. Veamos cómo puedes abordar esto en tu viaje de TI.

Iterar

Avanzar en pasos pequeños y manejables es una piedra angular en muchas metodologías comunes en nuestra industria:

• agile– se trata de iterar con los cambios en el producto para descubrir qué necesitan los clientes, mientras que
• producto mínimo viable (MVP) – tiene como objetivo crear la primera versión que se puede comparar con el mercado, y luego se itera desde allí.

Veamos cómo usar un enfoque similar en su vida diaria.

Mientras aprende

La mejor idea sería:

• aprender una parte del material, y luego
• usarlo.

El material de trabajo te presentará regularmente desafíos para aplicar y probar tu conocimiento en un curso o libro bien organizado. Si aprendes sin ese lujo, necesitarás crear esos ejercicios por ti mismo. En ambos casos, la mejor respuesta que puedes obtener es que tu código funciona como se espera—por lo que debes usar lo que estás aprendiendo en tu proyecto paralelo o comenzar uno nuevo.

Mientras trabaja en un ticket

¿A menudo te quedas atascado en un ticket? Lo más probable es que estés tratando de hacer demasiadas cosas al mismo tiempo. Por lo general, puedes dividir una tarea en:

• refactorizar el código en el que estás a punto de trabajar
• Agregar infraestructura de código—métodos auxiliares, tipos de actualización, etc.
• hacer los cambios en la lógica de la aplicación
• agregando pruebas de extremo a extremo para la nueva función

En la mayoría de los casos, tiene más sentido hacer cada parte en commit separados: no quieres revisar o revertir las refactorizaciones con una nueva implementación. Dividir las cosas en commit separados , y tal vez incluso en pull request , le permite obtener una revisión de su código más rápido, lo que acelera su progreso.

¿Qué debes hacer si no conoces el código lo suficientemente bien como para planificar tus acciones con anticipación, o simplemente lo olvidaste y tienes todos los cambios realizados simultáneamente? No te preocupes , el conocimiento que obtuviste durante el primer intento no se desperdiciará—ahora, puedes dar un paso atrás, comenzar una nueva rama y aplicar o rehacer parte del gran commit que comenzaste.

Mientras haces proyectos

No importa si trabajas en proyectos comerciales o de código abierto—escucha el mismo mantra en todas partes:

• "Publicar temprano, publicar a menudo."
• "Muévete rápido y rompe cosas."

Incluso si estás trabajando en algún proyecto de aprendizaje personal, puedes aplicar esta mentalidad. En lugar de planificar una gran versión final de tu proyecto, intenta simplificar lo que estás construyendo al mínimo. Puedes encontrar algunos ejemplos en mi artículo sobre el aprendizaje con proyectos personales.

Evita caer en la madriguera del conejo

Su principal objetivo al hacer las cosas en iteraciones es evitar caer en una madriguera de conejo. Es bueno pasar tiempo investigando cosas; y como desarrollador, debes ser resistente a la frustración de no saber cómo funciona algo o cómo corregir un error. Lo malo es que la misma fuerza ante la frustración a veces juega en tu contra. En algún momento, los rendimientos de la inversión de pasar más tiempo disminuyen hasta el punto en que solo estarás perdiendo el tiempo. Estarás muy involucrado en el problema y ya estarás involucrado en solucionarlo cuando suceda, por lo que dejarlo ir 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 a tu alrededor que pueden ayudarte. Como principiante, tienes dos posibles maneras de fallar:

• buscar ayuda demasiado rápido
• buscar ayuda demasiado tarde

¿Qué es demasiado tarde o demasiado rápido? Bueno, eso depende de la situación en la que se encuentre tu 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 ayudarlo
• está reemplazando a un desarrollador que se va en 2 semanas, por lo que la prioridad es obtener el mayor conocimiento posible de ellos

Mi consejo es encontrar reglas explícitas con su equipo y luego apegarse a ellas. Entonces, si estás de acuerdo en que cuatro horas de golpearse la cabeza contra la pared con un ticket es demasiado, después de cuatro horas, busca ayuda.

Aprende cómo dejarlo

No es una idea mejor solo porque pasaste tantas horas implementándola. En todo caso, demostró que el enfoque no es factible o no es tan fácil como se esperaba. Evita la falacia del costo irrecuperable: la estrategia excelente es estimar, antes de comenzar, cuánto tiempo desea dedicar a una tarea antes de dejarla atrás, y luego apegarse a esa estimación. Dependiendo del ticket, dejarlo puede significar dejar que otro desarrollador lo recoja o no hacerlo todo junto, al menos ahora.

Busca siempre retroalimentación

Cada paso de la interacción es un punto en el que podemos y debemos recibir retroalimentación. Nos permitirá hacer algunas correcciones de rumbo y asegurarnos de que estamos en el camino correcto. Hay muchos tipos de comentarios que podríamos buscar:

• pruebas automatizadas que pasan localmente o en CI
• colega más experimentado o su mentor revisando el código
• presentar nuestro producto externamente y recopilar comentarios

¿Quieres aprender más? Consulta mi otro artículo sobre retroalimentación.