Caracteristicas de los buenos programadores junior

Cuando un programador Junior entra en un equipo de trabajo ya formado, es bastante habitual que se compare a si mismo con los nuevos compañeros de trabajo que conforman el equipo de trabajo. Y también es bastante habitual que se sienta como una carga, sin apenas capacidad, y muy lejos de poder aportar valor al equipo. Eso no deja de ser una perspectiva subjetiva; todos los miembros de cualqueir equipo de trabajo han sido nuevos antes, y son conscientes de todo lo que es necesario aprender antes de poder participar de forma activa y segura.

A pesar de la falta de experiencia, existen una serie de actitudes importantes que definen a un buen programador Junior.

Hacen preguntas, y las hacen con cabeza

Puede ser intimidante, pero es un importante hacer preguntas. Cuando a un junior se le encarga una tarea, debe estar seguro de cuales son los requisitos de dicha tarea. Y para poder validar los requisitos es fundamental confirmar con el interlocutor las suposiciones que se han echo.

No se debe preguntar "¿Qué tengo que hacer?", ya que eso es el trabajo de cada persona. Lo que se debe hacer es explicar que es lo que se ha entendido, preguntar si se ha entendido todo correctamente, o si se olvida algo. Hacer este ejercicio es importante: obliga a analizar los requisitos de la tarea para poder expresarlos en forma de pregunta, y permite al interlocutor comprobar si existe algún problema en el planteamiento de los requisitos.

Las preguntas del estilo "¿Es que no entiendo esto?" tampoco deberían plantearse. Igual que el anterior punto, el trabajo de cada persona es entender los retos a los que se enfrenta. Es fundamental leer e investigar los problemas que se planteen. Cuando algo no funciona como se espera, se puede buscar ayuda para entender porque las cosas no encajan.

Cometer equivocaciones, y aprender de ellas

Lo habitual tras el primer commit que se realiza en la vida real es recibir un aluvión de críticas. Seguramente todo el código esté mal escrito, y peor estructurado. Seguramente la sensación de frustación y derrota sera importante, pero los fallos son la mejor escuela para un programador.

La experiencia de un programador junior es bastante limitada, y se centran en resolver los requisitos planteados. Es complicado analizar todas las implicaciones de un cambio en un sistema complejo teniendo poco experiencia o bagaje. En muchos casos la forma de plantear una solución pone en riesgo el mantenimiento en el futuro, y es complicado entenderlo sin haber visto antes dichos probelmas.

Es importante tener en cuenta los comentarios recividos, y aplicarlos en próximos desarrollos. Revisar los commits de gente con experiencia también es una buena ayuda para contrastar la forma de plantear soluciones.

Existe una gran diferencia entre aprender y practicar. Y justo de ese aprendizaje es de donde surje de la práctica. La documentación y los tutoriales no cuentan toda la historia, y cuando llegué el momento hay una gran cantidad de pequeños detalles que no son "relevantes", pero que aparecen en los primeros momentos. No te quedas atrapado en la teoría, hay que implementar los problemas, probar y repetir.

La clave es aprender de cada caso. No se debe cometer la equivocación de no intentarlo. Nadie espera que un programador junior haga un buen trabajo, asi que lo ideal es intentarlo con ahinco. Ofrecer una solución lo antes posible, y aprender de los errores es mejor que bloquearse y no ser capaz ni siquiera de presentar una solución que comentar. Sin embargo, una vez que se recibe una explicación sobre algo que no está bien implementado, es importante tratar de recordarlo, y tenerlo en mente para el futuro. No hay nada peor que una persona que repite una y otra vez los mismos errores

Se mantienen enfocados y productivos

Cuando alguien se une a un equipo, hay muchas cosas que aprender. El lenguaje utilizado, la arquitectura de la aplicación, las librerías y frameworks utilizados. Cuando un programador experimentado se encuentra con ese reto, es probable que anteriormente haya tenído que trabajar en proyectos similares, o con herramientas parecidas.

No es buena idea abarcarlo todo al mismo tiempo, ya que seguramente se termine fallando. Es necesario hacerlo poco a poco, escogiendo un área en la que trabajar, y dedicarle el máximo esfuerzo posible. Se debe aprender todo lo posible de dicha área hasta llegar a tener seguridad y confianza en ella. Es una tarea larga, pero con el paso del tiempo se notarán que cada vez es mayor el aporte que se hace como parte del equipo. Llegará un momento en el que se sabrá cómo resolver de manera sencilla los problemas, y cada vez habrá menos comentarios en los pull request.

Al mismo tiempo que se progresa en el cónocimiento, se mejora en la productividad. Dicha productividad es una medida que relaciona la complejidad del desarrollo realizado, y el tiempo invertido en completarlo. Es necesario que a medida que aumenta el conocimiento en alguna de la áreas de trabajo, también aumente la productividad en esa área. Siendo capaces de abarcar tareas más complejas, y ajustarse a los tiempos designados.

En esta misma línea, es importante hacer una reflexión sobre la productividad, y un problema que muchas veces afecta a los desarrolladores sin experiencia. En un proyecto es fundamental controlar los tiempos de desarrollo. Normalmente no se espera que un progrador junior sea capaz de cumplir los plazos marcados, ya que cualquier problema que surja supondrá un grave reto. Sin embargo, para el gestor del proyecto es fundamental poder controlar los tiempos del proyecto. Por lo general, en cuanto veas que una tarea se va a retrasar en el tiempo, el supervisor debe estar al tanto del previsible retraso, para que pueda hacer los ajustes necesarios.

Una señal de los programadores enfocados es la búsqueda de soluciones a los errores que aparecen. No existe mejor tutor que un error complejo, cuya traza debe ser descifrada. Va a ser muy raro encontrarse con un error que no le haya ocurrido antes a otra persona, y para el cual no exista una respuesta en internet. Es fundamental leer el mensaje de error, tratar de entender lo que está pasando; buscar en internet los motivos de dicho error. Pararse a preguntar los errores a la primera no ayuda a progresar mentalmente, siempre es interesante dedicar un buen esfuerzo a ententer por uno mismo los errores, y a buscarle la solución.

Buscan mejorar

Cuando el proyecto ha avanzado varias semanas, y ya son varias las tareas que se han cerrado, es muy probable empezar a pensar que los desarrollos hechos para las primeras tareas siguen sin estar todo lo bien que debería. Cualquier progrador (y no sólo los junior) está en un inacabable camino de búsqueda de soluciones. Siempre que terminas con una tarea te das cuenta que exitía una forma mejor de hacerlo.

Es posible que existan tareas que se cerraron con un manejador de error genérico para no hacer frente a todos los posibles casos, y que con el tiempo se entienda cual es la manera en la que hay que cambiar la estructura para hacer frente a esos errores. O espantosos bloques if / else que un par de meses despues causen estupor en los ojos....