Trabajando con sitios web estáticos de información y de contenido

A la hora de plantear el construir un sitio web, por muy sencillo que sea, suele ser habitual que la primera propuesta que nos venga a la mente sea siempre la misma: WordPress.

Este artículo no pretende mostrar una herramienta que solucione todo lo que puede solucionar un CMS como WordPress. La idea es invitar a pensar en formas de trabajo más actuales y eficientes para publicar contenidos en un sitio web.

La era de los API

A lo largo de la última década hemos sido testigos de una evolución importante en la web que empezó a definirse en el año 2000 con la llegada de REST.

Los sitios web que utilizamos permiten integrarse unos con otros. Podemos hacer que contenido que publicamos en nuestra cuenta de instagram, strava o youtube se muestre automáticamente en otros sitios y servicios como Twitter.

Cada vez tenemos menos necesidad de almacenar contenido en el hosting en el que publicamos nuestros sitios web, sitios de comercio electrónico o blogs.

El contenido se crea y almacena de forma distribuida y el usuario cada vez tiene más libertad para elegir cómo hacerlo.

Herramientas como Zapier o IFTTT nos permiten crear flujos y automatizaciones entre diferentes servicios sin necesidad de programar.

Por ejemplo, podríamos subir una foto a instagram y que automáticamente se guarde en Dropbox, Drive o s3. Podríamos añadir una entrada en una hoja de Excel de Google y que automáticamente cree un evento en Google Calendar o en algún otro calendario de otro servicio.

Integración y despliegue continuos

En desarrollo de software funcionamos de una forma similar a lo que veíamos en el punto anterior.

Actualmente todos los desarrolladores de software y web utilizamos GIT. Si no conoces nada sobre repositorios GIT, puedes pensar en ellos como si se tratasen de una carpeta de Dropbox de tu ordenador, en la que puedes crear un archivo, este se sube a dropbox automáticamente, registrando todos sus cambios. La base de GIT es similar a la de Dropbox, sólo que es mucho más potente.

El código al que contribuimos se encuentra en un repositorio central de GIT que se aloja en algún servicio en la nube como Github, Bitbucket o Gitlab y cuando hacemos cambios en el mismo, estos cambios desencadenan una serie de pasos automáticos que pueden terminar en que se publique una actualización de la web sin tener que utilizar un cliente FTP.

A nivel profesional, otros profesionales como los traductores, diseñadores y escritores están empezando a utilizar GIT y a trabajar de esta manera.

Markdown y el formato sin contaminar

Cuando escribimos en un Word o en un editor de texto enriquecido de una web, estamos utilizando el formato final del documento que queremos enviar o publicar en la web.

Esto nos condiciona muchas veces a tener que trabajar con un tipo determinado de editor de texto que no siempre tenemos instalado en nuestra máquina y también nos obliga a aumentar el esfuerzo cuando queremos publicar en varios formatos con diseños o estilos muy distintos.

Markdown nos permite crear archivos de texto plano que luego podemos convertir en archivos HTML, docx o pdf con el diseño y formato que más nos convenga.

Cada vez más servicios y sitios web soportan escribir con Markdown descripciones y comentarios.  Y existen herramientas como pandoc que permiten convertir desde markdown a pdf, docs o html, incluso online.

La ventaja principal de tener un formato de origen sin contaminar es que se puede automatizar la publicación en diferentes formatos finales como HTML o PDF.

Como he comentado antes, cada vez más profesionales de disciplinas no tecnológicas empiezan a utilizar este tipo de herramientas y formas de trabajo, como podemos ver en este artículo de Mariana Eguaras sobre el tema.

Sabiendo todo esto, ¿realmente necesitamos una base de datos?

Hemos visto que podemos trabajar con un directorio que puede registrar nuestros cambios con GIT o Dropbox. Y también hemos visto que podemos escribir nuestro contenido en texto plano utilizando Markdown y generar a partir de ese texto, documentos en html, pdf o docx.

Por lo tanto con esto en mente, si trabajamos con un flujo de entrega continua o con una receta de Zapier que cuando creemos un archivo en nuestro Git o Dropbox con extensión .md (para indicar que es Markdown) nos genere automáticamente un archivo HTML y después lo suba a nuestro hosting web… ¿realmente necesitamos tener un WordPress con una base de datos si lo único que queremos es un sitio web con unas pocas páginas de contenido?

Es más, si tenemos nuestro contenido en base de datos, si en un futuro queremos consultarlo siempre vamos a necesitar tener que importarlo en una base de datos para exportarlo o verlo a través de un cliente o una web que se conecte a la misma.

Si nuestro contenido está en archivos de texto, vamos a poder verlo sin dificultad o grandes requisitos de software.

Alineados con esta filosofía de trabajo, existen cada vez más herramientas que nos dan soluciones en este sentido.

VuePress es una de ellas, pero podemos ver otras muy buenas alternativas como Hugo, Gatsby y muchísimas más.

VuePress

VuePress es una herramienta que se base en el framework de desarrollo Vue para poder generar sitios web estáticos de forma simple tomando como origen un directorio de archivos escritos en MarkDown. Inicialmente se diseñó para crear sitios estáticos de documentación, pero ahora mismo podemos crear portales de información sin limitación en el diseño.

Para poder utilizarlo, necesitas tener yarn en tu ordenador instalado. Si eres desarrollador probablemente ya lo tengas si no, lo puedes instalar fácilmente.

Después de instalarlo, únicamente debes ejecutar este comando una única vez, para futuros sitios web no hará falta hacerlo.

yarn global add vuepress

Una vez instalado vuepress en tu equipo, puedes tener un directorio con archivos .md que se transformarán en un sitio web estático.

Por ejemplo podríamos tener una estructura de directorios como esta:

├── readme.md
└── about.md
└── services.md
└── contact.md

El archivo “readme.md” sería el index y cada uno de los otros archivos .md se transformarán de .md a html.

Para poder trabajar en nuestro entorno local, podemos levantar un servidor web que nos montará la web “en caliente” en http://localhost:8080 sin tener que hacer nada. Cuando modifiquemos un archivo, la web se actualizará automáticamente.

Para levantar ese servidor web, podemos hacerlo con el comando:

vuepress dev

Con este comando podemos visitar la ruta http://localhost:8080/about.html y ver la información del about.md. También nos añadirá un buscador automáticamente.

Una vez terminado podemos generar el sitio web en html para poder subirlo a cualquier servidor que soporte html con el comando:

vuepress build

¿Y si no soy desarrollador ni me interesa la linea de comandos? ¿Puedo trabajar con VuePress u otra de las opciones que has mencionado?

Sí. Pero debes tener configurado un flujo de Entrega Continua.

Por ejemplo, en elComité, tenemos un flujo configurado para la nueva web que estamos creando para nuestra asociación.

En este flujo, cuando modificamos algo en nuestro repositorio de Github, el sitio web se actualiza automáticamente.

El trabajo con el contenido está totalmente separado del trabajo de diseño o maquetación. Si alguien del equipo únicamente necesita modificar el contenido no necesita tener que abrir el terminar si no quiere.

Esto lo conseguimos gracias a Netify, que permite integrarse con Github, Bitbucket o Gitlab. Netify es notificado cada vez que github se actualiza, generando un sitio web nuevo por cada cambio, sin necesidad de utilizar FTP. Soporta también dominios personalizados y certificados SSL, siendo totalmente gratuito para un único usuario.

En el caso de que se desee, cualquiera en el equipo puede tener funcionando el mismo sitio web que vería en producción sin necesidad de contratar o configurar un hosting o instalar nada raro en su ordenador; simplemente necesita abrir el terminal y ejecutar “vuepress dev”.

Si deseamos trabajar en el diseño, VuePress basa sus themes en componentes, que pueden ser diseñados y programados como si fuesen una aplicación web javascript al uso, consumiendo incluso servicios REST si lo necesitásemos.

VuePress y otras alternativas son muy potentes y te dan muchas características que se suelen necesitar para construir sitios web: templates, i18n (soporte para idiomas), buscador, soporte para SEO e incluso pueden generar sitios que funcionen offline sin conexión a internet.

Para necesidades más avanzadas, como la de poder enviar archivos o recoger emails para una newsletter, disponen de integración con servicios en la nube que ya te dan estas funcionalidades e incluso con servicios serverless basados en funciones que permiten programar acciones complejas a nivel de backend si fuese necesario.

Pero la idea principal es que al no necesitar base de datos, únicamente necesitaremos un hosting o un servicio cloud que sirva html por lo que el coste puede ser muy bajo o incluso cero si no tenemos grandes necesidades.

Conclusión

Mi objetivo con este artículo era el de mostrar que existen formas más modernas y mucho más eficientes a la hora de crear sitios web estáticos y de contenido.

Creo sinceramente que la era de los CMS como WordPress para crear sitios web y landings está llegando a su fin, gracias a que formas de trabajo que son el día a día en empresas de software como la Integración Continua, están llegando a otros sectores y profesionales.

Las herramientas como VuePress significan un gran avance para los desarrolladores de front en este sentido.

Estas soluciones les proveen de herramientas modernas para poder aportar de forma más eficiente a la creación de la nueva generación de sitios web y aplicaciones de información que veremos en los próximos años.

 

El perfil Paracetamol

Hace algunos años, compartía con un gran amigo y colega del sector varios botellines casi congelados de 1906 en una de las geniales terrazas que hay por Alameda de Hércules en Sevilla. En una de las conversaciones surgió que en su equipo había dos personas que cuando no estaban, el trabajo parecía no salir adelante.

Cuando había algún bloqueo o problema, por mínimo que fuese, el resto de sus compañeros tenían la costumbre de esperar a que llegasen esas personas que, lejos de sentirse “honrados” con su gran medalla de héroes, estaban hasta los mismísimos de que todo aparentemente dependiese de ellos.

Esta fue la primera ocasión en la que utilicé el término paracetamol para describir perfiles que “gozaban” de este rol.

Un perfil paracetamol oculta el dolor del equipo cuando hay problemas, por lo que muy pocas personas en la empresa son conscientes de que estos problemas existen hasta que estas personas no están o se van de la empresa.

El perfil paracetamol es muy distinto a otros perfiles heroicos que se sienten cómodos generando dependencias. Estas personas normalmente suelen ser gente extraordinariamente generosa, autodidacta y disponen de alta capacidad resolutiva. Precisamente por estas capacidades y su actitud de ayuda directa ante los problemas, si no se ponen los medios para detectar su sobrecarga de trabajo y limitarla, las consecuencias podrán ser problemáticas para ellos pero especialmente críticas para la empresa.

Existen formas para evitar que se pueda crear una cultura paracetamol-first en una empresa, las siguientes son algunas que he visto funcionar a lo largo de mi carrera profesional.

Cultura de documentación

Una empresa, sobretodo una empresa que crea productos de software, no se puede permitir centralizar el conocimiento en islas humanas.

Crear una cultura de documentación en la empresa es algo vital para evitar dependencias a nivel de conocimiento.

Esta documentación debe ser fácilmente accesible y actualizada. Y debe cubrir desde aspectos organizativos y de procedimientos de la organización hasta las especificaciones técnicas de cada proyecto.

Metodologías y herramientas de documentación activa a nivel de código o producto de software como BDD (Aplicando StoryBDD y cuidando las narrativas), SBE e incluso Swagger (o Blueprint) son muy útiles para exponer la funcionalidad de los productos de forma automatizada.

A nivel de repositorios, todos los proyectos deberían contar con:

  1. Un buen Readme con un índice que recoja los siguientes puntos
  2. Cómo arrancar el proyecto
  3. Cómo probar el proyecto
  4. Qué dependencias tiene el proyecto
  5. Qué versión y requisitos tiene este proyecto

En una empresa dedicada 100% a producto, debería haber una persona dedicada a asegurar esta cultura y gestionar esta labor.

La cultura de documentación no implica sólo documentar los proyectos o formas de trabajo, sino también el consultar la documentación antes de coger el teléfono o levantarse de la silla para interrumpir al compañero.

Este punto es especialmente importante si se trabaja de forma remota, con equipos distribuidos o en proyectos open source.

Medir los cambios de foco y limitar el WIP

En metodologías como Kanban y Scrum el WIP, work in progress, es uno de los conceptos más importantes y que permiten mejorar la eficiencia de un equipo.

Normalmente en los entornos paracetamol-first el WIP no se limita en absoluto, de hecho puede tender al infinito. Es clave que el foco no se diluya en varias tareas simultáneas. Limitar por ejemplo a una o dos tareas concurrentes por cada miembro del equipo suele ser una buena práctica para conseguirlo.

Otra medida útil es medir las interrupciones que tiene cada miembro del equipo. Cuando se hace y se presentan los datos en las retrospectivas al final de cada sprint, muchas veces sobran las palabras.

Hacer partícipe al equipo en las decisiones y diseño de soluciones

En mi opinión, todo desarrollador de software debería tener el skill o rol de arquitectura de software. Hacer partícipe de la visión global a todos los equipos es algo fundamental para que las personas no se queden limitadas o “cómodas” en su nicho.

En SCRUM existe el rol de Scrum Master. Cuando surge algún problema o necesidad de toma de decisión, el Scrum Master no debe lanzarse a solucionar el problema directamente; en su lugar debe guiar al equipo para que entre todos, encuentren la mejor solución, aunque ella o él la tengan clara. Hagamos SCRUM o no, me parece muy interesante esto y creo que es muy valioso para evitar estos perfiles.

Evitar ser líderes paracetamoles

El peor paracetamol es un dueño de la empresa al que le cuesta delegar o un líder que se carga peso de ejecución, ocultándolo al equipo y a las métricas.

Cuando eres el dueño de tu negocio y te apasiona lo que haces puedes caer muy fácilmente en esto y hacer que tu empresa dependa enteramente de ti.

Es importante desconectar y medir la productividad a nivel de entrega de valor cuando tú no estás en tu negocio.

Muchas personas creen que su equipo no es productivo cuando ellos no están físicamente en la oficina, pero la realidad es que no han puesto los medios para que estas personas puedan serlo o no disponen de la suficiente información para poder hacer su trabajo.

Exigir y respetar el tiempo fuera del trabajo

Los perfiles paracetamoles son propensos al workaholismo y por ello es importante que no se extienda una cultura en la empresa en la que se promuevan invertir horas extras o trabajo fuera de un rango horario.

Se suele decir que el máximo productivo de un desarrollador es de seis horas al día. Debería ser un objetivo que durante esas seis horas ese profesional tenga el foco puesto en entregar valor y optimizar la gestión de los proyectos para que esto sea la norma principal.

Todas las herramientas e información deberían ser fácilmente accesibles

Si hay impedimentos para poder disponer de la información o herramientas para realizar el trabajo, por ejemplo si se necesitan utilizar desde una aplicación móvil o fuera de la red local de la oficina, es muy posible que ese trabajo se delegue en otras personas y por lo general, en una cultura paracetamol-first, siempre serán las mismas.

Cultura de trabajo en remoto

No todas las empresas ni personas tienen por qué trabajar con una cultura de remote-first, pero establecer los mecanismos para hacerlo puede asegurar que todos los puntos anteriores se cumplan.

En una cultura remota es clave el medir y gestionar la comunicación de forma asíncrona, cada miembro del equipo debe poder realizar su trabajo de forma autosuficiente y contar con toda la información para poder hacerlo, por lo que no es un buen entorno en el que puedan crearse perfiles paracetamoles.


Apuntes interesantes

Dejo por aquí algunas opiniones y apuntes interesantes que he recibido por Twitter sobre este artículo.

 

Principios SOLID

A pesar de que existe mucho material escrito sobre este tema, en mi día a día me encuentro con software diseñado desde cero sin tener en cuenta algunos o ninguno de los principios SOLID.

Los principios SOLID son la base para diseñar software que sea flexible, testeable y fácil de mantener.

Algunos están ya bastante asumidos por la comunidad de desarrollo, otros no tanto.

En este artículo explicaré cada uno de estos principios con simples ejemplos que representan escenarios típicos de nuestro día a día.

Single responsability

Una clase debería tener una única responsabilidad.

Este principio quizás sea aparentemente el más sencillo de entender. Aun así, son frecuentes las implementaciones que se lo saltan, incluso de forma intencionada.

Un ejemplo de implementación que se lo salta es la de Active Record que se implementa en el ORM de RubyOnRails, cuyos modelos suelen ser propensos a atraer responsabilidades ajenas a las que deberían tener.

Un ejemplo parecido de esto sería este código


class Message {

  public function setFrom( Person $person ) {}

  public function setTo( Person $person ) {}

  public function send() {}

}

En este código, vemos que una clase mensaje implementa el método “send” para enviarse a sí mismo. Sin embargo, esta responsabilidad debería ser delegada en un objeto cuya labor sea enviar.


$user1 = new Person( "Asier" );

$user2 = new Person("Thor");

// componemos el mensaje
$message = new Message();

$message->from( $user1 );

$message->to( $user2 );

// enviamos el mensaje mediante un Sender
$sender = new SMSSender();

$sender->send( $message );

$sender = new EmailSender();

$sender->send( $message );

Como vemos en el código anterior, la primera ventaja de separar en responsabilidades nuestro código reside en que podemos tener flexibilidad a la hora de trabajar con nuestros mensajes sin cambiar el código de las clases que los representan.

En un principio quizás hayamos definido que nuestros mensajes se enviasen por email, pero si quisiéramos enviar por otros medios, deberíamos hacer cambios en nuestra clase Mensaje para poder implementar cambios en este sentido.

En muchas ocasiones, el aplicar estas modificaciones a las clases para poder mantener responsabilidades que no son las suyas las hacen magnéticas a más responsabilidades.

Por ejemplo si seguimos la estrategia de mantener responsabilidades en la clase Mensaje, esta podría también ser susceptible de implementar el método “save”, para guardar el mensaje en base de datos. O el método “print” para imprimirlo. Sin embargo, el otorgar de estas responsabilidades a la clase Message, conllevaría saltarse este patrón corriendo el peligro de limitar la flexibilidad, propiciar la aparición de código redundante a futuro (por ejemplo: necesidad de implementar métodos “save” o “send” en diferentes clases que no tienen ninguna base común entre ellas, utilizando la herencia de forma incorrecta con clases abstractas) y aumentar el coste de mantenimiento de nuestro software.

Open-close

El principio abierto-cerrado es para mí una de las lecciones más importantes que he aprendido como desarrollador de software.

El objetivo a conseguir es hacer extensible tu código sin tener que modificarlo.

Pongamos el siguiente ejemplo que no respeta este principio:


class SenderFactory {

  public function createFromProtocol( $protocol ) {

    switch ( $protocol ) { 

      case 'sms':

        return new SmsSender();

      case 'email':

        return new EmailSender();

    }

  }

}

$factory = new SenderFactory();
$sender  = $factory->createFromProtocol('sms');

$sender->send( $message );

En esta típica clase de Factoría, tenemos un Switch/Case para crear cada uno de los Sender a los que dará soporte. Si quisiéramos añadir un nuevo tipo de Sender, deberíamos añadir otro case más para el mismo, teniendo que modificar la clase por cada extensión.

Para conseguir respetar el principio Abierto-Cerrado, deberíamos seguir los siguientes pasos:

1) Crear una interfaz para los objeto Sender

interface SenderInterface {

  public function send();

}

2) Crear un sistema para poder añadir de forma externa las diferentes implementaciones de Senders en la factoría. Un ejemplo simplificado (no utilizar en producción):


class SenderFactory {

  private $_senders = [];

  public function createFromProtocol( $protocol ) {

    if( isset ($this->_senders[ $protocol ] )  )

      return new $this->_senders[ $protocol ];

    thrown new Exception("there is any sender for " . $protocol);

  }

  public function addSender( $protocol, 
                             $senderClass ) {

    $this->_senders[ $protocol ] = $sender;

  }

}

De esta forma podríamos añadir de forma externa sin preocuparnos de tener que tocar el código de la factoría:


$senderFactory = new SenderFactory();

$senderFactory->addSender( 'sms', SmsSender::class );

$senderFactory->addSender( 'email', EmailSender::class );

$sender = $senderFactory->createFromProtocol( 'sms' );

$sender->send( $message );

Liscov sustitution

“Sea ϕ(x) una propiedad comprobable acerca de los objetos x de tipo T. Entonces ϕ(y) debe ser verdad para los objetos y del tipo S donde S, es un subtipo de T.”

Bárbara Liskov

El principio de sustitución de Liscov es uno de los que más frecuentemente se suelen saltar.

Básicamente lo que dicta es que si una clase hereda de otra, el funcionamiento de la aplicación no debería verse afectado si esta es sustituida por su clase padre.

Esto también relativo a las interfaces. Si una clase que implementa una interfaz es sustituida por otra que implementa esa interfaz, el comportamiento no debería verse afectado.

Esto conlleva varias cosas:

  • Los métodos públicos de la clase hija y padre deberían ser exactamente los mismos
  • Los métodos deberían devolver los mismos tipos de datos
  • Lo que se exprese en un método abstracto o no, en la clase padre o la interfaz, debería ser lo que este método realice, sin sorpresas extrañas.

Un ejemplo sobre este último punto: si tenemos esta interfaz


interface SenderFactoryInterface {

  public function createFromProtocol( $protocol );

  public function addSender( $protocol, 
                             SenderInterface $sender );

}

Esperamos que las clases que implementen la SenderFactoryInterface puedan crear un Sender que hayamos cargado en la misma.


class SenderFactory implements SenderFactoryInterface {

  public function createFromProtocol( $protocol ) {

    if ( !$this->checkIfMeetsSomeCondition( $protocol ) ) 

      thrown new Exception ( 'Protocol not supported' );
    ....

  }

}

En este ejemplo vemos que hay una condición interna en el método createFromProtocol que decide si funcionar o no con un tipo de protocolo. Esto viola el principio de sustitución de Liscov ya que otra clase que implemente SenderFactoryInterface no tiene por qué contemplar esa condición y esto puede derivar en inestabilidad del sistema al cambiar de SenderFactory.

La idea como conclusión es que debe respetarse lo que define una interfaz o una clase padre, sin añadir ni exponer funcionalidad adicional que esté fuera esa definición.

Interface segregation

“Clients should not be forced to depend on methods they do not use.”

Robert Martin

Al seguir el principio de Segregación de interfaces debemos asegurarnos de que una dependencia que inyectemos en una clase no muestre métodos que no se necesiten o no tengan sentido para lo que pretendemos hacer.

Por ejemplo, si tenemos una interfaz que define cómo podemos extraer y guardar datos de un sistema de almacenamiento:


interface StorageManagerInterface {

  public function getItems();

  public function save( EntityInterface $item );

}

Y tenemos una clase que necesite leer datos de ese sistema para imprimirlos:


class PrintService {

  public function printLines( StorageManagerInterface $storage ) { }  
 
}

Dentro del método printLines no nos interesa guardar nada en el sistema de almacenamiento. De hecho, sería peligroso hacerlo en ese método, ya que se supone que no vamos a hacer ninguna manipulación, sólo deberíamos imprimir los datos que nos traigamos del sistema de almacenamiento.

Para no saltarnos el principio de Segregación de interfaces, deberíamos separar las operaciones de lectura y escritura en dos interfaces distintas. Si por alguna razón necesitásemos ambas operaciones en alguna clase, podríamos tener otra interfaz que implemente dichas interfaces.

Nuestro PrintService ahora ya tiene únicamente los métodos que necesita como vemos en el siguiente ejemplo.


interface StorageReaderInterface {
  
  public function getItems();  

}

interface StorageeWriterInterface {

  public function save( EntityInterface $entity );
}

interface StorageManagerInterface
  implements StorageReaderInterface, StorageWriterInterface {
}

class PrintService {

 public function printLines( StorageReaderInterface $storage ) { } 
 
}

Dependency inversion

La idea de la inversión de dependencias es que nuestro código dependa siempre de abstracciones, no de clases concretas.


// incorrecto
class NotificationService { 
  
  public function __construct( EmailSender $sender ) { 
    ... 
  } 

}

// correcto
class NotificationService {

  public function __construct( SenderInterface $sender ) {
    ...
  }

}

En el ejemplo superior vemos cómo respetar este principio y que al inyectar la interfaz SenderInterface, le damos más flexibilidad pudiendo cambiar en un futuro el tipo de Sender sin tener que modificar el código.

Sin embargo, pasar una interfaz no es lo único recomendable. Suele ser habitual que utilicemos interfaces de un framework que utilicemos para desarrollar nuestro código.

Esto nos genera una dependencia con el framework, lo cual puede ser un problema si luego queremos reutilizar código separándolo en un paquete independiente.


class LoggerService { 

  public function __construct( Framework\EventDispatcherInterface $dispatcher ) {} 

}

Lo ideal sería crear nuestra propia interfaz e implementarla en una clase que haga uso de la interfaz que nos provee el framework. Esto nos permite cambiar en un futuro de framework sin que nuestro código se vea afectado.


class FrameworkEventDispatcher 
             implements EventDispatcherInterface {

  public function __construct(Framework\EventDispatcherInterface $dispatcher) {}
}

class LoggerService {

 public function __construct( EventDispatcherInterface $dispatcher ) {}
 
}

$logger = new LoggerService( new FrameworkEventDispatcher() );

Conclusión

Los principios SOLID nos permiten diseñar nuestro software para que después de evolucionarlo y mantenerlo durante años no se convierta en una mala partida de Tetris.

Si tenemos la mente abierta incluso podemos aplicarlos fuera del código o incluso del mundo del software, en otras disciplinas y artes creativas.

Cambio de mochila

Tengo una especie de ritual cada vez que cambio de etapa profesional y consiste en cambiar también de mochila. No se trata de algo metafórico, literalmente cambio la mochila en la que suelo llevar el portátil.

Este año he elegido cambiar de mochila. Es la tercera vez que lo hago. Después de diez años como autónomo, tres empresas creadas y siete años trabajando en remoto, desde Febrero he comenzado una nueva etapa profesional.

A final del verano del año pasado tomé la decisión de apostar por el cambio y ha sido interesante el participar en procesos de selección de varias empresas, algunas no españolas.

Vivimos en un momento increíble en el que trabajar como desarrolladores de software. Las empresas están cambiando hacia modelos más eficientes, distanciándose de formas de trabajar obsoletas que van radicalmente en contra de modelos actuales como el trabajo en remoto con equipos distribuidos y la mejora continua.

Buscaba ser partícipe aportando a este cambio y también, afrontar retos tecnológicos realmente ambiciosos. Y actualmente los estoy encontrando en Versia, como responsable del área de arquitectura de software.

No puedo decir que este cambio sea sencillo, pero tampoco es que estuviese acostumbrado a cosas sencillas. Pasar de trabajar desde un pueblo en mitad de viñedos en La Rioja a una oficina con doscientas personas desarrollando software está siendo un reto de adaptación bastante interesante.

Este año he empezado también a mentorizar tanto a nivel de desarrollo como a nivel de gestión de producto. No lo había hecho en serio hasta la fecha, pero es muy enriquecedor.

Debo mencionar que también he cambiado en la forma en la que veo a la comunidad de desarrollo de software en España.

Cada vez conozco a más desarrolladores con ganas de trabajar mejor y preocupados no sólo por adquirir conocimiento en herramientas tecnológicas sino también en mejorar de forma sincera sus soft-skills a nivel emocional. Y al margen de sueldos, estos perfiles no aceptan trabajar de cualquier forma.

Esto fuerza a que las empresas españolas deban espabilar para conseguir y retener talento. Otras empresas de fuera de España que se están afincando en Barcelona y el sur de España están viendo una oportunidad en esto y se empieza a notar en la comunidad, lo cual creo que es algo positivo.

Sin embargo también veo más postureo de buenrollismo y charlas orientadas a currículum. Me faltan charlas fuera de palabras clave actuales, más relacionadas con producto desde la experiencia real, refactoring de proyectos legacy críticos… y también me falta escuchar a más personas que normalmente no suelen estar tanto en el radar.

Y en este sentido, esperamos también aportar desde elComité nuestro granito de arena. Desde hace un año estamos trabajando en este sentido y nos gusta también hacerlo en compañía de otras comunidades, fuera incluso de Euskadi.

De momento, esto es todo. Llevaba tiempo sin escribir en el blog, en parte por la duda de si este tipo de entradas aportan valor. Todo feedback es bienvenido :)

 

 

 

 

 

 

 

La importancia de respetar a quien comparte

En las comunidades relacionadas con el mundo del desarrollo de software tenemos una cosa muy buena y es la gente que se anima a compartir su experiencia, lo que ha aprendido e incluso código para que otros desarrolladores puedan aportar valor en su día a día, sin privarse de invertir tiempo con los suyos.

Cuando tratamos con seres humanos siempre hay conflictos, cada comunidad tiene sus puntos de vista, prioridades y temáticas que se consideran más o menos prioritarias e importantes. También hay egos, malentendidos y estos se incrementan gracias a Twitter, que puede llegar a actuar como un auténtico detonador y dispatcher de basura.

Esta semana Josue Yeray ha compartido las causas de su burnout como ponente y aunque habla de las comunidades .net, he visto cosas parecidas en otras de otras tecnologías e incluso fuera del sector, en sectores que no tienen nada que ver, como el de la traducción.

Yo mismo he sufrido este burnout. Creo que lo más lamentable que he sufrido fue cuando el años pasado otro ponente apoyó su charla en criticar a la mía en el mismo evento. No me importan los chascarrillos o incluso los hachazos, pero no los tolero cuando van con el objetivo de pisar al otro. No necesito esto. No estoy en un evento ni quiero crear comunidad para esto.

Esta experiencia y otras me hicieron reflexionar y pensar si tenía sentido el participar en este tipo de eventos en los que parece que estamos perdiendo la perspectiva de compartir para en su lugar, tratar de competir por lo que sea.

Lo importante es compartir

¿Por qué compartimos? No creo que haya una única razón. En ocasiones he escuchado que es porque tenemos ego y en algunos casos, es un motivante real que hay que gestionar en la comunidad. Pero creo que aunque en esos casos ese sea el motivante inicial, poco a poco te das cuenta que tienes más que callar que hablar. Y te das cuenta porque conoces a gente, gente que nunca ha dado una charla que te enseña más con una cerveza en la mano que en toda una conferencia.

En serio, he compartido cervezas* post-evento que me han llevado después a búsquedas de Google que me han tenido leyendo durante horas, invirtiendo unos euros en la Kindle Store, LeanPub o en Safari Books Online, para crecer un poco más como desarrollador de software. Y lo más importante, he conocido a personas geniales.

Por lo que los ponentes, hablo por mí al menos, creo que con el tiempo tendemos cada vez más a dejar la idea clave que genere debate en las preguntas o cañas de después. Más que nada porque todo el mundo tiene algo que aportar y el ponente también puede recibir valor en el evento.

En los eventos no se comparte solo en las charlas. Las charlas siempre son la excusa para ir y conocer a un montón de gente interesante.

Valorar lo que se expone y a quien expone

Cuando organizas eventos de comunidad, sobre todo si son constantes, te das cuenta de la importancia de contar con gente que se anime a dar charlas.

Muchas veces son los organizadores los que repetidamente dan charlas porque en su comunidad no surgen voluntarios.

Por eso para mí, independientemente del nivel de la charla, alguien que se sube al escenario para hablar a 10, 300, 1000 personas, tiene mi respeto.

A menos que te dediques a dar charlas, impartir una ponencia supone encontrar espacio de tiempo para preparar el tema: recopilar mentalmente tus conocimientos y experiencia sobre el tema, estructurarlo para exponerlo sin aburrir en el tiempo que tienes, buscar información y recursos que complementen a aporten valor en los slides y por supuesto, ensayarla una y otra vez para asegurarte de que transmites bien la idea sin pasarte de tiempo.

Todo esto se complica porque tienes trabajo y una vida a la que atender. Al margen de tus deadlines, entregas, marrones de tu día a día, tienes en mente la charla que debes dar y hasta que no la das, estás con ella en la cabeza, por muchas tablas que tengas.

Por todo esto, creo que alguien que tome la iniciativa y se anime a compartir, debe ser respetado y valorado. Sobre todo si es constante, la constancia es oro.

Tú también puedes exponer

Como he comentado antes, suele pasar que a veces el motivante de querer dar una charla sea el ego. Esto genera conflictos o frustración entre miembros de la comunidad que quieren visibilidad en eventos grandes.

A veces esto va relacionado con la expectativa de hacer marca personal o currículum a base de dar charlas. Esto pasa mucho sobre todo en temáticas de moda o que tienen más tracción.

Podemos entrar a debatir si esto es bueno o malo. Sin embargo, aunque el objetivo de un profesional sea faisanear hacer marca personal, si el resultado implica que la comunidad se alimente de su experiencia y conocimiento, para mí no me parece algo malo.

Sí que veo problema cuando esto lleva a criticar o crear mal rollo en la comunidad ante la frustración de no disponer de una oportunidad para hablar.

Pero lo cierto es que hay oportunidad para hacerlo. Como dice Yeray, puedes participar en comunidades que estén deseando que alguien se anime a dar charlas (hay muchas más de las que se cree) e ir cogiendo tracción y soltura.

Si no te identificas con una comunidad en concreto o no conoces ninguna, puedes montar una tú con la gente que conoces. Al final, se trata de crear un movimiento.

También dispones de un canal brutal para empezar: YouTube. En serio, se pueden hacer infinidad de cosas e ir cogiendo tracción.

Pero sobre todo creo que lo importante es conocer a gente de fuera de tu círculo y descubrir que lo importante, al margen de marcas, es compartir y crecer en conjunto.

*Nota: con respecto a las cervezas en los eventos, no me refiero a tener que beber únicamente alcohol. A mí me encanta la cerveza y creo que es algo común a muchos desarrolladores, pero no es exclusivamente a lo que me refiero. Es interesante leer el artículo de Pablo Godel sobre el alcohol en conferencias.

 

 

 

 

 

 

 

Cosas que he aprendido en 2016

El equilibrio lo es todo.

Es el verdadero éxito. Pero no quiero sonar como un abraza-árboles, creo que se puede tener los pies en la tierra, buena economía y satisfacer tus necesidades creativas. Esta misma semana Derek Sivers ha escrito sobre el tema.

Con salud y conocimiento, tú pones las reglas de cómo vas vivir.

Y relacionado…

Si algo es demasiado difícil puede ser un síntoma de que lo estás haciendo mal.

Que algo te resulte demasiado difícil durante un periodo largo de tiempo, es un síntoma de que posiblemente estés obcecado en hacerlo de una forma enrevesada y haya un camino más fácil o puede que otro momento más adecuado.

Actualmente, para hacer funcionar un negocio SaaS (Software como servicio) necesitas un canal de venta.

Sin un canal de venta, vas a tener únicamente un producto SaaS difícil de vender.

No obstante, aunque vendas poco, puede ser factible alcanzar tu objetivo si este es simplemente conseguir una vía adicional de ingresos recurrentes en lugar de buscar crecer exponencialmente como quien buscó El Dorado.

Pero hay que saber qué es lo que quieres y si quieres un negocio que crezca, necesitas un canal de venta sí o si.

Las personas que viven, cambian.

Y hay momentos en los que puedes encontrarte (de verdad) con personas que ya estaban a tu lado.

Todo el que hace, merece respeto.

Nada más que añadir.

La constancia es la mejor aptitud.

La constancia hace que las cosas se hagan y crezcan. Y que las personas que la aplican, crezcan también.

Twitter mola, si eliminas todo el input negativo.

Mi relación amor odio con Twitter ha llegado a su fin. He aceptado que ya no se puede usar como lo usábamos en el 2007 y he tomado la decisión de hacer unfollow a toda persona que era constante en expresar negatividad.

No me malinterpretéis, no me gusta la falsa positividad, de hecho la aborrezco y creo que es la raíz del odioso postureo actual. Sin embargo, creo que entrar a Twitter a aportar negatividad, quejas o cosas similares exclusivamente es lo fácil, sobre todo si no van acompañados de autocrítica.

En ese sentido me gusta más instagram y me resulta curioso ver que personas que se quejaban continuamente de todo en Twitter, en instagram parecen felices. Que sea real o no, es su problema, pero no me apetece estar en un canal para consumir mal rollo.

Yo he pecado de esto también e intento no caer en ello. Obviamente esta es simplemente mi opinión.

El feminismo es lo más importante que debes respetar como ser humano en estos momentos.

Sobre todo si no estás a gusto cuando ves actitudes claramente machistas o crees que el feminismo es una palabra mal elegida, es importante (y enriquecedor) abrir la mente y leer sobre el tema.

Probablemente te hayas encontrado con postureo (en Twitter), con quien escribe barbaridades (sin poner su nombre real) para provocar a quien no está en su misma línea de pensamiento, con quien se fustiga (en Twitter) por ser hombre, con quien lo mezcla con otros temas como política, veganismo etc. y con quien sube vídeos diciendo gilipolleces como que los “feministas follan mejor” o “tienen más sexo“. Yo he visto las cosas de forma distinta cuando he empezado a ignorar todo esto.

Existe literatura escrita sobre el tema, pero para mí lo más interesante ha sido el conocer e investigar figuras femeninas que han hecho cosas relevantes a lo largo de la historia(relacionadas o no con el feminismo) y fueron obviadas totalmente e incluso asesinadas miserablemente.

También hablar con mujeres de todo tipo sobre su visión de este tema te va a aportar cosas que igual todavía no ves de forma clara. Poco a poco vas a entender realmente que nos han educado según una cultura con base fuertemente católica que no respetaba la igualdad y empezarás a ver más cosas sutiles en tu día a día que no te van a gustar, con las que no estás cómodo, al igual que no te gusta ni estás cómodo con el machismo más evidente.

Aunque hay quien es agresivo a la hora de hablar este tema, en mi opinión no tienes por qué estar de acuerdo con todas las opiniones sobre el mismo, pero el que abras los ojos es importante para que el mundo sea mejor y seamos mejores como sociedad.

YouTube es un canal muy potente e interesante.

La verdad es que una cosa que este año he investigado y me resulta bastante interesante, hay contenido muy bueno si lo sabes buscar y tengo previsto hacer pruebas con este canal durante el año que viene.

deSymfony2016

Hace unos días pudimos disfrutar de la conferencia más importante de habla hispana sobre Symfony y su ecosistema. Llevaba tres años sin celebrarse y lo echábamos de menos.

Para mí, deSymfony no es solo una conferencia, es una comunidad. Una comunidad brutal. Es poder volver a ver y charlar con personas excepcionales a nivel profesional y personal.

Personas que empezamos siendo contactos y hemos acabado siendo grandes colegas profesionales e incluso amigos. Hasta tal punto es esto, que hay personas que acuden a la conferencia para compartir unos minutos con esta gente aunque ya no trabajen con Symfony o php siquiera.

Y los organizadores. Es impresionante lo que han creado y su preocupación para que todo salga bien y darnos el mejor trato posible. David Castelló, Javier López, Javier Eguiluz, Marcos Labad, Nacho Martín y también Ariel Ferrandini, son auténticos héroes no solo por hacer un evento como este, sino por cuidar de esta comunidad y escucharla.

Este año tenía como objetivo tomarme un descanso de dar charlas pero la excepción ha sido obligatoria para este evento.

Se me había olvidado la presión por el nivel del resto de ponentes y de los asistentes. Y es que deSymfony se caracteriza porque cualquiera de los que están entre el público puede dar una ponencia de nivel.

He echado en falta a grandes amigos que no pudieron venir a España para acudir a esta cita, espero poder volver a verles pronto para compartir un café o unas cervezas.

Ahora solo queda esperar al próximo deSymfony, que estaría genial volver a disfrutarlo en una ciudad más pequeña que Madrid o incluso en algún pueblo de los que tenemos repartidos en España, para que la experiencia sea tan brutalmente buena como lo ha sido hasta la fecha o incluso mejor.

Trabajar en remoto

10748111_1534441890135825_555708309_n

Hace unas semanas leí un genial artículo de Jurgen Appelo que llevaba el título “Stop remote working“.

En dicho artículo el autor defiende la idea de que a veces se dice que decimos que trabajamos en remoto, como si estuviésemos trabajando en un sitio diferente al que deberíamos trabajar. Y es que si podemos trabajar desde cualquier lugar con conexión a Internet y visado, el mundo entero debería ser nuestra oficina.

Estamos hartos de escuchar el término “nómada digital” como si fuese una doctrina a seguir, pero realmente esto es solo una elección en la forma en la que trabajas. No necesitas ser un nómada, ni trabajar en remoto pero si quieres, puedes hacerlo.

De hecho hay personas que no quieren trabajar en remoto. Muchas personas valoran el ir a una oficina y ver cada día a las personas con las que trabaja en equipo. Esto es muy respetable y de hecho comprensible, es muy importante ver físicamente a las personas con las que trabajas. Comentaré más adelante en detalle sobre esto.

También hay personas que no están preparadas para hacerlo. Yo mismo no lo estaba la primera vez que estuve trabajando como empleado en remoto y también como autónomo. Tuve que aprender con el tiempo, sufriendo las consecuencias de malas prácticas en cuanto horarios, elección de clientes/proyectos y comunicación.

Valoro mucho haber pasado por la experiencia ya que con la misma he conseguido finalmente tener control sobre mi vida mejorando como profesional y también como persona.

Esta experiencia también me ha hecho fijarme en otras aptitudes distintas a las técnicas y más cercanas a las personales cuando elijo con quién quiero trabajar, ya sean clientes, proveedores, socios o colaboradores.

En los últimos años he trabajado con muchos clientes, incluso con reticentes a trabajar en remoto. Es cierto que aún queda mucho para que sea lo normal no solo en España, sino en todo el mundo. Creo que esta reticencia es algo cultural y de hecho, la cultura de la propia empresa ha de adaptarse poco a poco a este cambio.

Cuando trabajamos de esta forma, desde fuera muchas veces pareciese que estemos totalmente solos. Que estuviésemos inmersos en una clase de burbuja-locura que de un momento a otro nos vaya a provocar una especie de “fiebre de la cabaña”, como a Jack Torrance en El Resplandor.

Pero la realidad es que lejos de trabajar solos, tenemos un ecosistema virtual montado en el que pasan muchas cosas cada día. Estamos en constante comunicación con profesionales de diferentes culturas y países, resolvemos varios problemas a lo largo de la jornada y todo ello sin dejar enfriar el café.

Voy a centrarme en explicar mi punto de vista sobre algunas de las cosas que más me suelen preguntar sobre este tema y después os presentaré un proyecto en el que hemos estado trabajando Diego Rodriguez y yo en las últimas semanas con el objetivo de que si quieres, puedas trabajar en una ciudad distinta cada día.

Herramientas

Creo que nunca hemos tenido tantas opciones y herramientas que faciliten la comunicación entre los miembros de un equipo. Tenemos Slack, Trello, Evernote, Basecamp, Telegram y un largo etcétera de opciones con app móvil multiplataforma y mensajería IM. Incluso tenemos teléfono.

Pero el problema no está en la herramienta, sino en la comunicación. Existiendo comunicación, puede servir perfectamente un archivo de texto plano compartido por dropbox.

Dicho esto, personalmente prefiero Evernote o Slack junto a Skype o appear.in, pero hay miles de opciones más.

Comunicación

Es clave que la gente con la que trabajes sepa comunicar bien, tanto por escrito como por audio. Esto también incluye clientes y proveedores.

La comunicación es algo caro en dinero, en tiempo y a veces, también en salud.

Para mí comunicar bien se puede resumir en lo siguientes:

  • No mentir
  • Si hay algún problema, necesitas ayuda o hay algo que no sabes hacer, decirlo cuanto antes.
  • Si utilizas la ironía o eres “gracioso”, tener en cuenta la cultura del receptor, que puede no estar acostumbrado a tus bromas. Especialmente si no le estás viendo la cara.
  • Si no se entiende algo, preguntar, aunque sea quinientas veces.
  • No divagar e ir al grano cuando se está discutiendo algo en concreto.
  • Y lo más importante, no guardar silencio durante días por verse saturado.

Sensación de avance

Este es el punto en el que más insisto cuando trabajo con más gente en remoto, y va muy unido al tema de la comunicación.

Lejos de buscar tener un control obsesivo de cada parte del proyecto, considero importante compartir y actualizar todas las tareas en las que el equipo está trabajando, indicando quién está encargándose de cada una. También es importante ver cuáles se han completado.

Que cada miembro del equipo vea que se están haciendo cosas y quién está haciendo qué, creo que es lo más importante para tener motivación y la sensación de que el barco está realmente en ruta avanzando hacia algún sitio .

En metodologías ágiles existe el concepto de “daily“, una reunión breve en la que el grupo se reúne diez minutos cada día para ver lo que se ha hecho, lo que se va a hacer y si hay algún problema a solucionar.

En algunas ocasiones, no es posible reunirse cada día, pero sí que veo crítico hablar cada semana al menos.

Aunque trabajemos en remoto, también es importante verse en persona cada cierto tiempo. Por muy acostumbrado que estés trabajando solo, nada te carga más las pilas y te da la sensación de estar realmente en un equipo que el ver físicamente a las personas con las que trabajas día a día. No solo para firmar en una notaría cosas o discutir sobre cómo implementar una funcionalidad, sino también para recordar batallitas compartiendo unas cervezas.

Horarios

Realmente esto es lo que menos me preocupa cuando trabajo con más gente en remoto.

Aunque viene siempre bien una ventana de al menos una hora en la que coincidamos, tampoco es algo relevante para mí si hay buena comunicación por escrito.

Como nota personal y aunque sea tentador, si que recomiendo no trabajar de noche. Es genial no tener interrupciones telefónicas o de otro tipo, pero también tu vida social puede verse tocada, siendo muy fácil caer en una rutina en la que pasen días sin que hables con otras personas.

Cuando tengo que realizar labores que me exijan foco o creatividad como por ejemplo programar o diseñar, he aprendido que es mejor tener horarios para responder mensajes de email, llamadas o de mensajería y respetarlos rigurosamente antes que quedarse toda una noche programando.

Lugares y personas

Yo no soy nómada. Aunque me suelo mover bastante, por lo general suelo estar trabajando y viviendo de continuo en una ciudad determinada y luego cambio al cabo de un par de años. Me gusta esta libertad y seguramente en algún punto de mi vida decida quedarme en una ciudad ya “para siempre”.

Normalmente si no vivo con nadie más, suelo acondicionar parte de mi casa como si fuese una oficina y trabajar allí en los horarios que me haya puesto ese día. Quizás vaya a alguna cafetería alguna mañana, aprovecho para quedar con alguien y matar alguna tarea desde allí antes de que llegue.

Si vivo con alguien más, entonces suelo buscar con quien compartir oficina o algún coworking en el que haya un mínimo de vida, aunque prefiero lo primero. Si vivo con más gente me resulta muy complicado trabajar en casa, a menos que esa persona no esté en casa durante mi horario de trabajo.

Independientemente del lugar en el que trabaje en mi ciudad/pueblo “base”, sí que me gusta viajar puntualmente y moverme a otras localidades, trabajando durante unos cuantos días o incluso una semana desde las mismos.

Personalmente este cambio de contexto me carga mucho las pilas, ya que no solo conozco ciudades o pueblos que de otra forma igual no visitaría en modo turista, sino que puedo conocer a nivel profesional personas que están trabajando día a día en ellas, organizando comunidades y otro tipo de iniciativas interesantes.

Esta experiencia es un tipo de workation forzada y fiel a la definición del término, suele ser muy productiva tanto a nivel de trabajo como a nivel personal.

Por qué hemos creado rentmydesk.com

Tanto Diego como yo creemos que herramientas tipo linkedin cojean en la parte de conectar realmente a las personas en el mundo real y esto es algo muy importante en RentMyDesk.

Para las empresas cada vez es más importante conseguir captar talento para sus equipos, buenos proveedores (diseñadores, traductores, programadores, escritores…) y también obviamente, clientes. Con una herramienta así pueden recibir visitas de personas que cumplen con sus criterios viéndolas trabajar desde su misma oficina y compartir puntos de vistas profesionales.

Por otro lado, los freelances y otros profesionales acostumbrados a trabajar en remoto, pueden organizarse viajes a ciudades que quieran visitar, conociendo, trabajando y compartiendo cafés con personas y empresas que están haciendo cosas en esos lugares. También es una buena alternativa a trabajar en el aeropuerto mientras esperas a tu vuelo con un café de discutible calidad.

Ya tenemos un MVP desarrollado en beta privada. Si tienes un hueco en tu oficina y te apetece rentabilizarlo o atraer talento, ponte en contacto con nosotros. El servicio es totalmente gratuito.

El buen desarrollador de software

Strip-Faire-payer-la-formation-650-finalenglish-1 (1)

Llevo un tiempo pensando en lo que es para mí ser un buen desarrollador de software y los puntos que nos pueden hacer ser justo lo contrario.

Desde hace bastantes años trabajo y comparto proyectos con un número variado de profesionales, bien personas o agencias a las que delego trabajo o bien que me lo delegan ellos a mí. Este texto se basa en esta experiencia.

Por otro lado debo decir que, algunas de las cosas “malas” que destaco en este texto no solo las he visto en otros profesionales, sino que también las he visto en mí mismo cuando empezaba bastantes años atrás o al cometer errores a lo largo de mi carrera profesional.

Por lo tanto es una visión muy personal de nuestro mundo y no pretendo tener la razón absoluta. Los comentarios siempre se agradecen.

No tener una actitud de gilipollas

Somos unos privilegiados al dedicarnos a desarrollar software en estos momentos. Podemos asegurar que no hay paro en nuestro sector y que siendo inquietos, actualizándonos y currándonoslo un poco podemos trabajar desde prácticamente cualquier sitio del planeta (siempre que tengamos visado y conexión a Internet).

Es posible que en un futuro esto cambie y que mucho del trabajo o tipo de proyectos que estamos realizando en estos momentos se podrán sustituir por APIs o servicios cloud. Pero el presente es el que es y se puede vivir genial desarrollando software.

Pero este privilegio no nos da derecho a comportarnos como cretinos. Chantajeando a quien nos contrata o criticando en público a quien oferta porque en Londres cobrarías en triple y te irían a buscar a casa en un taxi de esos negros molones. Hablaré de este tema más en detalle más adelante en esta misma entrada.

Dominar el framework javascript de moda no te da derecho a ir por la vida con la actitud de un House desarrollador de software. House era un payaso pero al menos salvaba vidas (en la ficción).

Mejor un trabajador responsable que un ninja

Puedes cambiar el término “ninja” por lo que desees, incluidas siglas de certificaciones oficiales.

Al final de lo que se trata es de sacar trabajo adelante. Y de poco sirven las charlas que hayas dado, los tags que uses en Twitter o las pegatinas que tengas en tu Mac.

Tener capacidad de respuesta es algo muy valioso en un desarrollador para mí, mucho más importante que sus títulos o marca personal.

Es muy habitual la decepción que puedes llevarte al comprobar como una persona que es rockstar en Twitter u otros escenarios, desaparece en mitad de un proyecto para finalmente salir del mismo porque se ha visto saturado o simplemente no le gusta que se use una tecnología o herramienta X. Me parecen actitudes de chavales de catorce años. Sin ánimo de ofender a los chavales de catorce años.

Al final lo que se desea es tener en tu equipo gente con la que puedas contar. Puede que no controlen a un nivel brutal la última versión de Angular o hayan participado en un proyecto de gran tráfico o que hayan escrito libros sobre la última librería javascript de moda que dentro de dos años no utilizará nadie, pero es que la mayoría de las ocasiones tampoco hace falta.

Lo que sí hace falta son profesionales responsables que acaben el trabajo de forma correcta y sin tonterías.

Comunicación

La comunicación es otro valor clave.

A todos nos surgen imprevistos, nos equivocamos o puede que pase algo fuera de nuestro control que nos impida hacer nuestro trabajo. Comunicar cuanto antes cualquier imprevisto ayuda a poder resolver la situación, callarse siempre es una mala opción.

Lo mismo que si una frase o acto de otra persona en el equipo te sienta mal o no estás motivado por algún problema.

Personalmente valoro mucho quien sabe comunicarse cuando las cosas van mal o hay presión en un proyecto. El coste de comunicación es un precio muy alto que se puede pagar al trabajar con un equipo o una persona equivocados.

Saber comunicar correctamente tus ideas cuando trabajas en equipo, escribir bien y expresarte bien es una habilidad que en mi opinión nos hace mejores desarrolladores.

Esto me parece especialmente importante cuando se trabaja en remoto. Cuando no ves la cara del otro ni escuchar su voz, el texto lo es todo. Es crítico en estos contextos cuidar mucho cómo escribimos.

Comunicar también es escuchar.

Algunos podemos tener carácter, prejuicios por falta de perspectiva o simple cabezonería, somos humanos. Muchas veces incluso teniendo experiencia caemos en estas cosas. Y muchas veces, debatimos con ímpetu aun estando equivocados.

Creo que tanto si eres el que argumenta estando o no equivocado como si eres el receptor, debes escuchar lo que esa persona te está diciendo, sobre todo si tiene experiencia. Las lecciones más valiosas las aprendemos cuando estamos equivocados y cuando nos argumentan el por qué. Y son doblemente valiosas cuando el/la que nos alecciona tiene menos experiencia que nosotros.

Y aunque en ese momento no lo veamos, sin duda quedará en nuestra mente y será un recurso muy valioso cuando toque darse cuenta de nuestro error.

Pragmatismo VS curriculum oriented development

No es “sexy” (y madre mía con lo de “sexy” para hablar de frameworks y lenguajes…) desarrollar una API REST en php y mysql, teniendo Go, lenguajes como Erlang y OTP que existen desde los 80 pero que las hemos descubierto hace cuatro años o bases de datos como MongoDB que “escalan”, “son rápidas” (porque sí y ya está) y que las usan en esa empresa que tiene un “CEOfounder” de 24 años.

Estás desarrollando un producto y lo que importa es el valor. Entregar el máximo valor, con la calidad mínima necesaria consumiendo la menor cantidad de recursos de tiempo y dinero.

La tecnología es algo crítico pero no es lo más importante. Son nuestras herramientas, pero ya está. Nuestro recurso más valioso es la capacidad de crear con ellas usando nuestro criterio. El dominio de las mismas es importante, entrenar con ellas es importante, pero no tan importante como el entregar y entender lo que estamos desarrollando.

Creo que un desarrollador orientado a la herramienta no es un buen desarrollador, es mi opinión personal y mi opinión como cliente.

Por otro lado valoro también mucho el pragmatismo.

Está muy bien que la plataforma web tenga una arquitectura basada en servicios con una implementación de Inyección de dependencias muy currada y que también, se haya tenido en cuenta la separación de orígenes de datos para poder distribuir la carga entre varios frontales web, varios servidores de lectura y escritura a nivel de base de datos y las operaciones pesadas gestionadas por sistemas de colas asíncronas. Todo esto está muy bien. Pero al final si el proyecto es nuevo y va a tener un crecimiento natural, es posible que no se vaya a necesitar orquestar una arquitectura de ese tipo en seis máquinas o instancias virtuales en la nube de turno y puede que con un servidor en un hosting tradicional vayamos sobrados.

No necesitamos añadir coste al cliente de mantenimiento de sistemas o coste extra de servicios cloud porque a nosotros nos ponga cachondos tener una arquitectura de las que salen en blogs como High Scalability.

Y por último: el pasar de frameworks, ORMs y complicar el mantenimiento por trucos de rendimiento cuando no tienes este tipo de problemas, personalmente me parece condenar al proyecto a tener que reescribirse en un futuro por la cantidad de esfuerzo que puede suponer hacer cambios mínimos y el terror también de subirlos a producción.

Trabajando por cuenta ajena y las ofertas de trabajo

“El águila con talento esconde sus garras”

Muchas veces me quedo atónito al escuchar las experiencias que han tenido empresarios con su equipo técnico en ciudades como Madrid, Londres o San Francisco.

Cretinos sin ningún tipo de escrúpulos que hacen chantaje a sus empleadores amenazando con irse de la empresa porque han recibido en el último mes un montón de peticiones de amistad de recluiters en linkedin.

Chantajes que van desde imponer el uso de una tecnología/frameworks “o se van”, irse sin avisar ni decir nada una tarde de la oficina porque tenían un partido de fútbol o simplemente porque había un evento en la oficina molona de turno de Madrid.

La verdad me sorprende el aguante de sus jefes por miedo a perder “talento” o capacidad de ejecución, reteniendo un equipo tóxico a ese nivel.

“Que cierre su empresa si no sabe llevarla” He llegado a leer esto cuando un empleador anuncia una oferta de trabajo por debajo de los 32000 euros anuales a un desarrollador, sin entrar a valorar su nivel.

“En Londres me pagarían X” Pues ve a Londres y disfruta de este sueldo. Es posible que al irte, la gente que contrata a programadores en este país se de cuenta del vacío que has dejado, la gente que organiza eventos deje de hacerlo porque ya no merece la pena y el mercado del desarrollo y de Internet en España se colapse. Que se jodan, por no valorar el talento que alguien que va a comisión ha visto en tus aptitudes de Linkedin.

Pero desde luego yo no quiero trabajar con gente así. De hecho no quiero personas así a mi lado.

Montar un negocio se ha convertido en un espectáculo en el que cualquiera puede opinar sin vivir la experiencia de hacerlo. Pero la realidad es que los ataques a empresarios que están empezando y ofrecen sueldos humildes, no mejora el mercado.

Me parece muy respetable buscar el mayor sueldo posible, pero la mayoría de los lugares en los que te van a ofrecer trabajar no van a poder competir con otras empresas en eso. Y es respetable que no quieras trabajar por menos de lo que vales o creas que vales, pero montar un espectáculo en Twitter o en foros me parece bastante infantil y tóxico.

Al mundo real le dan igual las pataletas y la gente realmente competente habla poco y hace más.

Los programadores que realmente pueden elegir dónde trabajar lo hacen sin montar espectáculos. Si no les interesa lo que se oferta, se van a otro sitio sin montar un drama.

Todo lo demás

Y en último lugar es importante todo lo demás. Escribir buen software, mejorar como desarrollador día a día, mejorar nuestro nivel de inglés para comunicarnos y aprender de otros desarrolladores, aplicar calidad y entrega continua, autoformarnos en nuevas herramientas para que con criterio, las podamos utilizar cuando sea el momento y contexto adecuado.

Personalmente, algo que últimamente me parece importante es volver a repasar conceptos y mejorar mi nivel de matemáticas. Al margen de todo el postureo relacionado con algoritmos (otra moda-pesadilla), mejorar en esto viene muy bien para comprender cómo funcionan algunos sistemas y tras años de experiencia programando se ven de otra forma los conceptos que cuando los estudiábamos no los veíamos para nada útiles. También es útil para delegar trabajo en matemáticos que se encarguen de idear los algoritmos que implementemos en nuestras aplicaciones o software.

Considero también importante dominar otros campos y tener hobbies. Nos dan perspectiva, conocemos a gente distinta y salimos de nuestra zona de confort.

De hecho veo importante conocer otras personas muy distintas del mundo del software, creo que nos pueden dar puntos de vista e inspiración que nos hacen mejores desarrolladores aunque no seamos plenamente conscientes de ello.

Producto y empresa

Me encuentro en un momento de reflexión personal que tiene como objetivo decidir si en los próximos cuatro años invertiré en ampliar mi formación en diseño (y gestión) de producto o si apostaré en formarme muy en serio en el ámbito de empresa.

Lo que he aprendido y conseguido con la práctica en ambos campos durante los últimos diez años me hace estar hambriento de seguir avanzando para alcanzar un buen nivel de conocimiento y experiencia en los mismos.
De hecho, no es que vaya a dejar de formarme en un campo por profundizar en el otro (no funciono así) pero sí que esta decisión es lo suficientemente importante como para condicionar mis próximos pasos.

Hace años hice la reflexión de que la tecnología es algo que me gusta pero lo que me apasiona de verdad es crear productos. Productos que den valor y que se usen.

Gracias a mis conocimientos y experiencia puedo crear productos de software con relativamente “poco” esfuerzo e inversión, pero me encantaría crear productos también fuera del ámbito tecnológico.

Por otro lado, me apasiona vivir la experiencia en la que esos productos o servicios pasan de generar ingresos tímidamente a generar beneficios. El reto se vuelve aún más interesante cuando finalmente consigues que dichos beneficios no dependan de que tu negocio te absorba por completo, sino que te permitan crear equipos que funcionen como un reloj, con una filosofía y forma de hacer las cosas claras.

La creación y gestión de negocio es un mundo tremendamente interesante para mí, desde la parte financiera en la que literalmente es donde se aprende la realidad de los recursos económicos de los que dispones hasta la estrategia en la que diseñas los pasos que como equipo vais a dar para crecer todos juntos como empresa y como personas.

En definitiva son dos cosas que me apasionan y de las que sigo aprendiendo cada día.