Aprendiendo, distintas maneras de aprender

Me considero una persona curiosa, me gusta aprender nuevas herramientas, nuevos métodos de trabajo, conocer frameworks, patrones,… parece sencillo. En Internet hay cantidad de información sólo tenemos que navegar y consumir. Pero no es tan fácil, es tal la cantidad de información que es muy difícil

mantener encontrar buenos recursos, mantener el foco y sacarle provecho al material. Vamos a intentar revisar los distintos métodos que hay para aprender sobre un framework, librería, una metodología…

 

Video Cursos

Son geniales, en Youtube hay muchos gratuitos como JustForFunc en Go, también hay plataformas con cursos como Udemy, openwebinars, geekshubsacademy,… desde la perspectiva del productor del video, es la manera más «escalable» de enseñar. Solo poner online el material listo. Pero el productor también pierde algo muy valioso: el feedeback de los alumnos, conocer si algo no queda claro para explicarlo mejor o poder hacer nuevos cursos con ese feedback es algo muy provechoso.

Desde el punto de vista de los que consumimos, los videos son geniales podemos verlos cuando queramos, volver a ver trozos que no quedan claros o saltarnos partes, pero tenemos algo muy en contra: perder el foco. Si el curso es muy largo es fácil que dejemos de verlo, tener constancia para reservarnos parte de la semana a ver videos y que el día a día no nos «agote» ese tiempo es complicado.

Trainings / Workshop / Cursos presenciales

Son la mejor manera de aprender temas complejos. Si queremos conocer a fondo una herramienta, una metodología un workshop puede ser una gran idea. En uno o dos días alguien que conoce mucho esa herramienta nos da un curso intensivo.

Como profesor tienes feedback constante, puedes aclarar dudas, mejorar las presentaciones, pulir el enfoque de algunas partes…

Como alumno tiene su parte buena y su parte mala. La buena es que tienes un experto al que preguntar todas tus dudas, hay otros alumnos con otros puntos de vistaque seguramente preguntarán dudas que ni se te han pasado por la cabeza. Pero por contra, es muy agotador. Dos días de workshop condensan mucha información y asimilarla toda es complicado.

Pairing / Mobbing

Haciendo pairing cuando nos encontramos problemas complicados estamos incrementando el conocimiento en dominios específicos y lo que es mejor, estamos disminuyendo el bus factor. Aplicar pairing no es sencillo, por un lado es agotador si lo hacemos durante toda la jornada, aunque es cierto que hacer pomodoros ayuda mucho a la hora de tomarnos un respiro. Es un proceso agotador. Por otro lado no siempre es productivo estar haciendo pairing, hay cambios o funcionalidades sencillas en las que hacer pairing no aporta un valor a la funcionalidad en sí.

Otra de las mejorar que aporta hacer pairing/mobbing, es que podemos resolver problemas pendientes conjuntamente. De esta manera somos capaces de ilustrar los beneficios y los inconvenientes de cada decisión que tomamos cuando vamos camino de la solución. Así reforzaremos entre otras cosas la propiedad colectiva del código y el conocimiento sobre el dominio del problema.

Como hemos dicho antes no siempre tiene sentido hacer pairing, para mí tiene sentido hacer pairing:

• Refactorinzando: hacer pairinng cuando refactorizamos en valioso ya que por un lado no perdemos el foco en que queremos hacer y hasta donde queremos llegar. Es decir somos capaces de encontrar ese punto de equilibrio tan complicado en el refactoring. Cuando estamos refactorizando tenemos que saber cuando seguir y lo más importante cuando parar. De la misma forma es mucho más sencillo nombrar métodos y variables entre 2 personas que una sola.
• Cuando estamos testeando/modificando legacy code: que tengamos cerca a algún compañero cuando estamos tocando código legacy es por un lado una tranquilidad de que cuatro ojos ven más que dos y por otro lado una ayuda para comprender partes del código complicadas.
• Performance o haciendo los test más rápidos: en el momento es el que necesitamos hacer el código más rápido es necesario que busquemos el consenso de hacia donde queremos ir: más niveles de caché, caché más grandes, minimizar el tiempo en caché, aumentar el tiempo, mejorar los algoritmos,… hacer pairing para que tomemos estás decisiones nos ayuda a que nuestro código no se vuelva inmanejable y que lleguemos a un punto de equilibrio. Ya sea eliminando test redundantes, haciendo setups menos pesados, usando funciones de PHP,…

Code Reviews continuas

Revisar el código de todo el mundo antes de subirlo es bajo mi punto de vista una de las maneras de que todos mejoremos, ya que hace que programadores experimentados lean código de otros y aporten un feedback que puede ser muy valioso. Además hacemos que el código sea de todos, de que todos tengamos claro como trabajamos y que las soluciones que damos a los problemas que se nos plantean estén más consensuadas. A mí me ha pasado en más de una code review que un compañero me diga: «¿no crees que esto sería mejor hacerlo con esta función?» y yo quedarme pensando «Toda la razón. Esa solución es 1000 veces mejor. Que bueno que se le haya ocurrido».

Aunque es cierto que debemos tener en cuenta que las code reviews no van a cazar bugs, ni mucho menos, las code reviews sirven para mejorar el código que sube a producción. No me enrollo más que ya escribí un post sobre cómo llevar a cabo una code review y qué puntos tener en cuenta

Spikes

Los spikes son tareas de un Sprint que no aportan necesariamente un incremento de producto, sino que sirven para «investigar» sobre librerías, frameworks, metodologías,.. en definitiva, los spikes sirven para aumentar nuestro conocimiento sobre el dominio del problema para aportar mejores soluciones.

Creo que esta es una de las maneras de aprender en las que tenemos que tener más confianza porque requiere humildad por parte de los desarrolladores para que digamos, no tengo ni idea de como afrontar, o si tengo idea pero creo que investigando un poco podría aportar mucho más porque he visto tal framework, o cual librería que podría sernos útil. Y del mismo modo requiere que el product owner confíe en el equipo sabiendo que se vamos a invertir tiempo en una prueba de concepto de algo que puede que al final no nos sea tan útil como esperábamos.

Meetups / charlas técnicas / grupos de trabajo

Los meetups son grupos de personas que se reúnen por algún interés compartido, ya sea programar, aprender inglés, agile,… creo que son una buena manera de aprender, de estar al día y sobre todo de conocer gente que tiene intereses parecidos a los tuyos. Además, en mi opinión, lo mejor del meetup son las reuniones de después, es decir, el poder escuchar, hablar, discutir, y conocer gente que tiene inquietud por mejorar es muy valioso. Aunque sea sobre el último rant que ha aparecido en Twitter 😉

Resumen

Cuando queremos aprender sobre algo en particular, habitualmente pensamos en libros o en cursos pero creo que hay formas más eficientes de que aprendamos. Y no solo por el hecho de conocer el último framework de moda, sino por el hecho de que nos porque ese gusanillo que nos hace mejorar, que nos hace ser un poco mejores profesionales y sentirnos realizados con nosotros mismos.