Enhorabuena, acabas de terminar la carrera, el módulo o uno de nuestros cursos de formación de Hello, World! y has entrado a tu primer trabajo como desarrollador junior, pues aquí tienes tu manual de supervivencia para juniors. Un miembro del equipo de desarrollo te da la bienvenida al mundo real y te hace un tour por el proyecto. Te presenta a los compañeros, te ayuda a configurarte el entorno, te enseña dónde se encuentra el café y durante un par de días te mantiene bajo su ala haciéndote leer documentación o echando un vistazo a la aplicación para que te vayas familiarizando. Al poco, te asignan tu primera tarea, que en el 90% de los casos se corresponde con una incidencia poco prioritaria. Cabe recordar, que cualquiera de los miembros del proyecto tardaría menos de media hora en resolver.

Estas primeras tareas son el equivalente informático a la primera impresión, es un momento crucial en el que serás catalogado por los miembros del equipo en una de las siguientes categorías:

Ser un crack viene de serie. No hay forma de convertirte en uno leyendo un artículo en un blog, pero pasar de cualquier otra categoría a ser considerado como un chaval apañado es posible. Si nos fijamos en las descripciones de las categorías, podemos ver que la principal diferencia reside en la forma de obtener y aplicar la información que nos falta para resolver el problema.

Mientras realizas la petición que te ha sido asignada encontrarás varios momentos en los que te quedarás bloqueado y cómo gestiones estos bloqueos es crucial. Para estos casos recomiendo que sigas los siguientes tres pasos de manera secuencial, uno de ellos te dará la respuesta que necesitas.

Recopila la información

Primero y más importante, lee el log, preferiblemente completo, no sólo primera y última línea. En la mayoría de las ocasiones la respuesta al problema está ahí. Indicándote la línea concreta del código en la que se te ha olvidado poner el punto y coma, cerrar el paréntesis o en la que está saltando el NullPointerException.

Y para poder leer el log, debes saber de qué logs dispones. Según cómo sea el entorno en el que estás trabajando, puedes tener el de tu consola local en tu IDE, el del servidor de desarrollo, el de la aplicación, el de la consola del Chrome o todos los anteriores. Asegúrate de que sabes en cuántos sitios puede salir información del error y de que sabes acceder a todos ellos.

Si ninguno de los logs te ha ayudado a resolver el error, por lo menos te habrá dado algo de información para tirar del hilo. Tu siguiente gran amigo es… Google (o cualquier otro buscador).

Busca en Google la traza del error, es probable que a alguien ya le haya pasado y haya sido tan amable de publicar la solución que buscas.

Usa el debugger. No tengas miedo a bucear en el código, pon puntos de interrupción por donde pasa tu flujo y asegúrate de que se comporta como crees que hace.

 Si ni los logs ni Google ni el debugger han sido capaces de ayudarte, puede que necesites despejarte un poco.

Tómate un respiro...

A veces la solución a un problema aparece cuando dejas de buscarla. Si llevas demasiado tiempo enfocado en buscar la solución a un problema, puede que sea el momento de levantarte. Tómate un café, ve a por un Kit Kat, sal al Sol unos minutos o comenta con los compañeros sobre el combate del domingo. Cuando vuelvas a sentarte verás el problema con otros ojos y puede que la solución se haga evidente. Innumerables desarrolladores han encontrado la solución a un bug en el tren de vuelta a casa.

Si a la vuelta del descanso ves que sigues atascado en el mismo punto es hora de que saques al pato a pasear.

Cuéntaselo al pato

A esta técnica se le conoce como “rubber ducking”. Es una técnica extremadamente simple y efectiva para encontrar soluciones a problemas. Consiste en explicarle tu problema a un patito de goma, puede valer cualquier otro tipo de juguete o cosa que tengas a mano.

El simple acto de explicar el problema paso a paso, verbalizar la solución, hace que emerjan posibles soluciones que no habías encontrado previamente. En más de una ocasión, explicando el problema a un compañero más senior he encontrado la solución y he salido corriendo sin decir ni adiós.

Aprovecho este artículo para pedir perdón a todos esos compañeros con los que he hecho rubberducking humano.

Bromas aparte, si ni verbalizando el problema has encontrado la solución, al menos ha allanado el camino para dar el siguiente paso. Pregunta a alguien más sabio.

Pregunta a alguien más sabio

Si nada de lo anterior ha funcionado, es hora de preguntar a alguien que tenga más conocimiento. Si has seguido los pasos anteriores, les presentarás un problema que no es resoluble directamente con el log, y que no te podrán contestar con un https://gprivate.com/5ycbl

Y lo que es más importante, al haberle explicado previamente el problema al pato, se lo podrás explicar de una manera ordenada, notándose que entiendes el problema y que te has esforzado en solucionarlo.

Como nadie espera que saques las tareas sin preguntar, te recibirán con los brazos abiertos para explicarte lo que necesites o para mostrarte la solución al bloqueo que te has encontrado. Ante esta explicación hay que tener dos cosas en cuenta.

La primera, no mientas, si no has entendido la explicación no pasa nada, di que no lo has entendido, nadie te pondrá pegas en explicarte lo mismo de mil formas distintas, pero no digas que lo has entendido y vuelvas a la semana siguiente con lo mismo.

La segunda, apúntate lo que necesites para no tener que volver a hacer la misma pregunta, nadie te pondrá pegas a explicarte mil cosas distintas, pero no les hagas contarte lo mismo todas las semanas. Eres informático, pero unos analógicos papel y boli serán tus mejores amigos.

And that’s all folks

Recuerda que tu compañero super experimentado también tuvo su primer día de trabajo en el que estaba más perdido que un pulpo en un garaje. Todos hemos pasado por ahí, de hecho, por muchos años de experiencia que tengas, siempre vas a encontrarte problemas, será menos probable que tengas que llegar hasta el paso de “Preguntar a alguien más sabio”, pero tendrás que seguir el mismo flujo.

Ser un buen junior consiste en querer aprender, echarle ganas y no tener miedo ni a investigar un problema ni a preguntar a tus compañeros, y encontrar el equilibrio entre ambos.

Referencias

The Pragmatic Programmer, 20th Anniversary Edition, David Thomas and Andrew Hunt, 2019, Addison Wesley, ISBN 978-0135957059.