reflexiones

Puff..., casi siempre al comenzar el año el que más o el que menos hace una lista de buenos propósitos, de objetivos para los próximos doce meses. En cierta medida, yo lo también lo hago, pero sobre todo me gusta mirar un poco atrás y ser aún más consciente de dónde vengo (por eso de saber mejor hacia dónde voy).

Y desde luego, puedo decir que ni he tenido un trabajo rutinario desde que terminé la carrera ni que me he mantenido en el mismo tipo de rol. ¿Podría haber sido de otro modo? Pues ni idea, seguramente sí, ya que yo mismo he sido responsable de mis acciones y decisiones. ¿Quién si no?

Echo la vista atrás y ojalá los próximos diez años sean igual de intensos y productivos.

Me gusta Haruki Murakami y me le ha acompañado desde que cayó en mis manos casi por casualidad uno de sus libros allá por el noventa y pico.

A modo de resumen...

Terminé la titulación de Ingeniería Superior en Informática por el 2001, después de presentar un proyecto fin de carrera que me llevó casi un año. Se trataba de una aplicación hecha con Visual C++ y librerías MFC/ATL, para la creación de interfaces de usuario de un producto Scada que realizábamos por aquélla época en la compañía para la que trabajaba. Entonces pertenecía a lo que se denominaba el Grupo de Desarrollo de Software (nada original, por otro lado).

Fruto de este proyecto (que creo que sigue en producción en algún centro de operación ferroviario), fue este artículo que ya en su día publiqué en CodeProject y de título Improving ATL-ActiveX Serialization y mucho, muchísimo profiling y escribir código optimizado. Y ahora que lo pienso, ese artículo fue lo primero que me dio por publicar! Y por cierto, veo que tengo que actualizar la información con la que me registré en CodeProject, portal que sigue siendo para mí referencia hoy día.

Lo más interesante de aquéllo fue que en esa aplicación integré VBA (Visual Basic for Applications), toda una novedad en aquel momento, y también un gran reto técnico.

Acostumbrado a C++, todo el nuevo entorno de .NET framework junto con C#, creó una gran expectativa que abrazamos casi todos en el departamento desde el primer momento. De hecho aún conservo un libro que me regalaron en un evento sobre esa nueva tecnología y que creo que sería de lo primero que se publicó entonces.

Siempre he estado muy ligado a tecnologías de Microsoft, y también siempre me han parecido infantiles y no profesionales las comparaciones y dilemas un poco tontos y muy de nuestro sector entre esto o aquello. Toda tecnología tiene sus luces y sus sombras. Punto.

Sin embargo, desde hace unos años trabajo muy de cerca con Azure (la plataforma de cloud computing de Microsoft y de enorme crecimiento) y sigo con detalle todos los movimientos de esa compañía hacia una visión más "open" del software. De hecho, no en vano, .NET Core y la liberación de algunos productos tradicionales de Microsoft para su funcionamiento en Linux (como Sql Server, nada más y nada menos) es una muestra más de esa mayor amplitud de miras. Y no digo Azure por capricho, es que tengo clientes que funcionan desde esa plataforma con un éxito rotundo.

En 2006 ya estaba trabajando en Suecia en un proyecto de muchos millones de euros; mejor dicho, el proyecto tenía un montante de cien millones de euros pero la parte software, aunque, residual, era crítica: sin ese pilar, todo el proyecto se caía y las penalizaciones económicas por parte del cliente podían poner en riesgo la viabilidad misma del proyecto. Había mucha presión, teníamos que trabajar con prisas, cumpliendo hitos literalmente con la lengua fuera, además de toda la presión de los cambios que supone trasladarte con tu familia a un país muy diferente a España.

Pero aprendí, y muchísimo; fue para mí, a pesar de las crisis que viví junto con mis compañeros, una de las etapas más fértiles de ese periodo. Recuerdo alguna noche entera realizando una actualización de uno de los sistemas en los que se basaba el proyecto.

No había metodología, sólo tirar hacia delante del modo que fuese. Curiosamente, todos mis compañeros que entonces participábamos en ese proyecto para una compañía eléctrica sueca (Vattenfall), ya no están en la misma empresa, incluido yo mismo. Todos fuimos saliendo poco a poco encontrando (o buscando) mejores oportunidades laborales y profesionales.

De aquel proyecto me quedó muy claro la extraordinaria importancia de mantener una mínima metodología y orden en los desarrollos (abajo no había orden porque en el nivel ejecutivo ni lo había ni se fomentaba). Y también de la enorme importancia de un diseño pulcro y eficiente de la base de datos, ya que la aplicación era muy data-centric. La base de datos crecía a razón de millones de registros a diario, de modo que continuamente nos encontrábamos con nuevos cuellos de botella (tanto a nivel de software como de hardware). Todo un reto que finalmente pudimos estabilizar (nos llevó más de un año).

Después volví a España y comencé a interesarme por todo lo ágil y clean-code. Fue una época de lecturas frenéticas de toda la literatura relacionada que encontraba interesante (los libros, cómo no, de Martin Fowler, Robert C. Martin, etc.) y poco a poco fui confirmando ciertas intuiciones acerca de los pilares con los que construir buen software. 

Y como consecuencia natural, muy pronto comencé a darme cuenta de que no todo el mundo entendía igual el concepto de buen software, y que apenas se le prestaba atención a asuntos tan importantes como la organización de un equipo de trabajo, las dinámicas de grupo, la ausencia del concepto de jefe o gestor como aquel que facilita el trabajo de los demás, etc., cuyo resultado termina generando un producto bueno o malísimo.

Continuaba escribiendo software de un modo u otro, a veces con buenas condiciones y casi siempre en muy malas condiciones (exceso de reuniones impuestas, tareas no planificadas para hoy, etc.).

Entre 2008 y 2009 hice mi primera tentativa emprendedora. Y fue un total fracaso, pero me permitió meterme de lleno en Drupal. La idea era buena, pero somo se suele decir, la ejecución lo es todo. Por aquélla época comencé a leer mucho sobre emprendimiento e intraemprendimiento. Siempre digo que dejé esa compañía en la que mantenía un contrato fijo y con buen sueldo porque ya llevaba años preparándome mentalmente para probar otro tipo de cosas. Y es que nos centramos demasiado en la acción, pero se nos olvida una verdad trascendental: no es el hacer sino el ser (lo que somos) lo que provoca cambios verdaderos. Bueno, que enrollo en temas de desarrollo personal...

Entre pequeños proyectos de I+D y el mantenimiento del sistema que montamos en Suecia, tenía tiempo de comenzar a interesarme por otras tecnologías fuera del ecosistema de Microsoft. Comencé a hacer mis primeros proyectos web y a leer todo lo que podía sobre Drupal. Y, por supuesto, abracé NodeJS desde el primer momento. Entre otras cosas.

Tanto fue mi entusiasmo por Drupal que terminé participando como ponente en dos sesiones (esta y esta otra) en la Drupalcamp de 2011 en mi ciudad. Descubrí ese ecosistema y una comunidad muy implicada y estimulante.

Comencé a hacerme cargo de la gestión de equipos de trabajo sobre el 2009. Y no tenía ni idea de qué iba aquello, así que leí muchísimo al respecto y lo intenté hacer lo mejor posible.

La empresa para la que trabajaba entonces (la ingeniería Telvent Energía, ahora propiedad de Schneider Electric), no se puede decir que fuese una de esas cárnicas, pero lógicamente, la presión de sacar proyectos era alta. Como en todo, hay momentos buenos y malos, pero todo lo que quiero recordar de aquel periodo (trabajé en esa compañía desde el 2000 hasta el 2012) es bueno y hasta excepcional, y considero que no todo el mundo tiene la suerte de caer en una empresa y tener las experiencias nacionales e internacionales como tuve en Telvent, asistiendo a eventos importantes, etc. Viajé varias veces a USA (estuve en semana asistiendo a TAP program de Microsoft en Seattle, toda una experiencia viendo, oyendo y hablando con auténticos gurús, de los de verdad), así como viajes a diferentes ciudades de Suecia, Holanda, Eslovenia, etc. y hasta una semana en Beirut.

Pero el ciclo se fue acabando y comencé a interesarme por otras cosas y otras posibilidades laborales. Digamos que dejé de verme en un futuro lejano trabajando para la misma compañía.

"...no vaya a ser que cambie tu modo de pensar". Leí una vez en un libro de esos de desarrollo personal.

Comienza el año y después de tanto Rosco de Reyes (dulce típico en España y que pone fin a las navidades), te das cuenta de que ya es enero, vuelves al trabajo y esa enorme lista de propósitos y proyectos que alegremente hacías en diciembre, ahora la tienes delante y es hora de empezar a hacer cosas.

O sea, lo de siempre, comienza el camino para que al final del año, si nos seguimos acordando de esa lista, nos demos cuenta de que no hemos conseguido ni la mitad de la mitad. Es más, yo creo que esas promesas de mejora para el nuevo año entrante son más bien un tirar hacia delante y una excusa para justificar lo difícil que nos resulta actuar y hacer lo que debemos y queremos hacer. ¿O no?

Vale, sí, yo soy el primero que uso esas listas, las uso desde hace mucho con mayor o menor éxito. Uno de mis propósitos para este año se seguir leyendo más y mejores libros de todos los temas que me interesan, muchos de ellos de tecnología, otros de desarrollo personal, etc. 

¿Es que puede ser de otro modo? ¿Puede existir cualquier negocio o profesión que no avance sin seguir aprendiendo? Todo evoluciona, si no lo hacemos al mismo ritmo que todo lo demás, podemos terminar intentando vender algo a clientes de un mercado que desapareció o se transformó hace mucho.

Discrepo cuando oigo hablar de que estamos en la sociedad del conocimiento; puede que sí, que la economía sea cada vez más del conocimiento, pero las personas, en general, estamos lejos de darnos cuenta del impacto que esto supone en nuestra forma de aprender y evolucionar profesionalmente. Si los negocios cambian, lógicamente sus profesionales también. 

Es verdad que ahora disponemos de enormes recursos de aprendizaje a un coste ridículo en forma de blogs, webinars, podcasts, seminarios, videocursos, maravillosos libros en Kindle o de Google Play desde 0.99€ y que leemos desde el móvil; puede que ahora tendamos a leer más que antes y que leamos y nos informamos de otro modo. Pero paradójicamente, acumulamos tal cantidad de información que comienza a ser un problema esa misma sobreinformación porque somos incapaces de extraer conocimiento de todo ello. La hiperinformación (y la adicción a ella) comienza a considerarse algo patológico.

Lo importante no es llenar la cabeza de datos, sino saber qué hacer con ellos, a no ser que tengas complejo de loro y te guste repetir la información que lees, claro.

O sea, que no es lo mismo, en mi opinión, leerte todos los feeds de tu agregador cada día o cada dos horas, que empaparte un sesudo libro de Jeremy Rifkin analizando un tema en concreto en profundidad. Sin embargo, para la mayoría de la gente estar más informado es hacer justamente lo primero, y sólo lo primero.

No puedes avanzar en ningún tema si no lees en profundidad sobre él, y para ello hace falta la organización estructurada de un buen libro que analice el contexto, el planteamiento, las diversas experiencias sobre ese campo y que incluso se atreva a realizar algún tipo de prospección al respecto. El libro no ha muerto, de ningún modo, puede estar en la unidad de cuidados intensivos el formato papel, pero lo que es estructurar el conocimiento en forma de libro, eso va a pervivir, espero, muchísimos años. El saltar de titular en titular es para mí frivolizar y no llegar a nada.

En software ocurre exactamente lo mismo. No es igual aprender una nueva tecnología leyendo tutoriales por aquí y por allá que sólo tocan la punta del iceberg; puede servir para jugar un poco, para resolver problemas puntuales cuando ya conoces bien esa tecnología, yo lo hago muchísimo y lo voy a seguir haciendo, claro; también hay posts y tutoriales extraordinariamente buenos.

No obstante, si quieres realmente profundizar en esa tecnología, coge un buen libro y empápatelo de arriba abajo; es más, recomiendo no usar sólo un libro de referencia para ello, sino varios, ya que rara vez un único libro cubre todo lo relevante (por mucho que en el título ponga "La biblia de...").

Yo, al menos, eso es lo que hago cada vez que siento la necesidad de llegar al fondo de algo: quizá husmeo un poco por aquí y por allá en blogs de gente que sepa más que yo sobre ese tema en particular, pero siempre buscando una buena referencia bibliográfica con la que comenzar. Después asedio mi cabeza durante el tiempo que sea necesario con información sobre ese tema, libros incluídos, hasta que me siento suficientemente maduro como para seguir adelante. No es saber por saber, es aprender para hacer algo con todo ello.

Con un primer libro vas a conocer globalmente esa tecnología y seguro que encontrarás multitud de referencias para avanzar por caminos paralelos llegado el caso.

No se puede aprender seriamente algo únicamente picoteando en tutoriales de quinientas palabras; lo siento, pero no funciona así, el libro sigue siendo necesario porque te da esa visión global tan necesaria para saber usar bien lo que sea que necesitas aprender. Para mí, en un libro el autor te viene más o menos a decir "hey!, he trabajado mucho este tema y todo esto que te cuento aquí es mi experiencia sobre ello".

Así que esta es la paradoja: creemos que vivimos en una sociedad de la información cuando en realidad lo que queremos decir es que ahora estamos sobreinformados de muchas cosas pero seguimos con la misma falta de conocimiento que hace veinte años, y eso ocurre en todo, en tecnología, gestión de negocios, marketing, etc. Tenemos a nuestra disposición el conocimiento de forma inmediata y a coste muy pequeño, sin embargo el ciudadano medio, por lo general, no lo usa y se queda sólo en los titulares. Es una pena.

Por favor, ¡escribidme para decirme que estoy equivocado!

Acabo de comenzar el año con dos autoregalos, dos libros que prometen muchísimo.

Uno de ellos es el libro de Lazlo Bock sobre cómo están cambiando en algunas compañías la forma de organización del trabajo. El otro se llama El Mundo que Viene, de Juan Martínez-Barea, en donde se habla sobre cómo la meritocracia será un valor fundamental en el futuro (vaya, por fin).

No podemos progresar en un mundo que cambia continuamente sabiendo lo mismo que sabemos hasta ahora.

Lo siento, hay leer, pero incluso leyendo mucho te puedes encontrar abrumado y sin llegar a un conocimiento apropiado de nada e insuficiente para actuar y conseguir nuevos resultados, de ahí que leer libros bien estructurados y con la suficiente profundidad sea imprescindible, nada que ver con la inmediatez de los titulares de blogs de tecnología a la que somos tan aficionados (yo el primero, eh!), que son necesarios, claro, pero no suficientes para profundizar en nada.

El libro no está muerto, de ningún modo, el que sí lo está es quien piensa que va a obtener mejores resultados sin aprender nada nuevo.

Joer, qué serio me ha quedado esto.

Avanza el verano y en breve me tomaré unas semanas de vacaciones. Es como una especie de parón en tu día a día, en el trabajo, en la rutina familiar.

¿Cómo ha ido en un sentido general esta primera parte del año? No puedo evitar hacerme preguntas de este tipo. Así que aunque no soy muy dado a compartir reflexiones introspectivas en mi web, haré un resumen de este agitado año, al menos desde el punto de vista profesional y técnico, de todas las cosas y temas con los que he tratado.

Durante esta primera parte del año hemos cerrado proyectos importantes y abiertos otros nuevos, trabajamos en la realización de un prototipo software con el que vamos a preguntarle al mercado el interés que puede haber en él y planteamos ya una revisión profunda de uno de los productos que comercializamos.

Del mismo modo he avanzado en varios proyectos personales (he registrado mi primera marca) y por fin hemos puesto la primera piedra, como se suele decir, en otro proyecto después de tres años de planos, arquitecto, licencias, etc.

Lo que me pregunto es cuánto hay de mi forma de gestionar los proyectos software que dirijo en todos esos proyectos que, digamos, se gestan fuera de mi horario laboral, y al revés. En definitiva, creo que para cualquier actividad valen los conceptos de definición de roles y en todas es mucho mejor la colaboración que la imposición. Es liberador saber que no tienes que llevar siempre la razón y que el mundo se modela a medida que haces cosas y resuelves problemas.

Lo que sí sé es que en todos esos proyectos, sean del tipo de que sean, se avanza resolviendo problemas. No hay más. Emprender en algo consiste en resolver los problemas que van surgiendo de la forma más ágil posible. En realidad, cualquier problema es algo que tienes que aprender y sólo la carga emocional negativa que le quieras dar es lo que lo convierte en un problema. En fin, que divago.

A continuación escribo sobre lo mas significativo para mí de esta primera parte del año.

Javascript y librerías relacionadas

Parece ser que estamos viviendo un gran auge de un lenguaje que tiene muchos años: puesto que se está imponiendo la web en casi todo lo que hacemos y afortunadamente vamos convergiendo hacia estándares, Javascript tenía que jugar un papel muy importante.

En mi opinión esto será aún mejor cuando se popularice la revisión del lenguaje ECMAScript 6, revisión con la que se le dota de una mayor madurez y que contiene características que los desarrolladores acostumbrados a otros entornos siempre hemos echado en falta. ES6 es como el hermano mayor de Javascript con el que irán convergiendo todos los entornos (NodeJS), liberías (AngularJS) y frameworks que usan este lenguaje.

No obstante, me sorprende que exista cierta cultura de clean code y de refactorings continuos pero por alguna razón ésta siempre se aplica a lenguajes como C# y Java y no siempre a los desarrollos de Javascript, de modo que es muy fácil encontrar código en este lenguaje por todas partes verdaderamente sucio, no hay más que husmear desde Firebug o la DevTools de Chrome con cualquier web y descubrir cosas realmente significativas y curiosas en webs que reciben miles de usuarios diarios. Hay mucho por hacer...

AngularJS

Comencé con AngularJS en 2014 y desde entonces lo he usado en todos los proyectos que he dirigido con interfaces web. 

Aunque es más apropiado para SPA (single page applications) se puede sacar provecho de esta librería en cualquier aplicación web. Sin ninguna duda, una solución intensiva en código Javascript es más rápida de escribir y si se cuida bien la organización de los assets, queda muchísimo mejor estructurada de cara a su mantenimiento y evolución.

Como todo: un buen uso de AngularJS da lugar a una solución clara, limpia y bien estructurada, un mal uso puede generar una solución realmente sucia y difícil de seguir.

Me encantan las directivas de AngularJS; recientemente estoy viendo más y más publicaciones sobre Polymer, librería para crear componentes webs que aún no conozco del todo y similar a las directivas de AngularJS.

Flujos de trabajo para casi todo

Cualquier trabajo no es sólo una cuestión de realizar una tarea concreta con un comienzo y un final, ésta tiene que estar enmarcada en un procedimiento o flujo de trabajo que ordene cómo realizar las tareas.

Del mismo modo, cualquier trabajo que se tiene que repetir y que puede ser más o menos complejo se tiene que organizar para que cuando se repita, se haga correcta y eficientemente. Esta primera parte del año me ha tocado definir flujos de trabajo en distintos contextos. Lo más relevante de esto es que veo que casi nadie se preocupa por formalizar este tipo de procedimientos para que no haya que re-pensar una y otra vez cómo hacer las mismas cosas (perdiendo un tiempo precioso en el camino).

A nivel técnico, he usado intensamente grunt para una aplicación web en la que trabajo desde hace un tiempo y he escrito varios procedimientos acerca de su despliegue ordenado, validación, etc.

Igualmente, hemos comenzado un proyecto (ajeno totalmentae al software) que consiste en la construcción de unos alojamientos rurales, después de varios años de proyecto, planos, permisos, etc. Puesto que somos varias las personas implicadas, tanto los dueños como el arquitecto, el aparejador, el constructor, etc., he definido lo mejor posible el rol de cada uno para que a cada paso que haya que dar no tengamos que hablar todos-con-todos, bloqueando la toma de decisiones del día a día y suponiendo una carga de trabajo adicional (e innecesaria). Esta es la única forma de avanzar en los distintos proyectos que tienes en tu vida profesional y personal, o eso espero, ¿?

GIT no sólo para código

Me encanta GIT, ¿a quién no? Este año he comenzado a usarlo no sólo como herramienta de control de versiones y repositorio para código, también para otro tipo de documentos como los dos libros en los que estoy ya trabajando.

Aunque existen herramientas visuales para GIT y viniendo del mundo de Microsoft, llega un momento en que aprecias la comodidad de usar la consola para muchas tareas, sencillamente termina siendo más eficiente. Escribiendo esto se me viene a la cabeza ese magnífico y clásico libro de Neal Stephenson titulado En el principio... fue la línea de comandos. Genial y de obligada relectura cada ciertos años.

Optimización y rendimiento web

Al haber trabajado muchos años en el backend, he dedicado mucho tiempo a la optimización de código (a veces por necesidad y otras por puro placer, esa es la verdad). Esta primera parte del año he profundizado muchísimo en la optimización ya no sólo de los flujos de trabajo de una aplicación web profesional, sino en la optimización de todos los assets necesarios para la navegación con el frontend: ficheros html, css, imágenes, fuentes, minificación, técnicas de caché avanzadas, análisis en profundidad de los requests que realiza el navegador, buen uso de los selectores css, he aprendido que hay frameworks para el layout más eficientes que otros, el overhead que puede suponer obsesionarte por que tu aplicación sea responsiva, retraso intencionado en la carga de recursos y un larguíiiisimo etcétera.

Curiosamente apenas hay literatura en español sobre este tema tan importante, dado que el mundo web está creciendo exponencialmente y pocos desarrolladores conocen al menos las técnicas más relevantes. 

La clave está en ejecutar todas estas técnicas de optimización sin ofuscar la solución.

Sobre desarrollo web he mantenido muchas conversaciones interesantes acerca de lo poliédrico que puede ser el desarrollo de un portal web: además de la elección de las tecnologías correctas, no se pueden obviar las técnicas de optimización, tampoco ignorar estrategias SEO / SEM, integrar analítica web, etc. De modo que cuando leo un currículum en donde se pone "desarrollador web", la verdad es que no sé qué pensar...

Nginx y Redis

Para el proyecto que estoy a punto de publicar he usado por primera vez Nginx y Redis, dos proyectos que me parecen fantásticos. Nginx juega un papel muy importante para la arquitectura de despliegue para un sistema muy escalable (muchos usuarios concurrentes accediendo a un portal web) al tiempo que con Redis se puede jugar muchísimo para conseguir enormes mejoras de rendimiento en distinto tipos de aplicaciones.

Visual Studio 2015

Hemos comenzado a usar Visual Studio 2015 estos meses atrás y adentrarnos de lleno con ASP.NET 5 y NDX, la nueva revisión del Entity Framework, etc. Sorprende cómo se han ido adoptando las formas de trabajar con proyectos open-source en este nuevo tipo de proyectos con Visual Studio 2015 y esta nueva revisión de ASP.NET.

Desarrollo para la nube

Trabajar en distintos ámbitos tiene algo de fascinante, terminas dándote cuenta de cómo lo que haces en uno enriquece los demás y al revés.

Ahora mismo estoy trabajando en un proyecto basado en MEAN que al mismo tiempo me está permitiendo sentar las bases de un proyecto de I+D que estamos realizando en la compañía para la que trabajo y que desarrollaremos durante 2015 y 2016; este proyecto consiste en un sistema de detección y diagnóstico de incidencias para el despliegue de cuatro millones de smart meters, de la mano de una compañía de distribución eléctrica nacional. Big-data con Hadoop, su despliegue en la nube con Azure, el análisis y explotación de esos datos más una capa de servicios que consumirán terceros sistemas serán las partes esenciales del proyecto y en cuyas tecnologías nos vamos a meter de lleno en los próximos meses.

¿Qué puede garantizar que tendremos éxito en ese nuevo proyecto reconociendo que algunas de las tecnologías que vamos a usar son relativamente nuevas para nosotros?

Si crees conocer muy bien la tecnología X, ¿qué te hace pensar que serás capaz de sacar provecho a otra totalmente distinta?, ¿te asegura acaso que vas a tener éxito con un nuevo stack que debes usar para un nuevo proyecto cuya naturaleza no tiene nada que ver con lo que has hecho hasta ahora?

Para un responsable de proyectos, ese es un riesgo que hay que considerar a fondo.

Un desarrollador de software o un equipo de trabajo sólo pueden tener éxito en cualquier proyecto si son capaces de mantener firmemente una serie de principios de desarrollo y métodos que se pueden aplicar a cualquier tipo de tecnología.

Por tanto, aún teniendo valor, me da siempre qué pensar cuando escucho afirmaciones del tipo "soy experto en C#", "nivel avanzado de administración de Sql Server", o "desarrollador front-end con AngularJS", etc, cosa que se suele ver en todos los currículums que me llegan (y por qué no, en el mío propio hasta hace pocos años). Todo eso es fantástico, pero no suficiente...

Si dominas una serie de principios serás bueno y tendrás éxito en cualquier proyecto software independientemente de las tecnologías que se usen.

Para mí, el currículum ideal de un desarrollador profesional de software estaría compuesto de afirmaciones de este tipo:

• Participación activa en los siguientes proyectos:....
• Experto en patrones de diseños y antipatrones.
• Experiencia en enfoques ágiles para proyectos software.
• Conocimiento sobre principios de diseño como inyección de dependencias, inversión de control, DRY, KISS, SoC y un largo etcétera.
• Desarrollo con integración continua y cobertura total con pruebas unitarias y de integración.
• Experiencia de análisis de calidad de código.
• Habituado a refactorizar código y desarrollo de código limpio.
• Experto en realizar código mantenimible y evolucionable.
• Dominio de arquitecturas software escalables.
• Conocimiento de principios de usabilidad en interfaces de usuario.
• etc.

Aunque sólo son un ejemplo, todas esas aptitudes son mucho más importantes que dominar cualquier tecnología en particular: con cualquier lenguaje, sistema operativo, framework o entorno de desarrollo se pueden aplicar esas técnicas, principios y métodos impresindibles para generar productos software de calidad.

Cualquier desarrollador con dominio de todos esos temas va a seguir aplicándolos con cualquier nueva tecnología con la que tenga que comenzar a trabajar.

Aparte de una actitud positiva hacia el trabajo y buena disposición a trabajar en equipo, a lo anterior añadiría afirmaciones de tipo "Mis últimas lecturas técnicas han sido...", "Asistencia en el último año a eventos como...", "Participación en el blog X", etc. Aunque ya todo esto sería mucho pedir.

Es difícil, lo sé, cuando muchas compañías piden "expertos programadores en java", por poner un ejemplo, sin darse cuenta de que cualquier desarrollador mínimamente experimentado puede acercarse al mundo java con un par de semanas de estudio y dos o tres buenos manuales, aunque no por eso va a hacer un buen trabajo necesariamente. Sí va a hacer un buen trabajo si está habituado a implantar todos los conceptos anteriores con cualquier otra tecnología. Otra cosa es que los gestores de proyecto tengan claros ese tipo de consideraciones...

En cierto sentido, todo lo anterior es como la gramática y la ortografía necesarias para escribir una buena novela, en donde el saber escribir una palabra tras otra vendría a ser a conocer bien la tecnología X.

¿Sabes sencillamente escribir aunque tengas un buen vocabulario sin tener claras la gramática que nos permite generar un trabajo de calidad?

Sin clientes, ¿a quién le venderíamos nuestros productos o proyectos software?

Esto es evidentemente una obviedad, es una desfachatez siquiera comentarlo; sin embargo, no siempre tenemos a esos mismos clientes en cuenta para escucharles y que en cierta medida nos ayuden a mejorar todo aquello que hacemos y cómo lo hacemos.

Por lo general, no programamos o trabajamos en un proyecto cuyo cliente o usuario vamos a ser nosotros mismos, sino que siempre, de algún modo, vamos a realizar algo para que lo utilicen otros. No entiendo, por tanto, por qué no se trabaja intensamente con una actitud de escucha y recopilación activa de sugerencias y críticas para mejorar aquello que hacemos.

Es cierto esa frase ya clásica en software que dice que "el cliente no sabe lo que quiere" hasta que se le comienza a enseñar algo de esa nube abstracta de funcionalidad y requerimientos que pide. Pocos, muy pocos proyectos, comienzan con una definición clara y exhaustiva de requisitos. Por tanto, lo más normal (y natural) es que el cliente o nuestros usuarios comiencen a matizar y a solicitar nueva funcionalidad cuando ya por fin tiene algo entre manos que tocar y usar.

Esto no es malo, no hemos hecho nada erróneamente: sencillamente es lo habitual. Hay que vivir con ello y sabiéndolo, anticiparemos posibles problemas por desviaciones en tiempos y esfuerzos.

En realidad, esa falta de definición inicial es una gran ventaja si la sabemos usar correctamente.

Independientemente de quien esté más en contacto con tu usuario final, es imporantísimo para mejorar todo aquello que haces escuchar activamente las sugerencias, opiniones y críticas (positivas o no) de quienes en definitiva están usando el resultado de tu trabajo.

¿Y para qué? Sólo de esa manera vas a obtener una información muy valiosa:

• Entenderás mejor las necesidades específicas del cliente.
• Comprenderás mejor cómo este usa el producto.
• Manteniendo una actitud abierta, podrás recibir sugerencias de mejora que nunca se te habrían ocurrido.

En definitiva, dejas que los usuarios de tu producto (que además pagan por él directa o indirectamente) lo moldeen en cierto sentido para ajustarse mejor a las necesidades que tienen.

Como desarrolladores, en ocasiones se nos olvida que no programamos un producto o proyecto para nosotros mismos, sino que lo hacemos exclusivamente para que otros lo usen para resolver algún problema en particular. El cliente o usuario, en definitiva, es quien tiene la última palabra para validar si lo que se le entrega está bien, mal o es una solución más bien mediocre. Sin usuarios contentos, no hay producto (obviedad), y tampoco nadie que pague por nuestro trabajo (otra obviedad).

No siempre es fácil reconocer que algo en lo que se ha estado trabajando mucho tiempo, al final no sirve para nada (porque ningún usuario lo utiliza). Tampoco solemos tener una actitud suficientemente abierta como para encajar críticas que nos suenan negativas.

En el último año he tenido experiencias al respecto bastante buenas. Desde hace tiempo, uno los productos que comercializamos en la compañía para la que trabajo (y cuyo desarrollo lo he liderado yo desde el primer momento) ha evolucionado y crecido, básicamente, con el feedback activo de nuestros clientes consolidados que lo utilizan.

¿Resultado?

Me gustaría pensar que hemos ganado con esta actitud activa de escucha lo siguiente:

• Reconocemos todas aquellas mejoras que el cliente necesita en su día a día.
• Este feedback en realidad es una información valiosísima que nos permite generar un producto más cercano aún a las necesidades de ese mercado en particular.
• El cliente se siente valorado al tenerse en cuenta sus sugerencias.
• El producto evoluciona, por tanto, los clientes sienten que están usando (y pagando) un producto que mejora con el tiempo.

Del mismo modo, es difícil a veces saber identificar aquello que ese cliente solicita y que es muy particular y específico de aquello que realmente se puede incorporar como nueva funcionalidad útil al producto.

Esto es realmente lo que se persigue con una aproximación lean al sacar nuestros productos, tal y como lo describe Eric Ries en su libro El Método Lean Startup.

Son muchas las experiencias que se cuentan sobre la aproximación MVP (minimum viable product) para la generación de nuevos productos y la validación de ideas. Es decir, antes de dedicar mucho esfuerzo al desarrollo de algo que crees que va a funcionar, primero sacas un simple (y barato) prototipo para que lo valide tu entorno más cercano (que perfectamente pueden ser amigos y familiares). Con la información que recabes de ellos vas a validar tu hipótesis sobre la idea inicial o no; en caso negativo, también tendrás suficiente información como para abandonar esa idea (porque a nadie le interesa) o pivotar, es decir, evolucionarla para ajustarla mejor a una base mayor de posibles usuarios o clientes.

Podemos ser magníficos desarrolladores de software y crear soluciones limpias, evolucionables y maduras, pero si nadie las usa, entonces todo quedará en un bonito e inútil ejercicio o pasatiempo de fin de semana (con muchas horas de esfuerzo derrochadas e inútiles). De ahí que me interesen tanto todos esos aspectos que rodean el éxito de un producto software, sea éste del tipo que sea, una aplicación pesada de escritorio, un portal web o una aplicación móvil.

Recientemente me he acordado mucho de esto al leer Vender es Humano (de Daniel H. Pink); este es un libro muy interesante que recomiendo y que considera la venta como algo consustancial a cualquier actividad que realizamos. Todos, en el fondo, somos vendedores de algo, es decir, necesitamos usuarios o clientes que paguen por lo que hacemos. Venderemos más y mejor si además mantenemos una actitud abierta de escucha y si alentamos y recibimos con agrado cualquier tipo de feedback.

Durante el trabajo escribiendo El Libro Negro del Programador y después de su publicación (hace ya medio año), he recibido multitud de mensajes, sugerencias y observaciones. Todos esos comentarios me ayudaron (y lo siguen haciendo) a mejorar lo que hago, pero algunos de ellos me dieron bastante que pensar.

En concreto me indicaban que por fin se escribiera afortunadamente en castellano un libro en el que se recogieran el tipo de experiencias que trato en él y se hablara explícitamente de clean code, refactorings, etc, lo que me chocó bastante con la suposición de que los desarrolladores de software, programadores, analistas, informáticos en general, tengan un dominio suficiente del inglés como idioma en el que se encuentra gran parte de la literatura técnica que abarrota nuestras estantarías.

Pues bien, esa suposición no es del todo cierta y muchas veces lo que se pretende es poner en el currículum lo que se espera poner en él. ¿Habéis visto alguna vez un currículum en el que alguien no ponga eso de "nivel medio de inglés hablado / escrito"?

Unos meses atrás tuve en la oficina donde trabajo dos becarios que durante un tiempo hicieron con nosotros sus prácticas. Reconocían que les costaba mucho leer en inglés y que además preferían mil veces leer posts o libros en español.

No estoy hablando de que se ignore que nuestra profesión esté dominada por el inglés y que si queremos ofrecer nuestros servicios en un mercado global, necesariamente, sí o sí, hay que hacerlo en ese idioma. De lo que se trata es de reconocer que existe un enorme vacío de contenidos técnicos de desarrollo de software de suficiente calidad y de prestigio en nuestro idioma materno, y precisamente por ello existe una gran oportunidad para llenarlo.

En mi opinión, la razón por las que no existe un mercado auténticamente desarrollado de literatura técnica en castellano escrito por y para hispanohablantes (y no simples traducciones que en ocasiones son muy defectuosas y caras) es que no asociamos la estrecha relación que existe entre ser bueno o muy bueno en tu profesión y dedicar parte de tu tiempo a enseñar a otros sobre lo que mejor sabes hacer.

Nos falta dedicar más tiempo a enseñar y hacerlo como algo natural y como parte de nuestra profesión.

Como se suele decir, no sabes algo hasta que no eres capaz de explicárselo a tu abuela. Esta semana sin ir más lejos, le estuve mostrando a mi hija mayor cómo hacer un sencillo programita con javascript (en NodeJS) para sumar y restar, y reconozco que me costaba mucho trabajo explicar cosas para mí tan fundamentales de la programación que casi no reparamos en ellas. Entre otras cosas, me preguntaba que si para hacer ese programa para sumar se necesita otro programa (el editor de texto más el que lo ejecuta, y a su vez estos se hacen con otros programas), entonces ¿quién hizo el primer programa?...

Desafortunadamente, me encuentro con que muchos de los que sí escriben algo en forma de posts, aparte de que no les dan una continuidad y a los pocos meses el blog está completamente abandonado, lo hacen porque se sienten un poco obligados a hacerlo o para obtener cierto tipo de prestigio..., pero no por una vocación auténtica de enseñar o compartir.

Nos falta una auténtica cultura de compartir aquello que mejor sabemos hacer, sea esto lo que sea para cada uno. El conocimiento, si se guarda tras una coraza, termina devaluándose, cuando en realidad se amplía al compartirlo con otros. Estoy convencido de que existe una relación entre tu solvencia técnica y tu capacidad de mostrar y enseñar lo que sabes hacer bien.

Ya escribí en El Libro Negro del Programador un capítulo relacionado y titulado "Esclavo de tu propia solución o cómo querer ser imprescindible", acerca de cómo en entornos laborales en donde la competencia entre tus propios compañeros es palpable, se tiende erróneamente a intentar crear tu propia parcela de dominio (y que con el tiempo termina convirtiéndose en una auténtica jaula perdiento oportunidades).

Personalmente he aprendido mucho más escribiendo y compartiendo los capítulos del libro que si sencillamente nunca me hubiera parado a escribir sobre esos temas.

Se aprende leyendo libros, claro está, viendo videos, hablando sobre los temas que te interesan, pero también escribiendo, lo que es una aproximación distinta a ese conocimiento pero que te permite profundizar en él.

La percepción que tengo es que es un buen momento para liderar proyectos y escribir en castellano textos de calidad relacionados con tecnologías software. Afortunadamente, ya no hace falta contar con el premiso de ningún grupo editorial para que la obra, si es buena, se divulgue rápida y viralmente por Internet y te permina tener éxito.

Del mismo modo, creo que existe un gran número de desarrolladores de software que no dominan el inglés suficientemente y que si contaran con mejores contenidos en español, tendrían entonces una mejor formación y motivación para ser aún mejores en su profesión. Lo que quiero decir es que si el mundo anglosajón cuenta con muchos más proyectos de éxito (y más sonados) y en el mundo hispanoparlante no, puede estar relacionado con la ausencia de contenidos formativos de calidad en nuestro idioma.

¿Oportunidad? ¿Posible fuente de nuevos proyectos? Quién sabe, pero desde luego lo que sí es cierto es que si existiera un magnífico portal en nuestro idioma como sitepoint.com, con buenos contenidos, por poner un ejemplo, muchos de sus usuarios hispanoparlantes no dudarían en usarlo.