En esta segunda parte de la guía (si no vieron la primera parte, está acá), y asumiendo que ya tenemos el proyecto levantado y una idea general de la arquitectura del sistema y del contexto de negocio en el que trabajamos, voy a compartirte algunos consejos para esos primeros tickets y días de trabajo.
Caminante no hay camino!
En general, a menos que estés haciendo algo realmente muy extraño (como un proyecto de investigación, o algo así), considero que la mejor forma de aprenderte como funciona el código de un proyecto, es haciendo tareas simples en el mismo, generalmente bugfixing.
Y no estoy solo, en mi experiencia, la mayoría de PMs, POs y Líderes Técnicos comparte esta manera de pensar y, al "recién llegado" inicialmente le van a dar tareas más simples para que vaya aprendiendo el proyecto, y limitando el alcance de los problemas que el recién llegado se pueda encontrar o pueda causar.
Por lo que no tengas miedo, que tu equipo y superiores sabe que los primeros días son complicados, y que lleva tiempo amoldarse a un proyecto.
Equilibrando el Tiempo
Como recién llegados, nuestra cabeza tiene que hacer un balance en como usar nuestro tiempo. Queremos al mismo tiempo pasar rápido de hacer estas primeras tareas, y entender el código del proyecto.
Queremos entender el código, para no frustrarnos a futuro cuando tengamos que hacer algo más complicado y no entendamos nada de como funciona y la situación nos sobrepase. Queremos estar preparados digamos.
Y queremos pasar rápido de las primeras tareas, porque el 99.9% de las veces las primeras tareas son más aburridas que chupar un clavo, o mirar el pasto crecer, y aparte nos hace quedar bien con el resto del equipo y la empresa.
Respecto a mindset, recomiendo dejar la brújula en "entendamos como está estructurado en líneas generales el proyecto" y en "entendamos en líneas generales el código involucrado en la tarea". Esto último es importante: no hace falta que entiendas todo, absolutamente todo de lo que estás tocando, lo importante es que entiendas como funciona el contexto de lo que vas a modificar (más o menos) y en caso de que sea algo relacionado con datos, el flujo de datos de la aplicación.
Entendé por donde llegan los datos desde el backend al frontend, o desde la base de datos a la respuesta que tengas que dar de una petición (si, estos consejos aplican para backend también).
Aplicá el método científico:
- Reproducir el problema, e identificar el componente más importante.
Si lo que estás haciendo es resolver un bug, lo primero es reproducirlo, el bugfixing es muy difícil y poco confiable si no podés reproducir el problema.
Luego toca identificar el código más relevante en el proyecto. ¿Cómo? Buscando en el código del proyecto, a partir de las palabras que veas en la UI afectada. En el caso de ser un problema de backend, podés buscar a partir del nombre del endpoint.
O más o menos, por donde creas que esté el componente/controlador.
Si no, ¿Tenés QA en el proyecto para preguntarle? Puede que ese error tenga un test que no esté bien armado, o sea algo no cubierto por tests, pero que el QA sepa por donde viene la cosa.
Pudiendo reproducir el bug y el código donde más o menos ocurre, podés empezar a entender el problema específico.
- Armar una hipótesis de cuál es el problema y que deberías hacer para resolverlo. Habiendo podido reproducir el problema y sabiendo el componente donde ocurre (puede que a fuerza de debugger y console.log), tratá de identificar porque ocurre, usando la línea temporal de GIT, o investigando la situación. Puede ser muy útil tomar notas o hacer diagramas de lo que vas viendo, para que te ayuden a entender que lo que estás viendo.
Una cosa a tener en cuenta siempre que estés haciendo funcionalidades, es que es posible que lo que estés haciendo ya fué hecho antes en el proyecto. Te recomiendo revisar componentes parecidos, buscate si lo que estás haciendo (o algo parecido) ya fué implementado. No te recomiendo copiar y pegar sin entender (eso es muy peligroso, y te va a hacer quedar mal), pero fijate como se encaró el problema en una situación parecida.
Implementar tu solución.
Probar la solución, si no funciona volver al segundo paso.
Si funciona, dejarla en condiciones, lista para aplicar en un Pull Request.
Cuando te sientas perdido, aplicar el método científico (y tomar notas) puede ser de gran ayuda, para ordenar las ideas y llegar a una solución (o al menos entender el problema).
Anticipá los Problemas, Arrancá por lo Lento:
Tratá de aprovechar el tiempo, asegurando que los supuestos sobre los que se basa tu tarea sean realmente válidos: Si el ticket dice que lo que estás haciendo depende de un endpoint del backend ya existente, probá primero el endpoint, y después te ponés a hacer la UI. ¿Por qué? Porque la comunicación entre equipos usualmente es más lenta que maquetar un div con un par de inputs y un botón, y puede que hagas tu feature en 2 horas y te pases un día esperando por un endpoint.
Por eso, Atacá lo más difícil, probá los supuestos sobre los que se maneja el ticket.
Somos pocos y... ya nos vamos a conocer
Quiero dejar claro tres cosas que creo es lo más importante a recordar y realzar de esta guía:
- PEDÍ AYUDA, NO SEAS TERCO.
Esos primeros días se espera que tengas dudas, no tengas miedo de quedar mal.
- MANEJÁ TUS EXPECTATIVAS
El proceso de onboarding es una inversión que la empresa hace en vos, ellos saben que tenés que aprender como funciona su proyecto, su código y sus prácticas, por lo que no te persigas a vos mismo por no rendir tanto como el resto del equipo, en esas primeras semanas.
- OPINÁ Y DISCUTÍ.
Con respeto y razones, obvio, pero recordá que sos un par más de ojos que pueden ver algo que puede que esté mal. Especialmente en equipos chicos, o en cosas que no tengan una suite de tests como la gente. Tus ideas valen.
- ES PREFERIBLE SOBRE-COMUNICAR, QUE SUB-COMUNICAR.
Esto es algo que vi hasta en gente con mucho seniority.
Comunicá el estado de lo que vas haciendo a tu PM, PO, o lo que sea seguido.
Si te trabas, decilo rápido. Es más rápido y eficiente que el PM, PO, o un par te tire un centro a que te trabes por un día entero.
Recordá lo siguiente: El tiempo de los programadores es el recurso más caro y preciado de una empresa. Que te trabes (después de investigar y tratar de resolver/entender algo) es más caro para la empresa a que le avises a tu PM y te tengan que explicar de nuevo un ticket o una parte del código.
Eso es todo, espero que te sirva. ¿Se te ocurren más consejos? Compartilos en un comentario acá mismo!
Te quedaste con ganas de leer más? :
Top comments (0)