2011, Un año de libros

Published on Friday, 30 December 2011

Un año intenso

2011 ha sido un año intenso y productivo. Un año de crecimiento y superación, tanto en lo personal como en lo profesional. Y también un año de esfuerzo y estudio continuo, estudio que me ha llevado en 12 meses a saber mucho más, y a saber que sé mucho menos.

Porque, paradógicamente, cada vez que lees un libro y absorbes su contenido se dibujan ante tí nuevos horizontes, nuevos campos del conocimiento que no conocías, y a cada nuevo material que digieres te sientes más perdido en este mar de cosas por aprender en el que vivimos.

Quería cerrar el año echando la vista atrás y haciendo un repaso a mi trayectoria durante este año, con sus logros y fracasos, y no se me ocurre mejor manera de hacerlo que a través de los libros que me han acompañado estos doce meses.

El detonante

Siempre he disfrutado de la lectura. Me encanta la ciencia ficción pero también devoro a otros autores de novela como el difunto Xosé Saramago, Haruki Murakami y algunos clásicos como Víctor Hugo. Pero aunque sentía esa llamita perfeccionista en mi trabajo, nunca me había atrevido a sumergirme a fondo en los libros técnicos quizá por miedo al inglés. Pero algo había cambiado, una firme determinación de dar un salto cualitativo como profesional, e iba a poner todo mi empeño en ello.

Pasé los días anteriores y posteriores a la Nochevieja del año pasado enfrascado en la lectura de The Passionate Programmer. Este libro avivó aún más esta voluntad de expandirme como profesional. Su visión pragmática sobre el desarrollo personal y en el trabajo, alejada de romanticismos, conectó conmigo desde sus primeras páginas. Creo que ha sido el segundo libro en lengua inglesa leído de cabo a rabo, y empezaba a perder el miedo y a leer con mayor fluidez. El anterior había sido The Productive Programmer y posteriormente me haría con The Pragmatic Programmer. Son tres libros imprescindibles para todos los que se dedican a esta profesión.

Calidad e Integración Continua

Al empezar el nuevo año se me encargó una tarea importante; establecer metodologías para mejorar los procesos en el departamento, crear una figura de QA y aumentar la calidad del software que producíamos. El objetivo era mejorar nuestro ratio de bugs y organizar un departamento un tanto anárquico.

Una de las cosas que se hacen bien en Aureka Internet es poner a disposición de los empleados una biblioteca. Quien quiera puede pedir un libro, se encarga en Amazon o en otras tiendas, y lo tienes en la estantería en una o dos semanas. Como me faltaban muchos, muchos conocimientos sobre el tema para poder abordar con garantías la misión pedí unos cuantos libros para empezar a formarme.

El primero que abordé fue Continuous Integration. Me enganchó. Aprovechaba cualquier momento libre para leerlo. Los sábados me lo llevaba conmigo a desayunar al bar. Por las noches en el paseo al perro, me sentaba en un banco bajo una farola a estudiar sus capítulos mientras Deckard olisqueaba los arbustos. Creo que si ha habido un libro determinante en la mejora del departamento, este ocupa la primera posición.

Como nuevo responsable de QA empecé a inspeccionar todo el código que generábamos. Provengo de una cultura Pythonística y tengo fuertes convicciones sobre la importancia de la claridad del código, y me pareció que todos teníamos mucho que mejorar. Pero me faltaban unas líneas maestras, unos fundamentos teóricos de los que entonces carecía. Por ello me llevé Clean Code a casa, una auténtica maravilla escrita. En Clean Code, Robert C. Martin despliega un estilo de programación muy cercano a la artesanía, y su visión preclara resulta una fuente inmejorable para mejorar nuestra propia codificación.

No debía estar haciéndolo mal en QA y por aquel entonces me ascendieron a coordinador del departamento. Elegí a quien considero el mejor desarrollador del equipo como apoyo en QA o, para ser más precisos, tras un sondeo a todo el equipo se ofreció él mismo. Me pareció natural. En poco tiempo me di cuenta de que él era mucho más metódico, más paciente y más inquisitivo inspeccionando código y probando funcionalidades que yo. Y me alegré muchísimo de ello, porque podía delegar muchas funciones para centrarme en otros puntos de mejora en el departamento. La calidad estaba en buenas manos.

Agilismo

Hacía ya varios meses que veníamos aplicando Scrum. Algunos compañeros habían acudido a un curso y todos nos habíamos volcado con esta metodología. Yo no sabía nada sobre metodologías ágiles, más que lo que me transmitían los compañeros. Pero teníamos muchos problemas para terminar los sprints y había algunos aspectos de la estimación y planificación que no me cuadraban. Pedí a la empresa unos cuantos libros más y seguí leyendo.

Agile Coaching es un buen libro introductorio. No solo en sus explicaciones sobre Scrum, también porque explica algunos fundamentos de psicología de grupos y ofrece algunos consejos bastante interesantes. Pero me quedé con ganas de más, y me lo ofreció Mike Cohn.

Agile Estimating and Plannning explica con todo lujo de detalles cómo introducir Scrum en un equipo, cómo estimar, cómo planificar un proyecto y un sprint, y despliega todo un trasfondo sobre cómo salir al paso a las muchas dificultades que un equipo puede enfrentarse en su camino a través de Scrum.

Tras la lectura del libro de Mike Cohn empecé una revisión casi completa de la manera en la que estábamos aplicando la metodología. Introduje algunas prácticas nuevas como las reuniones retrospectivas e intenté modificar la manera en la que estimábamos y definíamos las user stories. El agilismo es una cuestión de equipo e inculcar estos cambios me ha resultado particularmente difícil. Algunas cosas siguen sin funcionar y aún queda mucho por aprender y experimentar.

Otro libro sobre Scrum es Scrum and XP From The Trenches. Es muy finito y se lee en menos de un fin de semana, y presenta una visión muy directa y aplicada de la metodología. He de reconocer que no estuve de acuerdo con algunas reflexiones del autor, pero no descarto que en futuras relecturas haya cambiado mi punto de vista.

Por aquél entonces, los dueños de perros en el barrio comenzaban a llamarme "el chico que lee".

Gestión de equipos

Tanto en el papel de QA como en el de coordinador, mis mayores dificultades han tenido mucho que ver con los aspectos humanos del trabajo en equipo. Mi falta de experiencia y un carácter en ocasiones obtuso e impulsivo me han llevado a cometer muchos, muchísimos errores y a volver a casa con muchísimos disgustos.

Ejerciendo de psicólogo paciente, mi compañero de profesión y amigo Alessandro me prestó Managing Humans, un libro muy recomendable para todos los que se encuentran con problemas como los que describo.

Descanso necesario

Debíamos estar a principios de Noviembre cuando me sequé y se me fueron las ganas de leer. Había sacrificado mucho tiempo libre y no daba para más. No dejé de leer blogs de manera ocasional, pero me tomé unas semanas en las que dediqué mi tiempo libre a cultivar el huerto, pasear tranquilamente y empezar alguna novela.

En el trabajo estábamos avanzando en una release importante sobre nuestro proyecto principal. Esta release implicaba tocar mucho, muchísimo código viejo. Una cosa llevó a la otra y terminé llevándome a casa Working Effectively With Legacy Code. Es un libro denso, repleto de ejemplos de código, y lo estoy leyendo con calma y saboreando a pequeños sorbitos. Quiero sedimentar bien sus conceptos porque, como Clean Code, este es un libro de primera línea. Y poco a poco voy recuperando aliento.

Conclusiones

A mediados de este mes desplegamos la nueva release. Era el cambio más importante que habíamos hecho en la web desde sus inicios, y para mí suponía un hito especialmente importante. Porque el éxito o fracaso de ese despliegue reflejaría los frutos de nuestros esfuerzos colectivos. Y también de mi esfuerzo individual.

El despliegue tuvo sus problemas. Urgencias de última hora y errores que sólo ocurren en el servidor. La web empeoró su rendimiento y tuvimos que dedicar parte de nuestros recursos a mejorar los tiempos de carga. Pero por primera vez restaurábamos el servicio antes de lo previsto en el deploy. Y aunque surgieron muchos pequeños bugs y alguno grande, por primera vez también recibimos muchas felicitaciones de los usuarios desde el primer día. El cambio gustó, el cambió funcionó, y a la semana siguiente más de la mitad del equipo estaba de vacaciones. La noche posterior al despliegue abrí una botella de vino, me tomé más de la mitad de su contenido y pillé un pedo yo solo bien merecido.

Creo que esta es la historia de un éxito. Un éxito que es de todo el equipo, pero del que, sin avergonzarme, me considero elemento catalizador. A ellos les debo el haberme escuchado y el haberse esforzado, día a día, por aplicar las enseñanzas que los maestros nos transmiten a través de los libros.

Al final me he dado cuenta de que sin saberlo he seguido un plan de estudios. Con becas pagadas en una empresa donde he tenido la inmensa suerte de que me dieran libertad y confianza para tomar todas las decisiones que considerase oportunas. Cuando hablamos de profesiones que necesitan formación contínua siempre nos viene a la cabeza la medicina. Pero nosotros, los que trabajamos en el entorno tecnológico, tenemos tanta necesidad o más de actualizar nuestros conocimientos que los médicos. Porque hemos decidido dedicarnos a esto, nos lo debemos y se lo debemos al mundo.

¿Y en 2012?

2012 viene cargado de nuevos desafíos. No sé lo que ocurrirá en el departamento. Seguramente el equipo se divida en pequeños equipos. Empezaremos nuevas pequeñas criaturitas que nos harán sumergirnos en nuevas teconologías, y habrá mucho que descubrir, mucho que aprender y mucho que equivocarse.

Me gustaría que QA fuera disipándose gradualmente. Esta idea ha estado siempre en mi cabeza desde los inicios, pero hasta ahora no he encontrado el momento de empezar a desactivar este Gran Hermano. Creo que siempre será necesaria una figura que vigile la calidad de los proyectos, pero hay que empezar a delegar la mayor parte de esta pesada carga en todo el equipo. Quizá un día, con una perspectiva más completa, escriba un post sobre ello.

Seguiré estudiando, claro. Empiezo a recuperar las ganas de engancharme al expreso del conocimiento. Necesito aprender mucho sobre programación orientada a objetos y patrones de diseño. También quiero profundizar en mis conocimientos de Scrum. Estudiar otras metodologías. Releer algunas obras maestras que he leído este año, ahora ya con más experiencia.

Espero dentro de 12 meses escribir un post titulado "2012: Un año de libros".