Agile

Imagen de http://www.harringtonstarr.com/agile-methodology-best-option-software-delivery/

Todo el mundo habla de Agile, scrum, Kanban, XP o de ser más agile. Pero, ¿qué es agile?

Agile comenzó cuando 17 personas se juntaron en Utah en el 2001 y crearon el manifiesto agile.

Personalmente, agile es una filosofía y una forma de ver las cosas. Solo hay que comprobar que el manifiesto contiene también 12 principios. Esos principios me gustan más que el manifiesto.
Por ejemplo, el primer principio que es muy bueno y dice: "nuestra prioridad número uno es satisfacer al cliente con frecuentes entregas de software que aporta valor".

Además agile es una forma de solucionar varios problemas que tenemos en el desarrollo de software. Los principales problemas que intenta solucionar son los siguientes:

Los requisitos cambian

Porque el cliente no tiene claro lo que quiere, porque no hemos entendido lo que quiere, porque ha surgido una nueva funcionalidad que puede ayudar al cliente más que los requisitos actuales, porque ha surgido una nueva funcionalidad que es necesarias para poder dar valor a las demás. Seguramente que puedas sacar más porqués por tu cuenta, pero lo que está claro es que cambian.

El coste se va de las manos

Y el coste se va porque no somos buenos estimando proyectos, porque nos confundimos en el desarrollo, diseño o toma de requisitos, porque añadimos mayor complejidad a nuestros diseños o código lo que hace que vayamos avanzando más lentamente, porque nos encontramos problemas que no conocíamos o que conocíamos pero que no hicimos nada al espectro o que aún conociéndolos y haciendo algo al respecto nos hizo perder mucho más tiempo de lo esperado, porque dejo la empresa gente que trabajaba en el proyecto, porque gente del proyecto es movida a otro proyecto con mayor importancia para la empresa.

El valor obtenido es muy pequeño

Este problema es una combinación de otros problemas. Como por ejemplo, de los dos primeros ya que si los requisitos cambian pero no hacemos nada al respecto el cliente obtendrá menos valor y además si el coste aumenta mucho quizás el valor que le hemos dado no compense.

En resumen, agile es una filosofía que ayuda a resolver los principales problemas que tenemos en el desarrollo de software.

Codemotion 2016

Imagen de Codemotion https://2016.codemotion.es/

He podido asistir este año a un gran evento a nivel nacional como es Codemotion.

Estoy muy contento de haber podido asistir ya que nunca había participado en nada parecido (no con este tamaño y de varios días). Además, me acercó a uno de mis objetivos para el 2016.
Como decía, ha sido mi primer año en Codemotion y tengo que decir que ha estado muy bien. Se nota que es una de las citas obligatorias a nivel nacional.

Como regla general, asistí a las charlas de las personas a las que conocía virtualmente y fue un acierto porque a todas las charlas que fui conociendo el speaker me gustaron.

Para el próximo año tengo que ir preparado para los workshops. Había muchos interesantes pero sin tener nada preparado no tenía mucho sentido el asistir.

En este artículo me voy a enfocar en las charlas a las que fui y que más me gustaron, pero antes, me gustaría dar las gracias a los organizadores porque organizar un evento de más de mil personas, a un precio muy asequible (pagué alrededor de 130 euros) y hacerlo con ponentes de calidad debe de ser un trabajo de titanes. GRACIAS.

Las siguientes apartados contienen información de las tres charlas que más me han gustado.

Agustín Cuenca - Cacahuetes y monos digitales o sobre como sobrevivir a las 6Ds

Esta fue la primera charla a la que asistí, después de la keynote, y fue un gran acierto.
Agustín habló del porqué de los sueldos bajos de los programadores en España y de las 6Ds.
Me gustó mucho porque es muy bueno comunicando y porque lo que contó me hizo pensar sobre el futuro del desarrollo del software.
Uno de sus hilos argumentativos fue que en un futuro los programadores no seremos necesarios. Esta parte fue la que me hizo pensar.

La pena de esta charla es que no fue grabada, pero tenemos las slides en el siguiente enlace:

http://www.slideshare.net/agustincnc/codemotion-2016-cacahuetes-y-monos-digitales

Mark Heckler - Living on the Edge (Service): Bundling Microservices to Optimize for Devices

Mark no hablaba español. Así que la charla fue en inglés.

El tema tratado tuvo poco que ver con el título. Una pequeña introducción de microservicios poniendo como ejemplo Netflix y después lo que hizo fue el crear aplicaciones con spring boot desde cero que formaban un ecosistema de microservicios.

Lo que me gustó de la charla fue la cantidad de componentes que están integrados en spring y que te permiten crear microservicios en poco tiempo.

Su charla si que fue grabada y está en el siguiente enlace:

Roberto Canales - Intraemprendimiento para frikis

Había visto varias charlas Roberto que me gustaron mucho debido a su forma tan simple de explicar. En este caso la charla fue de como Autentia, la empresa en la que es CEO y da servicios informáticos a empresas, están creando sus propios productos y cuál es el camino que están recorriendo.
A quien no le gusta escuchar de los errores de los demás :)

La charla también fue grabada:

Más charlas

Si quieres más, muchas de las charlas fueron grabadas y las podrás encontrar en la página de Codemotion:

https://2016.codemotion.es/agenda.html#5732408326356992


Toda charla que tenga un icono con forma de botón de play y de fondo azul es que fue grabada. Para acceder al vídeo, tienes que acceder a la ficha y pulsar el icono que te comento.

Resumen

El siguiente tweet es un buen resumen de Codemotion:

Me ha gustado mucho el evento. Mucha gente pero muy chulo. Seguro que el próximo año vuelvo #Codemotion2016

— Enrique Martín (@kikers25) November 19, 2016

* Modificado 02-12-2016: Solucionado algunos errores ortográficos

Ventajas de Spock para testear en Java

Imagen de http://www.playbuzz.com/jamesk20/leonard-nimoy-versus-spock-can-you-tell-which-quotes-are-from-his-famous-star-trek-character

Introducción 

Groovy es un lenguaje de programación dinámico para la máquina virtual de Java (JVM). Esto hace que sea muy fácil de configurar para alguien con experiencia en Java.
Lo que más destaca de este lenguaje es su sintaxis (syntax sugar) que facilita mucho el desarrollo. Y además es muy fácil comenzar a programar porque lo han hecho muy amigable para la gente que viene de Java. Es casi un superconjunto de Java.

Dentro del extenso ecosistema de Groovy tenemos Spock, que es una framework para escribir test. Spock tiene como ventaja principal la legibilidad de los test. Hace que los test sean muy fácil de entender sin ni siquiera saber nada de Spock o Groovy.
Lo más interesante de Groovy y Spock para alguien que viene de Java es que podemos tener nuestro código fuente en Java y los test en Spock.

Ventajas de Spock

En este apartado se listan los que son a mi entender las mayores ventajas de Spock frente a Java.
En cada apartado hay un ejemplo de como es el código en Spock y en Java para que puedas comprobar de la forma más clara posible la diferencia entre uno y otro. En la parte izquierda de las imágenes aparece el código con groovy y spock y a la derecha el código con java y junit.
Para los ejemplos de java se ha utilizado JUnit, hamcrest y mockito.

Los ejemplos en Groovy fueron creados por Iván López y los escritos en Java están escritos por mí. En el siguiente repositorio puedes encontrar el código fuente:

https://github.com/kikers25/codemotion-2015-spock

El repositorio lo escribió Iván para una charla sobre Spock y lo he extendido añadiendo los test que aparecen pero en Java porque me parecía que es más fácil ver las ventajas si se ven los dos juntos.

• Nombre de los test unitarios son cadenas

Los nombres de los test unitarios son importantes para entender que es lo que hace el código del test. En Java, el nombre del test es el nombre del método y no se pueden escribir espacios. Por lo que se tiene que utilizar algún tipo de método para que el lector sepa que hay un espacio. En mi caso suelo utilizar guiones bajos.
Con Spock esto no es necesario porque el nombre del test es una cadena. Así, podemos escribir espacios y otros caracteres que no son posible de utilizar en Java.

• Estructura de cada test en bloques

La separación en bloques de los test escritos en Spock es lo que hace que la legibilidad del test mejore mucho.
Los bloques están basados en el lenguaje gherkin y los bloques más comunes (aunque hay más) que se utilizan en un test son given, when y then. Estos bloques inicializan los objetos a utilizar (given), ejecutan la acción a probar (when) y comprueban que el resultado es el esperado (then).

• Inicialización de clases, listas y mapas

La inicializacion de objetos en groovy es de lo más fácil porque no necesitamos el crear un constructor con todos los métodos, si no que por defecto tiene un constructor al que puedes pasarle en modo de clave y valor todos los atributos que quieres inicializar del objeto. Personalmente utilizo mucho el patrón constructor (builder pattern) para crear objetos para mis tests. Con groovy no es necesario.
Además crear listas y mapas es muy intuitivo y fácil de leer.

• Tablas de datos

Con diferencia esta es una de las mejores características de Spock. Añadir test que hacen lo mismo pero con diferentes valores para los parámetros de entrada y el valor de salida utilizando una tabla de datos es una gran funcionalidad. Fíjate en las diferencias en la imagen de abajo.

• Herramienta de dobles de test completamente integrada

Utilizo jmock y mockito para crear mis dobles de pruebas para mis test. Con Spock no necesitas el buscar ninguna librería ya que viene integrada. Lo único que no me gusta es que para que una clase mockeada devuelva un valor no es necesario especificarlo a la clase. Lo que es lo mismo el framework es lenient por defecto.

• Mensajes de error cuando un test falla

Los mensajes de error son más claro que utilizando hamcrest.

Resumen

Groovy en combinación con Spock tienen muchas ventajas a la hora de escribir test si lo comparamos con Junit, Hamcrest y Mockito.
La configuración es muy fácil, resulta fácil el empezar a programar y la legibilidad de los test es muy buena. Es el framework para testing más completo que conozco.

Extra

Si te parece interesante tanto Groovy como Spock y quieres saber más. Los enlaces que aparecen a continuación son vídeos de las charlas de Iván López y Andrés Viedma sobre Spock:

https://www.youtube.com/watch?v=RjH1bd9D2Qs 
https://www.youtube.com/watch?v=D7TjLThg95I

Método iterativo e incremental

Imagen de Henrik Kniberg

Tu empresa ha externalizado la creación de una aplicación a una empresa en India y a los cuatro meses de la fecha límite entregan una primera versión.
En esa primera versión te das cuenta que tiene bastantes problemas. Como por ejemplo:

• Los requisitos mínimos no han sido cumplidos.
• La interfaz de usuario tenía que ser igual a otra aplicación, ya que los usuarios están acostumbrados a esta primera, y no se parece nada.
• La aplicación no funciona con el número mínimo de usuarios concurrentes que va a tener.
• Las funcionalidades desarrolladas hacen lo que tiene que hacer, a veces.
• El código no tiene un mínimo de calidad

Como puedes imaginar, no vas a poder arreglar todos los problemas en solo cuatro meses y los costes en cuanto a tiempo y dinero aumentan con cada mes que no ha entregado el producto, y serán muchos meses.
Además, la gente de negocio tiene que hablar con los clientes sobre estos cambios, ya que no van a estar terminados en la fecha prometida. Lo que bajará la confianza de los clientes en la empresa.
Lo mismo pasa con la gente de marketing y la campaña que tenían pensada hacer para captar nuevos clientes, que tendrán que ser pospuestas. Con el coste adicional que supondrá este cambio.

La forma de desarrollar este producto es en cascada (waterfall) ya que todos los requisitos han sido dados al principios del desarrollo y el producto se entrega cerca de la fecha de entrega.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles

La forma de desarrollar un producto en cascada es la más eficiente porque si los requisitos han quedado claros y no hay problemas durante el desarrollo del producto se han gastado cada céntimo en las cosas necesarias para obtener el producto.
El problema es que en los 10 años que llevo desarrollando software siempre hay "problemas". Puede ser que sea casualidad o que los problemas no son tal, si no un es algo habitual en el desarrollo de software. Personalmente me decanto por el segundo motivo.

Hay varias alternativas a este tipo de desarrollos en cascada pero voy a hablar del que conozco. Del desarrollo iterativo e incremental.

El desarrollo iterativo e incremental consiste en ir entregando versiones de tu producto que vayan entregando cada vez más valor con cada versión del producto.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles

La ventaja de esta forma de desarrollar un producto es que si hay algo mal, como la lista que he comentado al principio, tenemos tiempo suficiente para poder solucionarlo. O lo que es lo mismo, estamos reduciendo el riesgo que es el entregar un producto al final del desarrollo sin saber si está bien.

Claro que esta forma de desarrollo tiene sus inconvenientes. El más importante es el tiempo que hay que dedicarle a verificar que vamos por el buen camino. El tiempo que dedicamos a hablar con el cliente o con la gente de negocio para comprobar que lo que estamos desarrollando encaja con lo que tenían pensado.
Otro inconveniente importante es que la forma de desarrollar cambia de forma drástica. En cada nueva versión de nuestro producto tenemos que comprobar que las nuevas funcionalidades funcionan de la forma correcta y que las funcionalidades desarrolladas en las versiones anteriores siguen funcionan. Así, con cada nueva versión que se acerca más al producto tenemos que probar muchas cosas: las funcionalidades nuevas y las antiguas.
Como puedes imaginarte llega un momento que este proceso de comprobar que todo lo desarrollo funciona de forma correcta no se puede realizar de forma manual. De forma manual quiero decir de una persona que compruebe un todo funciona.
Por lo que necesitamos algún tipo de proceso automático que nos permita comprobar que lo que hemos desarrollo funciona. Aquí es donde entra en juego los test unitarios, los test de integración y los test de aceptación.
Los test unitarios y de integración comprueban que la aplicación funciona como debe funcionar y los test de aceptación comprueba que la aplicación funciona como el usuario final quiere.

Los cambios de un proceso en cascada a un proceso iterativo e incremental son grandes. Tanto a nivel de negocio como a nivel de desarrollo. La gente de negocio tiene que ayudar a comprobar que lo que que el usuario quiere es lo que se está desarrollando (test de aceptación) y la gente de desarrollo tiene que crear test de integración y unitarios para comprobar que lo que se está creando funciona de forma correcta.
Estos cambios son grandes pero van a permitir a vuestra empresa a reducir los riesgos. Lo que va a permitir a vuestra empresa crecer reduciendo los riesgos en este crecimiento.

Personalmente las ventajas ganan a los inconvenientes en un proceso iterativo e incremental. ¿Tú qué opinas?

Pequeño ejemplo en Python y TDD

Imagen de http://code.tutsplus.com/tutorials/beginning-test-driven-development-in-python--net-30137

Hace un tiempo leí el libro Test-Driven Development by Example de Ken Beck y me pareció un gran libro. Es una gran introducción a TDD.

Una parte del libro no entendí bien. La relacionada con un ejemplo de xUnit.
En esa parte del libro, implementa una librería para poder testear código y el ejemplo que va desarrollando está escrito en Python y no conocía el lenguaje. Creo que el lenguaje fuera Python hizo que no lo entendiera.

Así que para poder entenderlo y aprender un poco Python he escrito el código resultado de cada capítulo en un fichero mientras iba leyendo el libro. He subido los ficheros a:

https://github.com/kikers25/tddByExamplePython

Se puede comparar un fichero (con Winmerge) con otro para ver cual han sido los cambios en cada capítulo. Por ejemplo, los cambios entre el capítulos 18 y 19 serían:

Python

Espero que te resulte útil.

Mi camino aprendiendo inglés

Imagen de http://www.cleverlearncebu.com/the-importance-of-learning-english/

Siempre me resultó fácil el aprobar asignaturas en el instituto. Solo tenía que estudiar durante unos pocos días y ya era suficiente.
Eso me pasaba con casi todas las asignaturas. El inglés se me resistía. Si parte de la nota dependía de hablar o de escuchar en inglés tenía serios problemas para pasar de curso.

Creo que fue en el instituto cuando empezó mi odio (si, he dicho odio) al inglés. Pero como no iba a odiar algo en el que tenía que esforzarme muchísimo para poder sacar un aprobado raspado, que me hacía sudar y pasarlo mal y que me dejaba en ridículo delante de mis compañeros cuando intentaba hablar.

El problema era mayor por mis complejos a la hora de hablar. Este complejo empezó cuando era pequeño al no poder pronunciar la letra r. Por ejemplo, mi nombre lo pronunciaba Enlique en vez de Enrique. Si no me sentía cómodo al hablar en mi propia lengua, imagínate en otra.

Cuando terminé el instituto estaba muy contento de que no iba a tener ninguna asignatura relacionada con el inglés. Sabía que el inglés era importante en mi carrera profesional ya que soy informático y el inglés es la lengua común para todos los informáticos pero no me importaba. El odio que lo tenía podía más que mi carrera.

Durante mis primeros años trabajando me di cuenta que no tenía odio al inglés. Sino que lo que tenía era miedo. Un miedo inmenso y sin sentido. Miedo al hablar, miedo al escuchar y también al escribir y leer en inglés.

Estando trabajando en Madrid, me surgió la oportunidad de vivir en Holanda. Le di muchas vueltas. Creía que era una oportunidad que no se me iba a presentar una segunda vez, que si la dejaba escapar no volvería. También sabía que iba a ser muy duro. Al final tomé la decisión de ir a vivir a Holanda.

La primera impresión que tuve en Holanda fue de total inutilidad. Toda la gente a mi alrededor hablaba en inglés y holandés y algunos también en español. Si ellos eran capaces de hablar tantos idiomas y yo no, el problema debía de ser yo. Posteriormente vi que había otros factores por lo que los holandeses eran capaz de hablar de forma tan correcta en Inglés.

Al poco tiempo de estar allí hice varias entrevistas debido a mi experiencia y a la gran demanda de programadores. Pero debido a mis nulas capacidades de comunicarme no me cogieron en ninguna. Recuerdo lo mal que lo pasaba intentado comunicarme en inglés al teléfono con los recruiters que me llamaban.

Conseguí trabajo en una pequeña startup gracias a que su presupuesto no les daba para contratar a un programador holandés. Allí aprendí a comunicarme en inglés pero nunca me sentí a gusto hablando. Lo que más recuerdo de la startup es que al principio tuve bastantes dolores de cabeza porque tuve que hablar mucho en inglés con el dueño de la startup.
Al mismo tiempo, atendí varios cursos, fui a intercambio de idiomas y poco a poco me iba sintiendo más cómodo.

Tengo que agradecer a la serie juego de tronos que leyera mi primer libro en inglés. Tenía tantas ganas de saber cómo continuaba la serie después del último capítulo de la temporada (creo que de la segunda) que tuve que leerme los libros. Si alguno conoce los libros sabrá que cada libro tiene más de 500 páginas.

Cambié de empresa después de más de dos en la startup. Fue un cambio duro porque los compañeros de la startup se habían convertido en mi zona de confort.

Llegó un momento en el tiempo que pasé en la segunda empresa en el que me sentí más cómodo hablando. Habían pasado alrededor de tres años. Ayudó en sentirme más cómodo el curso que atendí para mejorar mi acento.
Todos los cursos relacionados con el inglés los hice en la empresa English Breeze. No hay nada mejor que encontrar un buen profesor que te ayude a recorrer el camino que te has marcado.


Aunque fue muy duro y me ha costado años el aprender inglés y el sentirme a gusto hablándolo ha merecido la pena porque me ha abierto muchas puertas. No estoy hablando solo a nivel profesional sino también a nivel personal. Me encanta aprender cosas nuevas y hay miles y miles de cursos y charlas gratis y que si no supiera inglés no hubieran estado disponibles para mí.

Todo esto lo cuento porque lo principal que he aprendido en mi tiempo que he pasado en Holanda ha sido que el único que está entre tu y tu objetivo eres tú mismo. Y que solo necesitas esforzarte y ser constante para conseguirlo.
Si tienes algo que quieres realmente hacer tienes que ponerte a ello, porque con constancia, tiempo y esfuerzo lo conseguirás.

* Modificado 05-05-2016: Corregidos errores gramaticales

Código como parte de entrevistas técnicas

Imagen de http://theodysseyonline.com/suny-new-paltz/interviews-the-bane-of-everyones-existence/249182

En los últimos meses he hecho unas cuantas entrevista en diferentes empresas españolas o que tienen sede en España y comparándolas con las que he hecho en Holanda lo que más me ha llamado la atención es que en ninguna española me han pedido código. Me llama la atención porque es algo que frecuentemente me han pedido en Holanda.

Pensando sobre esto me pregunto si puedes decir que un programador es bueno sin haber visto una línea de código que ha escrito.

Pongamos como ejemplo las entrevistas que he hecho para una empresa en España. Hice tres, una técnica, otra con mi posible futuro jefe y en la última con alguien de recursos humanos.

En la entrevista técnica respondí a muchas preguntas y en la parte final tuve que resolver problemas utilizando Java. En esta entrevista pudieron ver mis capacidades para resolver problemas y mis conocimientos de forma general sobre la informática.

En la segunda entrevista estuve hablando en ingles con mi posible jefe por teléfono. Fue una conversación sobre temas poco relacionados sobre mi trabajo, excepto por las preguntas que hice sobre la empresa. En esta entrevista pudieron comprobar cómo me manejo con el inglés y seguramente algo sobre mi carácter y forma de ser.

En la ultima entrevista hablé con alguien de recursos humanos sobre las cosas que le interesan a la gente de recursos humanos. Me imagino que van dirigidas a intentar conocer cuáles mis habilidades no técnicas, lo que en inglés se llama soft skills.
Teniendo en cuenta las tres entrevistas esta empresa sabe de mí:

• Mi capacidad de resolver problemas
• Mis conocimientos sobre informática
• Como me comunico en español y en inglés
• Mi forma de ser
• Mis habilidades no técnicas

Con esta información, ¿pueden saber si soy un buen programador? En mi opinión, no. Paso una parte importante de mi tiempo escribiendo código por lo que sí no ven nada de lo que he escrito es imposible que sepan que soy un buen programador.

Y si no saben si yo soy un buen o mal programador es posible que halla pasado lo mismo con los que serían mis futuros compañeros. Eso es muy peligroso porque significaría que la gente con la que estaré rodeado no son buenos y que por lo tanto podré aprender poco de ellos. Es un problema ya que aprender es muy importante para un profesional y más para un informático.

En conclusión, las empresas que no preguntan por código o no hacen pruebas de código no pueden garantizar que sus empleados sean buenos programadores. Personalmente, no me fío de este tipo de empresas porque pueden tener gente con la que podría trabajar y que me no aporten nada a mi aprendizaje.

Ciclo TDD: versión extendida

Imagen de http://www.agilenutshell.com/test_driven_development

Cuando a alguien se le explica por primera vez test driven development (TDD) lo primero que se le cuenta es su ciclo de desarrollo, que consiste en:

1. Escribir un test que falle
2. Escribir código de producción que haga que el test pase
3. Refactoriza el código

Estos pasos son un gran resumen de las principales tareas que hay que hacer en TDD pero para alguien nuevo en TDD no es suficiente. Voy a extender el mismo ciclo de desarrollo añadiendo más detalles. La mayoría de los pasos vienen de la siguiente página:

http://c2.com/cgi/wiki?TestDrivenDevelopment

Versión extendida

1. Selecciona un test. Busca un test que sea fácil de implementar pero que permita progresar lo máximo posible en la implementación
2. Piensa cómo quieres comprobar que el test pasa
3. Piensa qué debe ocurrir cuando todo va bien y cuando ocurre algo inesperado (excepciones). Por ejemplo, cuando hay problemas en la base de datos.
4. Escribe el test teniendo en cuanta cómo quieres que sea la API. Con la API me refiero al nombre del método, a sus parámetros y al valor a devolver
5. Haz que compile el código creando las clases y métodos que has escrito en el test. Los métodos deben devolver un valor, el que consideres que es el de por defecto
6. Comprueba que el test no pasa
7. Escribe el mínimo código de producción que hace que todos los test pasen. Si, el mínimo.
8. Si es necesario, mejora el código sin cambiar su comportamiento. O lo que es lo mismo, refactoriza el código
9. Comprueba que todos los test pasan

Notas

Teniendo en cuenta los pasos de la versión extendida, cuando escribimos el test ya hemos decidido qué vamos a hacer, cómo vamos a testearlo y cómo será su API. Luego dirán que con TDD no se piensa :)

Para gente con cero experiencia con TDD seguramente lo que les resulte extraño es que al escribir el
primer test, el código no compila y tendremos que crear todas las clases y métodos necesarios para que el código compile. Es una forma diferente de pensar, por lo que es necesario tiempo para asimilarla.

Consejo

Un muy buen consejo de Kent Beck en su libro TDD by example es el mantener una lista de los tests que quieres implementar. Así, cada test o prueba se convierte en una tarea a realizar y cada vez que terminas una es un ciclo TDD terminado y te acerca a la nueva funcionalidad que estás buscando.

Si eres indispensable estas haciendo mal tu trabajo

Imagen de http://www.newyork.com/

Te quieres ir de vacaciones tres semanas y se lo comentas a tu jefe. Te dice que ahora imposible porque el proyecto en el que estás trabajando eres el único que puede hacer una parte que es crítica. Al escucharle te sientes decepcionado al perderte tus vacaciones pero a la vez orgulloso porque eres una persona importante en tu empresa y porque eres imprescindible, ya que sin ti tu empresa no funciona.
Si este es tu caso no deberías sentirte orgulloso porque no estás haciendo bien tu trabajo.

Hay muchas razones por la que eres imprescindible pero seguramente que lo que está sucediendo es que eres la única persona en tu empresa que tiene el conocimiento de cómo realizar esa tarea.
Hay muchas razones por lo que esto puede suceder. Algunas son:

• La tarea es de vital importancia y no confías en nadie para hacerla.
• Tú eres la única persona con los suficientes conocimientos sobre el tema para entender el que hacer si surgen problemas.
• Tus compañeros no son lo suficiente buenos o profesionales para hacer (o eso es lo que tú piensas).
• No has tenido tiempo en compartir lo que sabes porque ha surgido algo urgente.
• Has pensado que no era importante el compartirlo.
• Tu jefe te ha dicho que es una perdida de tiempo.
• En un caso extremo de egoísmo, has decido el no compartirlo para convertirte en imprescindible y que no te puedan echar.

En cualquiera que sea tu caso no estás pensando en tus compañeros, ni en tu empresa y ni siquiera en ti.

De primeras te has quedado sin vacaciones, así que la playa y los mojitos tendrán que esperar. Además te has quedado sin aprender, porque no se tu pero cada vez que comparto información con mis compañeros siempre aprendo algo nuevo de ellos. Puede que aprenda algo pequeño pero siempre aprendo, y si eres informático como yo el aprender debería ser algo muy importante porque a los pocos años te quedas desfasado.
Si no eres informático el aprender también debería ser importante porque así te podrá diferenciar de tus compañeros y tener más posibilidades de destacar.

Desde el punto de vista de tus compañeros, toda la información debe estar compartida al menos por dos miembros de tu equipo. Así sí uno de ellos está enfermo, está de vacaciones o deja la empresa siempre habrá otra persona con esa información.
Por ejemplo, imagínate que has estado enfermo y debido a ello tu equipo ha estado casi parado. Lo que ha provocado que el proyecto no se ha terminado a tiempo y tu empresa ha perdido tiempo y dinero. Y todo ello por tu culpa, por no hacer bien tu trabajo y no compartir lo que sabes con tus compañeros.

Si no te he convencido y crees que eres intocable porque eres el único con esos conocimientos, recuerda que el mundo de la informática todo cambia muy rápidamente y que en 2, 5 o 10 años ese conocimiento no valdrá nada, tus jefes querrán despedirte, ninguna empresa querrá contratarte y lo vas a pasar mal. El que avisa no es traidor.

El río

 

La vida es tiempo. Tiempo que pasa y que hace que todo cambie pero que a la vez hace que siga todo igual porque para lo que para nosotros es una eternidad, para la vida es un instante.

La vida es un río. Un río que están movimiendose en todo momento y que a veces está calmado, a veces triste, a veces alegre, a veces rápido, a veces lento, a veces es todo y a veces es nada.

Un río que no tiene reglas, que no tiene límites, ni patrones ya que varía según Su antojo. Aún así sigue siendo siempre diferente, y sigue siendo siempre el mismo ya que somos parte del río. Nuestro presente, pasado y futuro pertenecen a El.

La gente que vive en este río son los que ponen las reglas, los limites, y dicen lo que está bien o mal. Intentan poner límites porque así se sienten más seguros y porque así se sienten en control. Somos nosotros, los hombres, los que convertimos un río infinito y lleno de sentimientos y de ilusiones en algo previsible y aburrido. En algo que odiar.

La vida visto desde nuestros ojos puede ser algo horrible pero no tiene porqué ser así porque el río de la vida no tiene límites. No tiene reglas. Es libertad.

 

Objetivos 2016

Imagen de https://www.teachingchannel.org

Me he retrasado en publicar mis objetivos para 2016 pero como dice el dicho, más vale tarde que nunca.
Echando la vista atrás, el 2015 ha sido mucho más relajado que el 2014. Es lo que tiene el trabajar en una empresa "normal" en vez de en una startup, que la vida es más tranquila :)

Lo más duro del trabajo ha sido el tener que ir a Amsterdam desde La Haya porque la oficina está ahí, más concretamente en Amsterdam Sloterdeijk. 
Pasé de tardar 15 minutes en bicicleta, a 1 hora y 15-30 minutos utilizando tranvía y tren. Pero el cuerpo se acostumbra rápidamente a los cambios.


Voy a hacer lo mismo del año pasado, primero voy a ver mis objetivos del año pasado y luego los nuevos para este 2016.

En la siguiente lista aparece en color negro mis objetivos del año pasado y en rojo mis conclusiones:

• Escribir en el blog de forma regular: dos artículos a la semana. Ahora sé que me voy a tener que esforzarme mucho para conseguir este objetivo pero seguro que merece la pena el lograrlo. Estoy contento con el blog porque, aunque no he llegado a los 24, he aumentado el número de artículos que he escrito. He pasado a escribir 8 en el 2014 a 14 en el 2015. Incluso he escrito artículos en Inglés, y estos cuentan doble porque cuestan el doble el escribirlos :)
• Aprender más lenguajes de programación: voy a intentar Groovy y/o Scala. Todo el tiempo que le he dedicado a TDD lo puedo dedicar a aprender nuevos lenguajes. Decidí el aprender Groovy. Hice un curso, un koan y escribí bastantes test unitarios. Es un gran lenguaje de programación. La combinación de Java para el código de producción y Groovy para test es muy potente. El problema es que no lo utilizo en el trabajo y no he empezado ningún Pet project con Groovy, así que es algo que estoy perdiendo poco a poco.
• Aprender Holandés: he aprendido la lección. Voy a intentar coger un curso que no me ocupe mas de un par de horas a la semana. Nada de nada. Nothing. Niente. Tenía clases de inglés hasta (creo recordar) Octubre y la idea de juntar el Inglés con el Holandés me tiró para atrás. Al terminar las clases, me dio mucha pereza el empezar un nuevo idioma. Soy de ciencias y el aprender Inglés me ha costado sudor y lágrimas. Siendo el Holandés un idioma más complejo y en el que no tengo ninguna base seguramente me va a costar más y mentalmente no estoy preparado.
• Hacer ejercicio dos veces a la semana: mi vida ha mejorado haciendo ejercicio así que hacer mas ejercicio seguro que lo mejora más. Encontré un meetup para jugar al fútbol y junto con el gimnasio hacía ejercicio al menos dos veces por semana pero llegó un momento en el que empecé a dejar el fútbol sin ningún motivo en concreto y ahora mismo voy solo al gimnasio.
• Mejorar mi pronunciación al hablar en inglés: tengo los típicos problemas de pronunciación de los españoles y alguno propio. Creo que mejorándolos me ayudaran a comunicarme mejor. Las clases de inglés con Hayley me han ayudado muchísimo y estoy muy contento al respecto. Las consecuencias de mejorar mi acento han sido que tengo mucho más confianza al hablar. También es cierto que en el trabajo tengo que hablar todos los días, así que puedo practicar todos los días. Esto ha ayudado.
• Aplicar agile prácticas en mi día a día. He leído bastantes libros sobre metodologías ágiles y creo que ya ha llegado el momento de aplicar lo aprendido. Utilizamos Scrum by the book en el trabajo. Al principio no lo utilizábamos pero creo que gracias a que hice una presentación, a que hablé con el jefe y que el estaba ya medio convencido empezamos a utilizar Scrum. Escribí un artículo hablando de mi experiencia. También lo practico de forma personal. Es bueno recordar que lo más importante de Agile son sus principios.

Pues en cuanto a objetivos cumplidos ha estado bastante bien el año. He cumplido tres y en dos progreso adecuadamente. No creo que sea muy importante el cumplir objetivos pero siempre hace ilusión.

A continuación mi nueva lista de objetivos para este nuevo año:

• Escribir en el blog de forma regular: Estoy con la moral alta por mi aumento en el número de artículo. Creo que puedo llegar a los 24 artículos para este año, aunque voy retrasado. Tengo que darle caña.
• Aprender más lenguajes de programación: Soy informático y es necesario el aprender cosas nuevas. Además te dan puntos de vista diferentes. Cuando estaba aprendiendo Groovy y estaba en el trabajo con Java, podía comparar lo que estaba haciendo con como sería en Groovy.
• Ir a eventos: Quería ir a la Agile Testing Day, a Xp days y a un code retreat en Bélgica pero por tiempo o temas personales o por otros motivos no pude ir. Creo que es una forma magnífica de aprender y de mejorar y de conocer gente interesante. Así que este año tengo que ir a al menos dos o tres eventos interesantes.
• Escribir en Inglés: Quiero escribir más artículos en Inglés. El escribir me fuerza a mejorar mi vocabulario y la forma de comunicarme. Creo que con cinco artículos, más que suficiente. La idea principal por la que empecé con el blog era el poder compartir con la gente lo que me parece interesante y por si alguien puede aprender de mis errores, pero no sé si al escribir en inglés me va a ayudar en esto. Ya se verá.
• Hacer ejercicio dos veces a la semana: Este objetivo es fundamental el cumplirlo ya que este año gracias a que he hecho más deporte he estado menos enfermo que el año pasado.
• Meditar tres veces por semana: Empecé a meditar por probar algo nuevo y, aunque es duro, los beneficios son muy grandes. Ahora mismo no lo hago a menudo y cuando lo hago son solo 10 minutos y no es suficiente. Me pasa como con el deporte. Sé lo bueno que es pero la pereza siempre gana.

Lo importante de los objetivos no es el cumplirlos sino el echar la vista atrás y pensar. Pensar si lo que he hecho y lo que estoy haciendo concuerda con lo que quiero hacer y con como soy.

También es cierto, que es bueno el marcarse objetivos y el cumplirlos porque en definitiva, un objetivo es un sueño, un sueño que queremos alcanzar. Y a quien no lo le gusta cumplir un sueño.

¡Tardío feliz 2016 a todo el mundo!

* Modificado 07-02-2016: Añadida imagen y cambiado texto final