De forma inconsciente, es mucho más probable que valores positivamente a personas con las que tengas una afinidad personal, mismos gustos, misma filosofía de vida, o incluso inclinaciones políticas parecidas. Pero que te pudieras ir a tomar algo con una persona no significa que vaya a ser un buen compañero de fatigas.

Seguro que te ha venido a la mente esa persona, con la que encajabas al cien por cien, pero en el día a día no daba la talla por cualquier motivo.

Qué valoramos

¿De qué va la entrevista personal? ¿Qué se busca realmente? o, al menos, ¿qué buscamos nosotros? En mi opinión mucha gente hace entrevistas sin tener muy claro qué es lo que se está buscando. Si te paras un poco a pensar qué es lo que buscas en una entrevista, es mucho más fácil que puedas encontrar las respuestas.

A continuación, vemos los elementos que buscamos nosotros.

Responsabilidad

Creemos que los errores penalizan mucho. Puedes hacer un trabajo genial con un diseño increíble implemetando mediante el Driven Development de turno, que si en la demo le das a guardar y sale un 500, quedas como el culo. Valoramos que el candidato pueda responsabilizarse del trabajo que realiza, tomándose la molestia por entender las necesidades, así como de realizar unas comprobaciones básicas.

Algunas preguntas que nos pueden ayudar a evaluar esto son: Describe el proceso desde que te asignan una issue hasta que la das por cerrada. ¿Cuál es el error que más frecuentemente cometes?

Encaje a largo plazo

Incorporar a una persona supone un pequeño drama para un equipo pequeño como nosotros. Tenemos que dedicar mucho tiempo y energías a realizar el proceso de selección: entrevistas, pruebas técnicas, etc. Después, realizar una oferta, esperar el tiempo que el candidato se toma para decidir, gestionar todo el papeleo y, finalmente, incorporarle al equipo, con un montón de tareas que esto conlleva. Todavía quedan unas cuantas semanas, sino meses, en los que necesitamos dedicarle mucho tiempo: explicarle el negocio, cómo trabajamos, etc.

Si después de todo este trabajo el candidato decide que quiere irse al poco tiempo, sería un absoluto fracaso. Así que está bien tener claro desde el principio que el candidato tiene potencial para permanecer varios años en la compañía.

Para evaluar esto, realizamos preguntas del tipo: ¿Por qué quieres trabajar con nosotros? ¿Por qué quieres cambiar de trabajo? ¿Cómo te ves dentro de 5 años?

También evaluamos su historial, para ver si tiene tendencia a cambiar fácilmente de empleo.

Inquietud por aprender

Para el equipo es importante incorporar a candidatos que tengan potencial para incluir cosas nuevas dentro del stack. Tenemos un stack que dominamos, muy consolidado, y con el que nos sentimos muy cómodos. Sin embargo, es bueno, tanto para nosotros como para la compañía, que tengamos capacidad de innovar. Es por esto que buscamos candidatos que muestren inquietud por aprender.

Buscamos evidencias de ello. ¿Qué libros ha leído últimamente?, ¿En qué proyectos open source ha colaborado?. ¿Qué tecnologías ha aprendido en los últimos años?.

Ojo, no sirve decir estoy aprendiendo XX. Casi todo el mundo dice estar aprendiendo algo. Si te preguntamos qué cosas te gustan de XX y cuáles no te gustan, esperamos una respuesta que nos permita hacernos una idea de que realmente estás profundizando en ello. Si das una respuesta poco clara, no lo tendremos en cuenta.

Flexibilidad

Los programadores somos por lo general bastante cabeza cuadrada. Entramos en conflictos por las más absolutas nimiedades. ¿espacios o tabulaciones? Por esto tenemos en cuenta cómo de bueno es el candidato adaptándose a un nuevo entorno o a un entorno que no está al cien por cien a su gusto.

Quiero alguien que entienda que nos pagan por solucionar problemas y mejorar procesos. Habitualmente lo hacemos poniendo software que funciona en producción.

Algunas preguntas que nos pueden ayudar, son: ¿Qué es lo que más te gusta y lo que menos de tu trabajo actual? ¿Qué dificultades tienes en tu trabajo actual?

Alto rendimiento

Somos un equipo de alto rendimiento. Obviamente no somos los mejores ingenieros del mundo, esos ya trabajan en Google, Amazon, Meta, ect.

Pero, dentro de nuestras posibilidades, tratamos de que salga trabajo a buen ritmo. No estamos hablando de que trabajar con nosotros sea un infierno y vayas a acabar quemado a la primera de cambio. Estamos hablando de buscar candidatos que, en una medida razonable, sean capaces de poner nuevas características en producción de forma consistente y a un ritmo razonablemente bueno.

Este apartado es muy dificil de evaluar, se evalúa en conjunto con la prueba técnica. Algunas preguntas que nos pueden ayudar con esto son: ¿Cómo de difícil fue la prueba técnica? ¿Qué partes se te hicieron más difíciles?

Escucha y toma notas

Antes de seguir, un consejo: ESCUCHA. Nunca debes interrumpir a un candidato. Incluso aunque esté contestando algo totalmente diferente de lo que se le ha preguntado. Simplemente lanza la pregunta y deja que él mismo empiece a hablar. Lo más importante durante la entrevista personal es que el candidato hable tanto como sea posible. Tampoco debes entrar en controversia con un candidato. Si el candidato realiza un comentario con algo totalmente intolerable, simplemente acaba la entrevista y agradécele su tiempo.

Si el candidato expresa una opinión con la que no estás de acuerdo o detectas alguna cosa que quieres matizar, anótalo y aprovecha los últimos minutos de la entrevistas para estas aclaraciones.

TOMA NOTAS. Muchos entrevistadores simplemente tienen un cara a cara con el candidato, pero no toman notas durante la entrevista. Yo les pido disculpas al comienzo de la entrevista a los candidatos por tomar notas. Hacerlo, puede que haga que la entrevista tenga algunos tiempos muertos, mientras acabas de escribir lo que quieres y lanzas la siguiente pregunta. Pero, al cabo del tiempo, lo agradecerás. Seguramente tengas que entrevistar a bastantes candidatos por cada puesto que tengas y los procesos probablemente se prolonguen durante algunas semanas, a veces durante algunos meses. Si no tomas notas, ya me dirás como vas a ser capaz de recordar los detalles de lo que te dijo el primer candidato con el que hablaste hace una hora hace dos meses.

El guión

Vayamos al grano. A continuación, te muestro el guión con las preguntas que hacemos a todos los candidatos. Como he dicho no somos profesionales de recursos humanos, así que hemos seleccionado este conjunto de preguntas. Todas ellas son muy abiertas, por lo que cada candidato podrá interpretarlas libremente.

El guión solo nos sirve para tener un sendero por el que conducir la entrevista, pero cada entrevista es diferente y puede que tome senderos diferentes. Ninguna de las preguntas tiene una respuesta correcta. Simplemente son un sendero para conocer mejor al candidato.

Describe brevemente tu carrera profesional

No me gusta empezar por esta pregunta. Sin embargo, los candidatos tienden a explicar su carrera profesional en la primera pregunta que le hagas. Debe ser que estamos programados para ello. Así que directamente le pregunto al principio del todo y así nos lo quitamos de en medio.

Normalmente proyecto el perfil de linkedin del candidato durante esta pregunta. Así le facilitamos el trabajo. En esta pregunta tratamos de dirigirle hacia los trabajos que ha realizado en los últimos años. Esto nos puede hacer una idea de en qué punto de su carrera está.

Introdúcete a ti mismo: ¿Quién es pepito pérez?

Esta pregunta es muy abierta. Lo que buscamos es tener una impresión general del candidato. ¿Qué opina de sí mismo? ¿Cómo se relaciona en sociedad?

¿Qué te motiva?

De nuevo es una pregunta muy abierta. Normalmente los candidatos relacionan esta pregunta con un nivel puramente profesional: ¿Qué te motiva en el trabajo?

¿Por qué quieres cambiar de trabajo?

Esta pregunta suele poner un poco incómodos a los candidatos. En muchos casos el candidato tiene que explicar por qué motivos no se encuentra cómodo en su actual puesto de trabajo.

¿Cómo es un día en tu trabajo ideal?

También es una pregunta que suele incomodar. Buscamos sobre todo saber si su trabajo ideal se parece a nuestro día a día, o si estamos dispuestos a adaptarnos a algo similar. Nos ayuda a detectar que tipo de cosas valora el candidato en una oferta de empleo. ¿Flexibilidad? ¿Prefiere trabajar en equipo o de forma más individual? ¿Qué tipo de buenas prácticas de las que estamos utilizando nosotros incluye?

¿Tienes alguna habilidad que te gustaría destacar?

Casi todos los candidatos suelen tirar por el lado profesional. Pero siempre es interesante escuchar las habilidades que tiene un candidato. Aquello que él considera que destaca fuera del ámbito profesional.

¿Por qué quieres trabajar con nosotros?

Pregunta típica de recursos humanos donde las haya. Suele sacar los colores a los candidatos, por qué no saben qué contestar. Obviamente no vas a descartar un candidato por que no se haya estudiado a qué se dedica la compañía, es algo que hemos hecho todos, apuntarnos a una oferta sin mirarla demasiado. Sin embargo, si el candidato tiene algún motivo para querer trabajar con nosotros como, por ejemplo, que le gusta el sector o que hay alguien dentro con el que quiere trabajar, es algo que valoramos positivamente.

Tu turno. ¿Qué te gustaría preguntarnos?

Siempre la última pregunta es para darle un espacio al candidato a que nos muestre sus dudas. Quizá quiere conocer más a fondo el stack o quiere conocer detalles como las facilidades que se dan en cuanto a flexibilidad laboral. Dejamos que el candidato exprese todas sus dudas y respondemos con tanta honestidad como sea posible. Las preguntas que nos hace también nos ayudan a conocer mejor al candidato. Si no pregunta nada, es que probablemente no esté interesado en el puesto de trabajo. Si pregunta por muchos detalles probablemente es por que realmente se está planteando venir a trabajar con nosotros.

Cierre

Siempre agradecemos al candidato el tiempo que nos ha dedicado, le explicamos los siguientes pasos del proceso y le invitamos a que, si le surgen dudas en los siguientes días, tengamos otra reunión para poder resolverlas.

Crea una base de datos

Como hemos visto, un proceso de selección es un montón de trabajo. Es por esto que merece la pena trabajar un poco más, e ir recopilando toda esta información sobre candidatos en algún tipo de base de datos. Si has hecho un proceso de selección como dios manda, habrás dejado un buen sabor de boca en todos los candidatos, y alguien que no te encajó en un puesto determinado, podría ser la persona correcta para otra posición. ¿Para qué volver a hacer el trabajo si ya lo hiciste en el pasado?

Como candidatos nos ha tocado hacer multitud de pruebas, y nunca hemos recibido ningún tipo de feedback, así que ahora que nos toca a nosotros, creemos que es un buen momento para tratar a los demás como nos gustaría que nos hubieran tratado.

Lo primero, esto no es un examen: es una opinión. Algunos candidatos entran en controversia con nosotros, y esto es algo bastante desagradable. Por supuesto siempre estamos abiertos a que alguien nos explique algo, y muchas veces hemos aprendido cosas con las pruebas de los candidatos, pero entiende que es muy desagradable cuando un candidato quiere convencerte de algo que no es.

Al final, si crees que estamos equivocados, es posible, simplemente somos programadores como tu, y por supuesto a veces nos equivocamos.

Candidato

Una prueba técnica tiene que estar muy orientada al tipo de candidato que estás buscando. No tiene mucho sentido hacer una prueba de algoritmia y patrones de diseño para un perfil que va a trabajar con wordpress.

En nuestro caso buscamos perfiles con varios años de experiencia, con un conocimiento razonablemente bueno del framework con el que trabajamos, pero que todavía tenga un buen margen de crecimiento junto a nosotros. Es decir buscamos a alguien que pueda ser productivo en un corto plazo, que pueda trabajar la mayor parte del tiempo de forma independiente, pero que el desarrollo profesional y el aprendizaje que puede adquirir con nosotros sea algo importante para él.

Descripción de la prueba

Nuestra prueba es realmente sencilla. No voy a describirla aquí, porque la cambiamos con cada proceso, pero básicamente pedimos que se instale un proyecto con symfony y que se programen un par de acciones, y algún comando. Todo ello sin dar ningún tipo de instrucción acerca de cómo hacerlo. Si acaso se insinúa ligeramente al candidato que sea creativo.

Consejos iniciales

Criterios de evaluación

Como verás en las cosas que evaluamos a continuación. es una prueba tan sencilla en la que buscamos es que seas muy detallista en las pequeñas cosas.

Asignaríamos una puntuación 1-10 para cada uno de los siguientes apartados, de forma que pudiéramos valorar de forma justa y a la vez sencilla para nosotros. Los criterios de evaluación no están en orden de importancia. Tampoco hacemos una media artimetica del resultado, simplemente es una guía para saber cuales son tus puntos fuertes y cuales son tus puntos debiles. El resultado de la prueba técnica, junto con la evaluación personal que hagamos, será lo que nos ayude a decantarnos por uno u otro candidato.

El README.md es una de las partes más importantes de la prueba, ya que te da la oportunidad de explicar y justificar las decisiones que has tomado.

Pon atención a las faltas de ortografía. No pasa nada, el que esté libre de pecado que tire la primera piedra, pero mi recomendación es que si sueles cometer faltas de ortografía, lo pases por un corrector antes de enviarlo.

Versiones

Valoramos positivamente que utilices las últimas versiones disponibles, especialmente del lenguaje y del framework.

Docker

Valoramos positivamente que presentes tu prueba dentro de un contenedor.

Coding Style

Valoramos positivamente que presentes un coding style consistente y especialmente que lo definas explícitamente de alguna forma, por ejemplo indicandolo en el README.md o incluyendo algún tipo de fichero de configuración como .php-cs-fixer.dist.php indicando tus reglas de estilo.

Alcance

Como ya he dicho anteriormente. Asegúrate de leer bien, lo que se pide. Muchos candidatos olvidan alguna pequeña cosa. Es obvio que es un despiste. Pero no dice algo bueno de ti, que seas despistado en una prueba sencilla.

Bundles

Muchos candidatos utilizan bundles de la comunidad. Valoramos positivamente que puedas usar los bundles más conocidos. Nos indica que conoces el ecosistema.

Comandos

La prueba probablemente te pida que ejecutes un sencillo comando. Evaluaremos que hagas un uso eficaz de los comandos. Valoramos que el candidato demuestre que conoce cómo funciona el componente configurando correctamente tanto los parámetros de entrada, como haciendo un uso correcto de la salida.

Formularios

Valoramos que el candidato demuestre que entiende bien cómo funcionan, que sea capaz de crear un formulario y añadirle algunas validaciones.

Doctrine

Valoramos que el candidato entienda cómo funciona doctrine. Declare entidades, repositorios y realice algunas queries sin cometer errores.

Servicios

Aunque la prueba no lo pide expresamente, se valora que el candidato trate de crear servicios y llevar la lógica desde los controladores a estos.

Assets / Frontend

Se valora que el candidato haga un uso correcto de webpack o que incluya algún otro recurso de frontend.

Pruebas

Se valora que el candidato entregue una batería de pruebas de algún tipo, unitarias, funcionales y sea capaz de justificar en el README.md su elección.

¿Qué te ha parecido?

Por supuesto, queremos saber tu opinión, ¿qué te ha parecido la prueba y el proceso en general?, ¿hay algo que cambiarías? ¿Crees que has tenido la oportunidad de demostrar tus capacidades? ¿Qué te hubiera gustado poder hacer?

Ciertas empresas suelen considerar que el candidato más cualificado para ocupar un puesto vacante es aquel que cumple con todos los requisitos y cuyas expectativas salariales son lo más bajas posibles, nosotros consideramos que enfocar así la busqueda es un error que puede traer consecuencias a larga. Pensamos que para que un empleado pueda exprimir sus capacidades en nuestra empresa, ha de existir una estrecha relación entre los requisitos que exigimos por su parte y las expectativas de trabajo que el candidato espera que la compañía ofrezca.

A lo largo de este artículo te contaremos cómo es nuestro proceso de selección con todo lujo de detalles.

La preselección

Solemos recibir candidaturas a través de dos canales:

1. A través de portales de empleo.
2. Nos contactan de manera directa al haber visto la oferta publicada a través de nuestra página web o de alguna redes sociales.

No nos gusta tener que depender de una plataforma o herramienta de terceros para comunicarnos, por lo que a partir de la toma de contacto nos comunicamos siempre de manera externa a ellas. Creamos en nuestro CRM una ficha con los datos relevantes del candidato y comprobamos si cumple los principales requisitos, aunque no los cumpla al 100%, pueden existir detalles que nos motiven a incluirlo en el proceso de selección como por ejemplo, una buena carta de presentación o una buena actitud.

Somos una empresa que trabaja 100% en remoto por lo que da igual en qué punto del globo se encuentren los candidatos, siempre que se conecten con nuestro horário y hablen nuestro idioma ;)

Llamada telefónica

Lanzamos a través de redes sociales los puestos que necesitamos cubrir y adjuntamos una encuesta que nos ayudará como primera criba, es importante para nosotros contar con un punto de partida óptimo que garantice conocimientos o estandares fijados así como conocer si el candidato o candidato están familiarizados con metodologías ágiles. Por lo general los primeros descartes se realizan por expectativas económicas que no van a acordes a lo que el candidato puede ofrecernos, por ejemplo, si buscamos a alguien que tenga experiencia en symfony, y el candidato tiene unos conocimientos mínimos, no vamos a poder ofrecer los 40k que nos exija, no podemos pagar esa cantidad para acabar enseñando a utilizar una herramienta que exigimos como esencial.

Entrevista personal

Es el plato fuerte de cualquier proceso de selección, es realizada por todo el equipo y se divide en dos partes:

El objetivo de la primera parte es buscar la sintonía entre lo que el candidato busca y lo que podemos ofrecerle entendiendo, entre otras cosas:

• Qué tipo de candidato es.
• Cuáles son sus motivaciones.
• Cuál sería su trabajo, pretendemos conocer si el desempeño deseado por el entrevistado se aproxima a lo que hacemos en nuestro día a día.

En la segunda parte dejamos preguntar al candidato y mostramos qué es lo que hacemos, esta parte de la entrevista es la más libre y abierta, suelen surgir preguntas de todo tipo y que dependen únicamente de la curiosidad del entrevistado. Intentamos mostrar la mayor transparencia posible sea cuál sea la pregunta.

La tasa de descartes en esta fase suele ser del 50%.

Prueba técnica

La prueba técnica nos sirve para saber si el candidato posee los conocimientos técnicos adecuados. No es una prueba complicada y aunque existan algunas partes en las que no se disponga de un conocimiento adecuado, se podrá superar poniendo un poco de empeño.

Se puede resolver de diversas formas. La forma en la que se resuelva nos dará las claves para saber con qué tipo de programador hemos topado. No solemos descartar a casi nadie en esta fase ya que evaluamos según factores que nos ha contado el candidato anteriormente.

Reunión del equipo

Todo el proceso esta diseñado para que al final llegue un pequeño grupo de personas a las que, tras una reunión de equipo, ordenaremos de mayor a menor teniendo en cuenta una ponderación realizada a través de los siguientes factores:

1. Feeling personal / soft skills.
2. Objetivos a medio-largo plazo.
3. Conocimientos técnicos requeridos.
4. Conocimientos técnicos adicionales del candidato.
5. Expectativas salariales.

Cada parte de nuestro equipo tiene opiniones diferentes al resto, por ello esta especie de ranking ponderado nos aporta una visión general de los entrevistados teniendo en cuenta las opiniones subjetivas de todo el equipo.

Oferta al candidato

Una vez ordenados de mayor a menor según la preferencia del equipo, nos ponemos en contacto con el candidato que más nos ha gustado para hacerle la oferta final y recordarle las condiciones pactadas. Le enviaremos la oferta por correo.

Normalmente aceptan la oferta. Si han llegado hasta aquí es porque existe “buen feeling” entre ambas partes. En caso de no aceptar, pasaríamos al siguiente candidato, llevando a cabo el mismo proceso.

¿Y los no seleccionados?

Todos los candidatos que no han superado alguna de las pruebas como podría ser la entrevista personal y la técnica, no se convierten en candidatos descartados, simplemente no han sido seleccionados y se lo comunicaremos explicando el motivo. De esta manera podemos ayudarle a mejorar en futuros procesos de reclutamiento.

¿Pruebas automáticas?

Las pruebas o la batería de pruebas es un software que debe escribirse en paralelo a nuestro propio software y cuya responsabilidad es comprobar que nuestro software funciona correctamente. Básicamente es software que prueba nuestro software.

Puede que intuitivamente pienses que construir una batería de pruebas, es trabajo adicional, ya que probablemente tardarás más tiempo y por lo tanto tu trabajo será más caro para tus clientes pero esto no es así.

Cuando tienes una buena batería de pruebas, la primera "derivada" es que vas a cometer menos errores. Menos errores supone menos tiempo arreglando errores y más tiempo programando. Además supone menos frustración en los usuarios.

La segunda derivada es que puedes hacer cambios con mayor confianza, y esto te hace ir más rápido. Las pruebas detectarán que has roto, y simplemente tendrás que arreglarlo, un equipo con una buena batería de pruebas termina trabajando mucho más rápido que un equipo que no las tiene.

Hay una tercera derivada y es que al desarrollar tu batería de pruebas te va a permitir diseñar mejor software, pero esto es algo en lo que profundizaremos en una entrada más adelante.

¿Si es tan bonito por que no todo el mundo hace pruebas automáticas?

Cuando escribes pruebas debes ser tan cuidadoso cómo con el código de producción. Todo lo que hemos comentado ya en esta serie sobre elegir buenos nombres, funciones, argumentos, etc son cosas que también aplican a las pruebas automáticas.

Escribir buenas pruebas requiere cierta técnica y ocurre que muchos programadores o equipos comienzan haciendo pruebas, y al no ser pruebas de calidad terminan teniendo una batería de pruebas que supone más un problema que una solución. Tras esta mala experiencia desisten, por eso en esta entrada vamos a explicarte cómo escribir buenas pruebas.

Escribe tus pruebas "PRIMERO"

FIRST o PRIMERO es un acrónimo que se utiliza para describir las características que debería tener una prueba.

Fast o Rápidas

Una prueba, así como la batería de pruebas a la que pertenecen deberían ser tan rápidas cómo sea posible. ¿Cuánto? Pues depende del tipo de prueba y del proyecto. El autor no se moja en este aspecto, pero en mi opinión deberías mantener cada prueba por debajo de 1 segundo.

Independent o independientes

Unas pruebas no deberían depender de otras. Esto te permitirá ejecutar aisladamente las pruebas que fallen en lugar de tener que ejecutar toda la batería o un conjunto de pruebas.

Repeatable o repetibles

El resultado de una prueba debería ser siempre el mismo y no variar si la ejecutas varias veces. De esta forma, podrás ejecutar una prueba una y otra vez, hasta que arregles el error. De lo contrario tendrías continuamente errores que luego no vas a poder reproducir.

Self-validating o validación automática

Lo que quiere decir esta regla es que las pruebas no deberían depender de una revisión, por ejemplo que el resultado fuera un texto que luego necesitarás leer para saber si es correcto o no. La prueba debe pasar o no pasar, no debería haber otro resultado posible.

Timely o en el momento correcto

El autor introduce en este capítulo las reglas del ciclo de TDD: rojo, verde y refactorización, pero no quiero profundizar mucho sobre este aspecto aquí, porque tendremos el libro "Test Driven Development: By Example" por en este blog y en el canal de youtube más pronto que tarde.

Show me the code

Supongamos que tenemos la clase rectangulo que vimos en el capítulo de estructuras vs objetos.

class Rectangle
{
    private $height;
    private $width;

    public function __construct(float $height, float $width)
    {
        $this->height = $height;
        $this->width = $width;
    }

    public function area(): float
    {
        return round($this->height * $this->height, 2);
    }
}

Escribir una prueba es una tarea muy sencilla, normalmente es simplemente una clase que tiene que extender de algún tipo de framework de pruebas, así es como se hace con phpunit

class RectangleTest extends \PHPUnit\Framework\TestCase
{
    public function test_area()
    {
        $rectangle = new Rectangle(1.11, 2.22);
        $this->assertSame(2.46, $rectangle->area());
    }
}

Fácil, pero ¿que ocurre al ejecutarlo?

Efectivamente había un error en el código. En este caso lo hemos introducido a posta, pero es un tipo de error que se puede cometer fácilmente.

¿Has visto cual?

La semana pasada publicamos una entrada sobre el uso de los comentarios. En ella explicábamos que siempre que puedas deberías evitar el uso de comentarios.

Argumentábamos que cuando utilizas un comentario para explicar un código que no se entiende con facilidad, no estás mejorando tu código, sino que estás poniendo una piedra en tu camino. Tu código sigue siendo igual de difícil de entender y además ahora te tendrás que ocupar de mantener esos comentarios actualizados. Lo cual no aporta valor a tu proyecto.

Muchas personas nos han escrito tanto por Linkedin, Twitter, Youtube y el grupo privado que tenemos en Telegram para tratar temas del canal.

Nos han indicado diferentes ejemplos en el que era muy difícil eliminar los comentarios o directamente no se podían. No quiero entrar aquí a revisar cada uno de los ejemplos, pero tras revisarlo con el equipo, era evidente que eran buenos ejemplos. En esos casos, los comentarios si ayudaban a mejorar el código.

Es por eso que quiero hablar un poco sobre los dogmas.

Los dogmas en el desarrollo de software

Existen por supuesto muchos dogmas en el mundo del desarrollo de software, seguro que te suenan algunos de estos:

1. Si no haces scrum estricto no haces scrum.
2. No se puede sacar adelante un proyecto sin pruebas automáticas.
3. En 2020 todo el mundo tiene que hacer DDD.

Estas y otras muchas que se te ocurran las hemos escuchado todos cientos de veces.

Poner un hombre en la luna

Corría el año 1957, estados unidos y la unión soviética se encontraban enfrascados en mitad de la guerra fría, cuando los soviéticos pusieron por primera vez un satélite en órbita, el sputnik. Esto supuso un gran varapalo para la sociedad americana, que crearía la NASA. Había comenzado la carrera espacial.

12 años más tarde en cabo cañaveral despega un cohete con tres astronautas y una misión: "poner un hombre en la luna". Los estados unidos tuvieron que hacer un gran esfuerzo en el desarrollo de la tecnología informática, ya que aquel cohete tenía un computador capaz de guiarlo. Ese computador por supuesto ejecutaba software, y ese software fue programado 30 años antes de que se publicara el manifiesto ágil.

Es decir que sin las consideradas mejores prácticas del momento actual, sin el framework de moda, este equipo de programadores fueron capaces de diseñar y programar un software que puso a un hombre en la luna.

La flexibilidad y empatía

Lo mejor es ser capaz de adaptarse a cada situación, este es el único dogma que te tienes que grabar a fuego.

Pensar que sólo hay un camino para hacer las cosas bien es cuando menos una postura algo miope. Si alguien piensa que su metodología / tecnología / framework / loquesea es netamente superior a las todas las demás está evidentemente equivocado.

Te voy a poner un ejemplo personal. La técnica del diseño dirigido por test (TDD) es una técnica que te ayuda a diseñar software escribiendo primero las pruebas y luego el código de producción. Al hacerlo al revés, haciendo primero las pruebas, te ayuda a que pienses en tu diseño desde fuera hacia dentro, en lugar de como lo harías habitualmente, desde dentro hacia afuera.

Yo estuve haciendo TDD durante aproximadamente un año. Después dejé de hacerlo. ¿Por qué? Pues por dos motivos. Primero porque una vez que asimilas bien la metodología, vas a ser capaz de pensar desde fuera hacia dentro sin necesidad de escribir primero el test y segundo porque en muchos proyectos el diseño no es algo crucial.

En mi opinión tu criterio vale más que lo que alguien escribiera en un libro en la punta del mundo hace veinte años.

No dejes de aprender

Que los dogmas no sean realmente dogmas, no es una excusa para no seguir aprendiendo o mejorando. En mi opinión es tu responsabilidad como buen profesional ir mejorando cada vez tus capacidades.

Además es una buena forma de disfrutar de nuestra profesión y por que no decirlo de ganar cada vez más dinero. No se paga igual de bien a alguien que programa en el lenguaje "a pelo" que a un "tope de gama" en la última metodología o framework de moda.

Te propongo algunos consejos para que no dejes de aprender.

Busca un buen proyecto La forma más fácil de seguir mejorando es dedicar ocho horas al día a mejorar, y para ello debes elegir tu puesto de trabajo en función de donde más vayas a aprender. El dinero y otras ventajas deberían pasar a un plano secundario. Da igual que ganes menos dinero el año que viene, lo importante es cuánto dinero vas a ganar el resto de tu vida.

Sigue canales de youtube y podcast de la temática. Una buena forma de seguir aprendiendo es este tipo de contenidos que suelen tener una alta calidad, y no requieren de demasiado esfuerzo, ya que puedes ver este video, mientras que vas en el tren de camino al trabajo o mientras esperas a un amigo.

Asiste a conferencias y meetups. Es una forma fácil de aprender y de conocer gente. Nunca vas a aprender sobre todo, pero si tienes el teléfono del que sabe, también puede servir.

Lee libros En comparación con los anteriores es el que más esfuerzo o disciplina requiere, pero si no quieres que te den gato por liebre lo mejor es acudir a la fuente. Leer un libro al año, puede marcar la diferencia.

No olvides apuntarte a nuestra academia, para recibir todas las semanas un nuevo video sobre desarrollo de software

Hacer una única cosa

Una función solo debería hacer una única cosa, y además debería de ser ser capaz de hacerla bien. Este concepto a la vez que es sencillo de entender es bastante complejo de explicar, así que vamos a definir algunas características que pueden indicarte que una de tus funciones hacen más de una cosa.

Demasiado larga

Si una función tiene demasiadas líneas de código, es muy probable que esté haciendo varias cosas a la vez. Deberías tratar de encontrar bloques dentro de esa misma función que hagan una cosa concreta e ir extrayendolas en funciones más pequeñas.

El límite exacto para considerarse demasiado larga es un poco difuso, pero por encima de 20 líneas deberías al menos plantearte si tu función es demasiado larga.

Secciones

Como continuación a lo anterior, si una función puede dividirse en secciones, nos encontramos ante un caso claro de que esa función hace más de una cosa.

A continuación vemos la función Lock::acquire

/**
 * {@inheritdoc}
 */
public function acquire(bool $blocking = false): bool
{
    try {
        if ($blocking) {
            if (!$this->store instanceof BlockingStoreInterface) {
                throw new NotSupportedException(sprintf('The store "%s" does not support blocking locks.', get_debug_type($this->store)));
            }
            $this->store->waitAndSave($this->key);
        } else {
            $this->store->save($this->key);
        }

        $this->dirty = true;
        $this->logger->info('Successfully acquired the "{resource}" lock.', ['resource' => $this->key]);

        if ($this->ttl) {
            $this->refresh();
        }

        if ($this->key->isExpired()) {
            try {
                $this->release();
            } catch (\Exception $e) {
                // swallow exception to not hide the original issue
            }
            throw new LockExpiredException(sprintf('Failed to store the "%s" lock.', $this->key));
        }

        return true;
    } catch (LockConflictedException $e) {
        $this->dirty = false;
        $this->logger->notice('Failed to acquire the "{resource}" lock. Someone else already acquired the lock.', ['resource' => $this->key]);

        if ($blocking) {
            throw $e;
        }

        return false;
    } catch (\Exception $e) {
        $this->logger->notice('Failed to acquire the "{resource}" lock.', ['resource' => $this->key, 'exception' => $e]);
        throw new LockAcquiringException(sprintf('Failed to acquire the "%s" lock.', $this->key), 0, $e);
    }
}

Podemos observar 3 secciones principales. En la primera trata de adquirir el bloqueo, en la segunda comprueba si el bloqueo debería haber expirado y en el último bloque realiza el manejo de errores. Podríamos facilitarle mucho la vida al lector si extrajeramos esos bloques dejándolos en algo similar a esto.

/**
 * {@inheritdoc}
 */
public function acquire(bool $blocking = false): bool
{
    try {
        $this->tryAcquire($blocking);
        $this->releaseIfExpired();

        return true;
    } catch (\Exception $e) {
        return $this->handleException($e);
    }
}

switch

Un bloque switch es probablemente un indicador de que una función hace varias cosas. La forma de solucionar esto es extraer ese bloque switch para que la única cosa que haga nuestra función es decidir qué hacer en función del valor que le pasemos a switch.

A continuación vemos un caso válido de un bloque switch dentro de la clase Store\StoreFactory, ya que aunque tiene un elemento switch la función hace una única cosa, en este caso devolver la instancia de Store\PersistingStoreInterface correcta en función del tipo de conexión que estemos utilizando.

/**
     * @param \Redis|\RedisArray|...
     *
     * @return PersistingStoreInterface
     */
    public static function createStore($connection)
    {
        if (!\is_string($connection) && !\is_object($connection)) {
            throw new \TypeError(sprintf('Argument 1 passed to "%s()" must be [...], "%s" given.');
        }

        switch (true) {
            case $connection instanceof \Redis:
            case $connection instanceof \RedisArray:
            case $connection instanceof \RedisCluster:
            case $connection instanceof \Predis\ClientInterface:
            case $connection instanceof RedisProxy:
            case $connection instanceof RedisClusterProxy:
                return new RedisStore($connection);
            // en total hay 32 casos diferentes.
        }

        throw new InvalidArgumentException(sprintf('Unsupported Connection: "%s".', $connection));
    }

Un sólo nivel de abstracción

Dentro de una misma función debemos mantenernos siempre dentro del mismo nivel de abstracción.

Por ejemplo si tuviéramos una capa de dominio de negocio y una capa de persistencia de datos, dentro de una misma función no deberíamos pasar de un nivel a otro, por lo cual tendríamos funciones con lógica de negocio y funciones con lógica de persistencia de datos.

Procesamiento de errores

Empezaremos indicando que el procesamiento de errores es mucho más sencillo a través de excepciones que de códigos de error, pero esto lo veremos mucho más en profundidad en el capítulo de procesamiento de errores.

El problema que tienen los bloques try / catch es que dificultan mucho la lectura.Si tenemos una función donde además de la lógica de la función tiene uno o más bloques try / catch, probablemente deberíamos extraer la parte de la lógica de negocio y dejar esa función sólamente con los bloques try catch tal y cómo hicimos con la función Lock::acquire en el ejemplo anterior.

Más lento para ir más rápido

A lo largo de este primer capítulo Martin nos introduce la idea de que en muchos proyectos cuando se trata de ir demasiado deprisa el resultado es exactamente el contrario. Si eers programador probablemente hayas vivido esto en tus propias carnes. En el periodo de uno o dos años en los que los programadores han ido añadiendo cambios al código sin control el resultado es que cada vez se hace más y más difícil avanzar y se dedica la mayoría del tiempo a solucionar incidencias. Para añadir cualquier pequeño cambio es necesario tener en cuenta un sin fin de detalles, efectos y consecuencias, así que cada nueva funcionalidad añade aún más complejidad al proyecto.

La solución que aplican muchos managers en este momento es aumentar la plantilla, pero sin cambiar la forma de trabajar, lo que fragmenta más el código y reduce cada vez más la productividad. Más pronto que tarde el equipo de desarrollo se plantará y exigirá "rehacer" el código para sacar una nueva versión, esta vez sin los problemas de la actual. Pero recuerda que si no cambian su forma de trabajar y de pensar, el mismo equipo que generó el problema volverá a generar un problema parecido de nuevo.

Si te has visto en esta situación te aconsejo leer esta serie de entradas sobre código limpio.

Bien, ¿Pero qué es el código limpio?

El libro autor comienza haciéndose el mismo esta pregunta. Para ello recurre a diversos autores relevantes a los que les traslada esta cuestión.

¿Qué conclusiones sacamos?

De todas estas entrevistas se extraen una serie de ideas más o menos comunes.

Que haga lo que se espera que haga

Nosotros en DEVTIA a esta regla la llamámos: "No me mientas". Es también muy fácil de entender cada función y cada clase tiene que hacer exactamente, lo que se espera que haga. Además esto debe ser evidente, no debo necesitar entrar a ver el método para saber que puedo esperar de el.

Pequeño

Esta es una regla fácil de seguir y fácil de entender. Cuanto más pequeño sea nuestro código más fácil será que podamos modificarlo y mantenerlo. Dependerá de cada proyecto y de cada equipo establecer los límites, pero un buen punto de partida podría ser que las funciones y las clases con sus métodos colapsados deberían poder visualizarse completamente en las pantallas que está usando el equipo.

En los siguientes capítulos veremos muchos ejemplos para mejorar este aspecto.

Sin duplicidad

Un error claro de diseño es cuando necesitas copiar y pegar tu código en diferentes sitios. A la larga esto va a introducir errores, ya que cuando alguien actualize una copia, probablemente olvidará actualizar las demás.

Debe tener tests

Casi todos los autores han introducido la importancia de los tests. Tener una buena batería de test nos va a permitir trabajar con nuestro código y poderlo modificar con seguridad de que si estamos rompiendo alguna cosa, los test nos van a avisar.

La regla del boy scout

La regla del Boy Scout se trata de una regla muy sencilla. Originalmente se refiere a lo que hacen los Boy Scout cuando hacen una acampada: dejan el lugar en el que han estado un poco más limpio de como se lo encontraron.

Aplicado al desarrollo de software nos indica que si en nuestro día a día según estamos trabajando en un proyecto podemos ir introduciendo pequeñas mejoras que el autor original no tuvo en cuenta, pero que para nosotros son evidentes. Estos pequeños cambios, en los que podemos incluir desde cambio de nombres, extracción de métodos, pequeños refactorizaciones, solución de bugs, ect, a lo largo de un periodo de tiempo generará un grado de maduración en el código.

Como empresa nueva nos encontramos con determinados problemas al empezar que nos llevaron a instaurar un sistema de competencia entre empleados que mantuviera controlados ciertos aspectos y ayudará a llegar a determinadas metas.

¿Qué fue lo que nos llevó a tomar esta decisión?

Uno de los principales problemas a los que tuvimos que hacer frente en nuestros inicios fue el motivar a nuestros empleados a seguir unas determinadas pautas y políticas a la hora de trabajar. Algunas de estas pautas eran:

1. La calidad no se negocia, nos da exactamente igual que el cliente tenga prisa o que nos presione para que hagamos las cosas como ellos digan. Preferimos tardar más si el resultado va a ser de una calidad mayor. La experienca nos demuestra que si te dejas llevar por las "prisas" del cliente o de tu jefe, acabas realizando un trabajo muy pobre, y las miradas van a venir a tí, cuando empiezen los problemas. Por esto es muy importante saber poner como prioridad la calidad en el trabajo.
2. No se sube absolutamente nada a producción sin haber realizado las pruebas automáticas. Los programadores que no están habituados a trabajar con pruebas automáticas, suelen tener mucha reticencia, a realizarlas, por desconocimiento y por pereza, por lo que las dejan siempre para el final. Tras algunos meses trabajando de esta forma tienes un proyecto con apenas pruebas y entonces vienen los problemas. Por eso, dejamos a decisión del programador si quiere realizar las pruebas antes mediante TDD o despúes, pero no se puede subir codigo de producción sin sus correspondientes pruebas.
3. Hay que documentar lo que hacemos. En nuestra opinión, nuestros desarrollos tienen que estar auto documentados. Esto significa, que si por ejemplo para calcular un dato, estás aplicando una formula, lo ideal, es que puedas plasmar esa formula en el mismo sitio donde se muestra el dato, ya sea a través de tooltips, aclaraciones debajo, o páginas de ayuda. De esta forma, ayudamos al usuario a comprender que está pasando y a la vez tenemos una documentación que se mantiene actualizada. En un futuro escribiremos un artículo sobre cómo se debería documentar según nuestro criterio.

Por desgracia, el equipo siempre acababa dejándose llevar por las imperantes necesidades del cliente y no se cumplían determinadas instrucciones de la empresa. En DEVTIA entendemos este comportamiento ya que el cliente es el que manda y el que aporta el dinero al proyecto. La falta de tiempo existente y las prisas del cliente eran uno de los principales motivos por los que el equipo acababa por no seguir el plan.

El director de tecnología tampoco disponía de tiempo suficiente para revisar uno por uno el trabajo de la plantilla, de forma recurrente, lo cual favorecía el no seguir las normas generales de la empresa.

¿Cómo mejoramos la situación?

Fue en este punto cuando decidimos revertir la situación, convirtiendo algo negativo en una manera de evolucionar como empresa y de acabar obteniendo mejores resultados.

Lo primero que decidimos hacer fue empezar a medir el desempeño de la plantilla con respecto a unas métricas previamente definidas y estudiadas. Estas métricas se basan en tres principios:

• Deben ser objetivas.
• Deben ser automáticas.
• Deben estar alineadas con la política de la empresa.

Las métricas que elegimos fueron las siguientes:

Inserciones en el repositorio

Las inserciones son el número de líneas añadidas al código. Cualquier programador con conocimientos suficientes opinará que no es una buena métrica en la que basar un sistema de competencia entre empleados, ya que es algo muy subjetivo, y no por insertar más líneas en el código se realiza un trabajo mejor.

Por ejemplo, un proyecto con muchas tareas de soporte al cliente, generará menos inserciones, lo cual no significa que se haya trabajado menos… ¿verdad? Por ello somos partidarios de darle la importancia necesaria a esta métrica, pero dentro de un contexto.

Es un factor que te permite medir la actuación y desempeño de una persona. Si una persona hace pocas inserciones en una semana no es nada preocupante, pero si este comportamiento perdura en el tiempo podría ser indicador de que algo no va como debería.

Actualmente contamos con una media de 2000 inserciones, que sirven de guía para hacernos una idea de cómo va la cosa.

Cobertura de rutas

Es una medida que nos dice el tanto por ciento de rutas (URL’s) que están cubiertas al menos por un test funcional. La situación idónea sería que todas las rutas pasaran por al menos un test funcional.

Aunque no es una medida 100% fiable en cuanto al desempeño del trabajo, si que es una referencia para saber si la plantilla está subiendo los cambios y el nuevo código con test.

Cuando empezamos con esta manera de trabajar, teníamos entre un 10-20% de URL cubiertos con test, actualmente nos encontramos en torno al 92%.

Succes time

Es el tiempo medido en % en el cual los test están en verde, es decir que están pasando todos correctamente. Actualmente esta métrica la medimos con el programa Jenkins, una herramienta open source construida específicamente para ello.

Una de nuestras prioridades utilizando esta métrica es lograr que los test se encuentren verdes la mayor parte del tiempo, no que se dejen para el final después de haber pasado semanas en rojo. Actualmente permanecemos verdes el 90% del tiempo lo cual es muy positivo.

Queremos que nuestros empleados estén atentos y se preocupen de ello día a día. De hecho, este es uno de los principales motivos por los que ponemos a competir a nuestros empleados, para aumentar la productividad debido a la competencia entre ellos.

Tareas cerradas en Jira

Jira es la herramienta que utilizamos para la gestión de las tareas realizadas por el equipo. Nuestro fin es que todo quede fielmente reflejado en la herramienta. Así podremos saber:

• Cuál era el alcance original de la tarea.
• Cómo fue evolucionando.
• Quién era el responsable.
• Cómo fue su resolución.
• A que líneas de código afecto.

Aunque una tarea no es una medida exacta ya que unas son mucho más complejas que otras, se logra fomentar el uso de la herramienta. Actualmente pedimos que se cierren al menos cuatro tareas por semana.

¿Cómo fue la evolución?

Empezamos a medir todas las métricas anteriormente expuestas a través de informes periodicos que además recibián cada miembro del equipo. De esta forma podía saber no sólo lo bien o mal que lo estaban haciendo, si no como estaban en comparación con el resto del equipo.

Cada semana cada miembro del equipo recibía un correo similar a este:

Cada mes cada miembro del equipo recibía un correo similar a este:

Los resultados fueron sorprendentes a la par que satisfactorios, el equipo pasó de tener un compromiso bastante bajo a estar totalmente comprometido y dedicado. Se establecieron unos mínimos semanales a cumplir, modificándolos según el desempeño.

Para motivar esta competencia y hacerla lo más sana posible, impusimos una sanción de un euro para que todo aquel que fallara en uno de los criterios mínimos. El dinero los introducimos en una pequeña hucha con forma de cerdito, consiguiendo que el proceso de pagar no se convierta en algo hiriente, sino que tuviera un toque simpático.

En el momento en que tengamos cierta cantidad de dinero dentro del cerdito, se comprará un regalo al que todo el mundo quiera optar, en nuestro caso algo de temática freak. Estableceremos un sistema de puntuación teniendo en cuenta todo lo anteriormente explicado y el empleado que más puntos acumule en un determinado periodo de tiempo, será el que se lleve el premio.

También para clientes

Aunque durante toda la entrada hemos hablado sobre como hacemos competir a nuestros empleados. Es una política que tratamos de implantar entre nuestros clientes. Si acceden, nos gusta ponerle en el dashboard de cada usuario, algunas metricas que indiquen como es su rendimiento con respecto al resto de empleados de su equipo.

Por ejemplo si tienen un equipo comercial, cada miembro podría ver cual es la facturación que ha conseguido ese año, y el porcentaje con respecto al total del equipo.

¿Y a ti, qué te parece nuestro sistema para poner a competir a nuestros empleados?

Este año se ha dado una coincidencia muy peculiar. Se celebraba la primera Pulpo Conf en Vigo y yo iba a ir a mi primera meetup, desde que puedo considerarme programador, gracias a Dani, que nos propuso hacer una escapada de fin de semana a todo el equipo de Devtia. Casualidades de la vida, ambas iban a coincidir en el tiempo y allí nos plantamos, nada más acabar las vacaciones, en las tierras norteñas.

Puede parecer que no pero en coche son unas pocas horas de trayecto de Madrid a Vigo. Concretamente, y sin contar paradas, algo menos de 6 horas de camino. Salimos desde mi barrio al finalizar la jornada y nos pusimos en marcha amenizados por música rock, conversaciones sobre historia (es lo que tiene estar rodeado de expertos en la materia) y algún tip de programación.

Llegamos a la ciudad de Vigo, en tierra galegas, sobre las 20:00. Un pequeño paseo, una cerveza en una terraza y vuelta al piso para cenar, contar 3 chistes y dormir para estar a tope la mañana siguiente, que esto empezaba bastante pronto.

LA CONFERENCIA

Ahora si, 7 de septiembre de 2019 08:40 AM y paseo de 20 minutos hasta la Sede de la Afundación, un maravilloso edificio reformado, antigua sede del ayuntamiento de Vigo, donde se celebraba la #pulpocon19. Al llegar ya había algo de cola, con mucha gente con cara de dormido aún, esperando a recoger el Welcome Pack y disponerse a desayunar. Un Welcome Pack, por cierto, bastante completito. Pegatinas, una bolsa de tela con el logo, la camiseta del evento, una pelota antiestrés, el libro La Guía del Refactor Cotidiano de Fran Iglesias (con edición especial de la Pulpo), folletos de publi / info de los patrocinadores, una mochila… Vamos, un señor Welcome Pack, aunque mi valoración no debería ser válida, al no tener experiencia previa.

En fin, una vez hechos estos trámites nos tomamos un café y un croissant en el estupendo espacio para los breaks (desayuno, parón de media mañana y comida) y nos dirigimos arriba, al auditorio donde, ahora sí, iba a empezar todo lo bueno.

Rolando Caldas (uno de los organizadores) se encargó de darnos la bienvenida, dar algunos datos del evento (211 personas!!!) y dar la primera charla, de título Mi Aplicación es un Monolito… ¡Y QUÉ!. La charla en sí no aportaba mucho, pues no dejaba de ser un vistazo a un código de Prestashop. Rolando intentó ser ameno pero entre el poco contenido que tenía el tema en sí, el madrugón y el horror de esas pocas líneas que se veían en la pantalla no pudo hacer mucho. Daba la sensación de ser algo de relleno y un calentamiento para lo que vendría después.

A las 11 subió al escenario Isabel Garrido, programadora en Letgo y experta en temas de testing. Su charla, Dobles de Acción Para Testing, fue bastante más entretenida. En mi caso, que acabo de empezar con el mundo del testing, pude sacar mucho provecho de su charla. En ella nos habló de los distintos dobles que podemos usar en testing, con ejemplos sencillos y una buena puesta en escena. Se la notó algo nerviosa al principio pero fue capaz de sacar adelante la charla y mantenernos a unos cuantos muy atentos a lo que estaba contando.

Tras esta charla hicimos el primer break. Un café para reponer pilas y vuelta al auditorio donde ahora venía una charla un poquito más densa. El encargado fue José Armesto, sustituto de última hora de uno de los ponentes, que nos habló sobre los famosos Kurbernetes. Su charla fue de más a menos, pero no por falta de calidad o conocimientos, si no porque la cosa se fue complicando y era mucho tema para tan poco tiempo. Yo me perdí por la mitad y ya no fui capaz de sacar nada más en claro. Pero el tema en sí era interesante, y José demostró ser un ponente con mucho ritmo y buen hacer.

Antes de la comida llegaba uno de los platos fuertes del día. Los chicos de CodelyTv, Javi y Rafa, subieron al escenario a revolucionar toda la movida. Su charla se titulaba Elige Tu Propia Aventura: Pasito a Pasito Driven Development y no engañaba en el título. Se curraron una “aventura” donde, cada pocos minutos, los del público votábamos hacía dónde nos dirigíamos. No teníamos que matar dragones o elegir izquierda o derecha, pero si que podíamos escoger la forma de solucionar los distintos problemas de arquitectura que se iban presentando en el código. Un código, por cierto, picado a un millón de clicks por segundo por Rafa usando todos los atajos posibles existentes y demostrando un control del PHPStorm tremendo. Mientras, Javi iba haciendo malabares para poder explicar todo lo que estaban haciendo. Una auténtica delicia de charla que se hizo corta (y a ellos también, que les quedaron un par de cosas por tratar) y en la que nos reímos y aprendimos a partes iguales.

LA COMIDA

Tras estas 4 charlas llegó la hora de la comida. Nos ofrecieron un catering bastante abundante y con uno de los mejores pulpos que recuerdo ¡Que lujazo! Tras ello fuimos a tomar un café en una terraza cerca del auditorio y nos pusimos de nuevo en marcha para las 2 últimas charlas de la jornada.

Empezó la tarde Mavi Jiménez, de Holaluz, con una interesante charla sobre cómo ha aplicado sus conocimientos de testing en su empresa (y lo que ha aprendido durante el proceso) titulada Be Smart My Test. No solo el contenido era interesante si no que Mavi supo llevar la charla con mucha simpatía y buen rollo para que la gente no se durmiese después del banquete: objetivo cumplido.

Para acabar la jornada llegaba la estrella de los ponentes, Carlos Buenosvinos, con Eventos, mensajería y otras fábulas. Carlos es el CTO de Seat actualmente y uno de los tíos que más sabe de esto en España. No defraudó, con una charla muy completa sobre gestión de eventos y arquitectura. Un colofón increíble que daba paso a la despedida y los sorteos (¡uno de ellos fue para mí!).

DESPEDIDA Y CIERRE

Tras una jornada muy intensa acabamos disfrutando de la Feria del Marisco en el puerto de Vigo para volver a casa a descansar y salir prontito por la mañana. Nuevamente unas pocas horas de viaje y llegada justo para comer.

Como resumen de la experiencia solo decir que, aunque no pueda comparar con eventos pasados, a poco que las próximas sean la mitad de buenas y divertidas (los compañeros de viaje ayudan mucho a esto) estaré más que satisfecho. Ha sido un placer, nos vemos en la próxima Pulpo Conf (o Morcilla Conf, o Cachorro Conf, o lo que toque…).