Rafa G. Blanes Blog

Las Doce Claves: Doce Habilidades y Estrategias para Emprender con Éxito

Este es mi primer trabajo para un público general, no necesariamente técnico, interesado en todo lo relacionado con el emprendimiento, en donde describo las doce habilidades y estrategias que a mí me han resultado más útiles cada vez que he puesto en marcha un nuevo proyecto o he tenido un nuevo propósito que felizmente he terminado con éxito.

Curiosamente, de mi anterior libro, “El Arte del Emprendedor Digital”, he recibido un feedback inesperado. La mitad de su contenido trata de los aspectos más técnicos que he puesto en marcha al implementar Hub de Libros, el resto, son capítulos de desarrollo personal y de estrategias de emprendimiento: prácticamente ha sido una constante los comentarios en que me indicaban que de ese otro libro, los capítulos de este último tipo habían gustado tanto o más que los estrictamente técnicos, algo que, por otra parte, no me sorprende en absoluto puesto que lo profesional difícilmente irá a mejor si no se dominan ciertas habilidades personales.

De modo que en “Las Doce Claves”, he extraído todos esos capítulos, los he revisado a conciencia exhaustivamente y los he adaptado a un público más general, quitando todo aquello que sonara excesivamente técnico.

¿El resultado? Mi primer libro de desarrollo personal útil para cualquier persona que abrace el emprendimiento como modo de vida o que sencillamamente esté pensando en lanzar nuevos proyectos.

Sin duda, existen muchas otras claves para crear un proyecto de éxito, y qué duda cabe también de que existen autores mucho más reputados que yo y que considero mis propios mentores y que recomiendo encarecidamente (como Raimon Samsó, Sergio Fernández, Tony Robins, Brian Tracy, y muchísimos otros).

No obstante, en “Las Doce Claves” se encuentra lo que yo he valorado más a la hora de poner en marcha proyectos como Hub de Libros y otros con anterioridad, después de mucho tiempo analizando cuáles eran esos atributos, virtudes y actitudes más importantes para avanzar en ellos, o al menos los que a mí me han resultado más útiles.

¿Y cuáles son esas claves?

En el juego del emprendimiento predominan ciertas habilidades personales, pero también otras de tipo organizativo, más aún en personas que, como yo, tenemos muchas otras responsabilidades profesionales y familiares (como la mayoría de la gente).

En cierto modo, se puede decir, que quienes emprendemos fuera de nuestros trabajos oficiales, tenemos algo así como un doble trabajo, de ahí que la optimización del tiempo y la productividad sean esenciales.

Si al cocktail le añadimos que queremos poner en marcha un proyecto ciertamente complejo que nos llevará bastante tiempo y dedicación, entonces es necesario avanzar en él con una planificación basada en tareas. Es más, en microtareas, que, bien definidas y de corta duración (preferiblemente menos de una hora), hará que puedas avanzar en tu proyecto cada día. Piénsalo, tres o cinco microtareas al día, durante una semana, un mes, varios meses, son muchas tareas completadas que necesariamente te acercarán al final de tu proyecto.

Divide tu proyecto, o cada semana que trabajas en él, en pequeñas tareas muy concretas, utiliza una herramienta tipo to-do y ve completándolas a tu ritmo, pero con constancia.

Pronto descubrirás el placer que supone ir eliminándolas de la lista.

Hub de Libros es una realidad después de un año de haber completado quizá varios miles de microtareas, pero de forma constante y lo mejor organizadas posible.

Avanzar así, forma parte de una cultura de trabajo basada en kaizen, esto es, de una fisolofía de vida en la que mejoramos constantemente pero a muy pequeños pasos. Lo importante no es la velocidad, ni la cantidad, sino el saber que todo es revisable y susceptible de mejora, y, como resultado, con el tiempo, se produce un efecto bola de nieve sorprendente.

Yo he integrado kaizen a muchos aspectos de mi vida, desde mi cuidado físico hasta la forma de enfocar mi trabajo profesional, y tan solo me digo a mí mismo que ojalá este concepto lo hubiese conocido mucho antes.

Kaizen es uno de esos conceptos que engloban una riqueza increíble, como ikigai y otros parecidos de la cultura japonesa, demasiado para exporner todos sus detalles y matices en un simple artículo. Tan solo animo a indagar más en él y a incorporar kaizen en tu día a día.

Por otra parte, dejamos que se apoderen de lo más importante que tenemos en nuestra vida: nuestra atención y nuestro tiempo.

Continuas llamadas, interrupciones, notificaciones de las aplicaciones de nuestro smartphone, reuniones dispersas, improvisadas e interminables, etc. Todo ello hace que no podamos trabajar apenas concentrados. Sin embargo, para llegar al fondo de una tarea y para realizarla sin estrés y lo mejor posible, hace falta trabajar la mayor parte del tiempo concentrado. Sencillo, evidente, pero no fácil de conseguir en un día a día que parece que cada vez está más lleno.

Y yo me pregunto, ¿lleno de qué?

Seguramente si analizamos en qué se nos van las horas del día y los días de la semana, lleguemos a una conclusión sorprendente: pasamos demasiado tiempo haciendo tareas improductivas, sobre todo si somos personas acostumbradas a ser incapaces de decir no a todo lo que los demás nos exigen.

De ahí que en Las Doce Claves, simplificar nuestro día a día, nuestra vida en general, vaya, y tratar de trabajar lo más concentrados en nuestras propias islas de concentración, es imprescindible.

Pero emprender un proyecto, sobre todo si se espera de él algún resultado económico en un mercado incierto, voluble e impredecible, no se puede dejar al azar, necesitas un método, pero no un sesudo y pesado documento de modelo de negocio de quinientas páginas, sino algo ágil, práctico y que cualquiera puede poner en marcha.

Tu proyecto no es un proyecto en realidad, sino una hipótesis que tienes que validar.

¿Quién la valida? Los usuarios, claro.

¿Cómo lo validas? Con datos, por supuesto.

De ahí en Las Doce Claves haya un capítulo especial a la metodología Lean, propuesta inicialmente por Eric Ries en su libro ya clásico y de título “El Método Lean Startup: Cómo Crear Empresas de Éxito Utilizando la Innovación Continua”, y que dio lugar a una auténtica cultura lean tan productiva como útil.

Que el título del libro de Eric Ries no te asuste, es útil y ameno para cualquier persona con o sin experiencia y que quiera conocer cómo avanzar en un proyecto dirigiéndolo hacia más y mejores resultados mediante pequeñas pero frecuentes iteraciones de trabajo: crear / lanzar / medir / iterar. Así, hasta que, poco a poco, los resultados se van dejando ver.

Como comento en Las Doce Claves, tu proyecto emprendedor es un barco a la deriva en un mar enorme e impredecible: tu trabajo consiste en dirigir el rumbo para llegar al puerto al que te interesa arribar.

¿Cómo? Con datos medibles, con qué si no.

De la mano de lean, hay un capítulo dedicado a la importancia de la recopilación de analíticas, esto es, los datos realmente importantes que necesitas conocer de tu proyecto para evaluar su tendencia y éxito. Me gusta afirmar que en este capítulo desmitifico totalmente todo lo relacionado con la adquisición de datos de tu proyecto en marcha, es tan sencillo como trivial, porque lo importante no es obtener esos datos, sino que sepas que sin ellos, te encuentras ciego ante lo que está ocurriendo. Es como llevar a cabo una dieta y salir a correr tres días en semana y no subirte a la báscula en ningún momento. La analítica consiste en analizar esos datos, sacar conclusiones y tomar decisiones al respecto.

He publicado en GitHub un nuevo repositorio de una librería extraída de todo mi trabajo realizado por el momento en Hub de Libros.

Se trata de Red Entities, un object mapper y query builder con el que hacer transparente el acceso a las entidades de datos con algunas particularidades que me animaron hace un año a construirlo y no usar otro tipo de proyectos similares. De momento, es compatible con varios sabores de Mysql y Sqlite y probado con Node.js 10, 12, 13 y 14.

Aunque he utilizado mucho GitHub y tengo publicados varios repositorios, con Red Entities he trabajado mucho en la documentación y en el ciclo de vida para publicar un proyecto así y que esté disponible también como paquete en NPM.

Tal y como comento en la documentación, hay una intención de diseño detrás de Red Entities, relacionada con la concepción de proyectos altamente escalables, esto es, proyectos que van a crecer mucho en todos los sentidos y que, además, no tenemos ni idea de hacia dónde se van a dirigir.

En software hay un principio que no siempre tenemos en cuenta: proyecto acotado, claro, con requisitos muy claros, que comienza y termina y punto... se puede hacer con cierto diseño y arquitectura y el ciclo de vida y metodología que elijas. Proyecto no claro, producto mínimo viable, requisitos impredecibles, reglas de negocio cambiantes... hay que hacerlo con un diseño, concepción y arquitectura totalmente diferente y una metodología ágil más abierta e iterativa. Sutil de pillar, pero con profundas consecuencias en el software que se genera de un modo u otro.

Y esto afecta, claro está, a cómo persisten los datos, cómo se utilizan y cómo evolucionan las bases de datos: al evolucionar las reglas del negocio y funcionalidad, lógicamente, las estructuras de bases de datos (sean las que sean), también cambiarán. Para que esto no suponga una pesadilla, hay que aplicar un enfoque, digamos, más laxo, con sus inconvenientes, claro, pero con las ventajas que comento en este post.

Digresión...

Sé que a algunos les parecerá extraño lo que voy a indicar a continuación, porque va en contra de ciertos paradigmas muy asentados e incluso aprendidos en nuestra etapa académica:

Los modelos de datos relacionales son un obstáculo en sistemas que van a crecer mucho y cuya evolución desconocemos totalmente.

Si cuentas con un proyecto cerrado (se sabe lo que hay que hacer, la lógica de negocio está muy bien especificada, y, además, se entrega y punto, poco más va a ser cambiado), entonces es perfecto utilizar como repositorio de datos con sus entidades relacionadas (relaciones 1..n, 1..1, etc.), que son restricciones sobre el uso y distribución de los datos entre diferentes tablas, manteniendo así en todo momento la integridad referencial y facilitando cosas como la eliminación en cascada, transacciones, rollbacks, etc. Incluso ligar el proyecto a una tecnología concreta de servidor de base de datos (Sql Server, Postgresql, Mongo, etc.)

Sin embargo, siempre (SI-EM-PRE) que he visto un proyecto que ha crecido mucho con funcionalidad inimaginable al principio y se ha querido mantener un enfoque relacional en los datos a toda costa, siempre, digo, el resultado ha sido horroroso: un número exagerado de tablas, reduncancia de datos, complicación extrema en las migraciones y todo cogido con pinzas. Recuerdo ese proyecto con más de cien tablas (sí, más de cien) y tantas líneas indicando sus relaciones que aquello parecía el mapa del metro de Londres. ¿Resultado? Imposible de mantener, cualquier cambio suponía un enorme dolor de cabeza, fallos en producción por efectos colaterales imposibles de prever y ya no hablemos del rendimiento.

En estos casos, hace falta un enfoque diferente, más bien pensar con un paradigma diferente.

Hace falta una componetización radical del sistema, en donde la funcionalidad está distribuida en pequeños componentes que se hablan entre ellos cada uno con su dominio de trabajo. La funcionalidad de alto nivel se implementa mediante la orquestación de los mismos.

Por su parte, puesto que su tamaño es por definición pequeño, cada componente maneja por tanto un conjunto reducido de entidades de datos, sobre los que realiza básicamente actividades CRUD.

Y nada más, porque esta es la clave de construir sistemas grandes que evolucionan mucho.

Este enfoque nos da una libertad extraordinaria para evolucionar el sistema (con más componentes, con cambios en los modelos de datos, etc). En Hub de Libros, sistema donde he empleado claramente este paradigma, además de haber más de setenta componentes actualmente, tan solo dos utilizan en su modelo de datos tres entidades (tablas) diferentes, con poco acoplamiento además y, en total, el sistema cuenta con seis bases de datos diferentes, cada una con un propósito distinto y una política de backups también diferente.

Claro, lo que ganamos por un lado, requiere pagar un precio, como siempre: nos quedamos sin la maravillosa integridad referencial, pero el precio bien vale la pena. Ésta hay que mantenerla programáticamente. No obstante, y después de trabajar en dos proyectos que siguen creciendo con este paradigma, eso no es un problema relevante dadas las ventajas de manejar pequeños modelos de datos para componentes pequeños.

Red Entities, proyecto que ahora libero a la comunidad para su libre uso, permite eso precisamente: definir un esquema (modelo en un objeto json), implementarlo con una línea de código (crear su estructura de datos en Mysql o Sqlite) y una sintaxis insultantemente sencilla y rápida de escribir para realizar las operaciones CRUD habituales, mediante lo que denomino selectores y que me recuerda en cierto modo a la eficacia de jQuery.

Sé que hay otros proyectos similares y mucho más ambiciosos, pero dada la importancia de esta librería en Hub de Libros, decidí desarrollarla desde casi desde cero después de haber trabajado el año anterior en un concepto parecido pero para Redis (Blue Entities) y evolucionarla para no depender en Hub de Libros en este punto tan importante de terceros. No he encontrado, digo, un object-mapper & query builder con las características para implementar componentes como se hace en Hub de Libros y los proyectos en los que trabajaré próximanete dentro de Mantra Framework.

Sin entrar en detalles, punto importante: la actualización de un esquema a otro (por un cambio en una propiedad, otro índice, o cualquier otro cambio), es trivial de realizar, algo que ahora mucho esfuerzo en la vida de cualquier proyecto.

Confío en que sea de utilidad y que haya quienes se animen a utilizar Red Entities en sus propios proyectos.

Llevo muchos años estudiando (e implementando) todo lo relacionado con las prácticas de código limpio y de «refactorings», para lo que he escrito muchos artículos así como «El Libro Práctico del Programador Ágil» e impartido varias formaciones.

He descubierto que cuando un programador lleva varios años haciendo algo a «su modo», con sus vicios y virtudes, es muy difícil cambiar su forma de trabajar. Esto es totalmente humano: nos aferramos a lo conocido (aunque intuyamos que ahí afuera hay formas mucho mejores). Te vas a dar cuenta de ello si todos tus proyectos los haces más o menos de la misma forma.

Ignoro si es precisamente por haber roto la barrera de los cuarenta años, pero con el tiempo te vas dando cuenta de que se disfruta más de la vida (de tu hogar, de tu familia y amigos) evitando la complejidad y, quizá, instalando en el día a día cierta rutina productiva y creativa.

Esto es, por alguna razón misteriosa, solemos caer en ese error de creer que algo cuanto más complicado, mejor, cuanto más, aún mejor, sin pararnos a pensar en ello ni vislumbrar la posibilidad de que ese algo, sea lo que sea, se puede hacer de un modo más sencillo y con el mismo resultado.

Recuerdo con cariño a un antiguo compañero de trabajo de una etapa laboral anterior; era muy bueno técnicamente, lo que hacía funcionaba, y lo desarrollaba rápido, pero tenía el problema de que solo lo entendía él. Cualquiera que tuviese que asumir algunos de sus proyectos o librerías, tenía un problema serio.

También me he encontrado, a mi pesar, ciertas actitudes de profesionales que intentan hacer las cosas exageradamente complejas adrede (como si así su valor fuese mayor) y hasta clientes que, al percibir la complejidad de un producto, asocian extrañamente que también su valor es mayor.

Mi opinión es que más que añadir complejidad, hay que quitarla y buscar lo simple. Y aún mejor si es extremadamente simple: en tu trabajo, en la forma de abordar proyectos, y también hacer simple el resto de cosas de nuestra vida, las relaciones familiares, nuestro hogar, nuestros hobbies, etc.

Simple no quiere decir fácil, más bien lo contrario. Buscar la sencillez suele ser algo complejo, por extraño que parezca, al menos al principio.

En los últimos años he leído mucho acerca del minimalismo, «downshifting» y conceptos parecidos, para lo que recomiendo un título que me gustó especialmente: «El Arte de Vivir con Sencillez», de un monje zen japonés de nombre Shunmyo Masuno.

¿Y qué tendrá que ver esa filosofía de vivir de forma sencilla con el desarrollo de software?

Pues todo, porque en definitiva, volcamos en nuestro trabajo nuestro modo de pensar y de actuar. La mente dispersa de una persona poco disciplinada, que divaga, desconcentrada, cuyo escritorio de trabajo es un almacén de recuerdos desordenado y cuyo hogar muestra la misma falta de orden (y limpieza), necesariamente va a impregnar su trabajo creativo con su mismo modo de vida.

Sí, Charles Bukowski, por poner un ejemplo, era un gran escritor, pero también un alcohólico amargado y seguramente un cerdo como persona, pero dejemos a los genios como la excepción que confirma la regla.

De unos años hasta ahora, soy un apasionado de la sencillez y de lo simple, y con el tiempo he descubierto que en el desarrollo de software esto trae muchas más ventajas de lo que pueda parecer al principio.

Hacer un proyecto software sencillo no es trivial, es más, pienso que, al contrario de lo que parece, es algo bastante complicado para lo que hace falta mucha experiencia.

Pero también hace falta buscar la sencillez dedicándole tiempo y parte de las iteraciones de desarrollo.

«Esto ya funciona», me digo a menudo, pero «¿hay algún modo de simplificarlo aún más?»

En la realización de productos que lidero para la empresa que es mi principal cliente, siempre organizo «sprints» para mejorar esto y lo otro antes de avanzar con más funcionalidad y, como consecuencia, la velocidad posterior es mayor (cómo me cuesta trasladar esta idea a los responsables de equipos…).

No es un capricho, es más bien una necesidad, sobre todo en productos y proyectos que sabes que te van a acompañar mucho tiempo o que en algún momento tienes que delegar en otros. Cuanto más sencillo, más barato y fácil será su evolución y con más facilidad otros compañeros asumirán ese trabajo. Hazles un favor y déjales las cosas limpias y ordenadas, te lo agradecerán.

Si necesitas comenzar a delegar para crecer profesionalmente y asumir otro tipo de responsabilidades, todo irá mejor si aquello que delegas puede ser digerido fácilmente por otros. Es decir, esa búsqueda de la sencillez en lo posible, te permite más libertad.

Busco siempre soluciones sencillas, lo más sencillo que se pueda poner en práctica, sin sacrificar, claro está, las buenas prácticas y el buen diseño, hasta el punto en el que si veo un trozo de código con cierta complejidad, no me quedo tranquilo hasta que lo «limpio» y encuentro un modo de simplificarlo, algo que quizá casi nunca te lleva más de un minuto.

Curiosamente, al hacer ese trabajo, descubres que esa forma de afrontar la programación genera diseños más robustos, capaces de abordar muchísimo mejor los cambios en el futuro.

Piénsalo, ¿para qué complicarnos la vida cuando podemos vivir de un modo más simple e igualmente gratificante, o incluso más? ¿Por qué implementar algo de forma rebuscada cuando lo podemos hacer con una sencillez envidiable?

De vez en cuando, me gusta realizar el siguiente ejercicio: navego un poco por GitHub a la caza de proyectos que me llamen la atención. Entro en ellos y, sin saber exactamente qué hacen ni cómo, busco puntos de mejora evidentes (para hacerlos más sencillos), reconociendo rápidamente los «bad smells» (o «malos olores») y tratando de imaginar un modo de hacerlo un poco mejor, refactorizando esto o aquello, cambiando esto otro para que esté más limpio y legible.

En ocasiones, me encuentro con auténticas joyas en este sentido, proyectos admirables de desarrolladores con un código envidiable y muy trabajado. Por extraño que pueda parecer, te puedes preguntar… ¿cómo serán el escritorio y la casa de esta persona? ¿Habrá coherencia entre este magnífico trabajo y su modo de vida? Apuesto a que sí.

Añade sencillez a tu trabajo, a tu organización y metodologías, a tu código, a tu forma de expresarte y de comunicar tus ideas y tus presentaciones, al contenido de tus correos y multiplicarás los resultados de todo tipo.

Solo sobrevive lo simple, lo artificialmente complejo suele terminar abandonado.

«Como haces algo, así lo haces todo»

PD: Este es un capítulo (completo) de «El Arte del Emprendedor Digital».

PD2: También publicado en Medium.

Los que hayan leído mi último libro ("El Arte del Emprendedor Digital"), habrán comprobado por qué es una buena estrategia desglosar la arquitectura de un proyecto software en componentes (sobre todo si el proyecto es de tamaño medio o grande y va a evolucionar mucho). De este modo (y sin entrar en demasiado detalle), la funcionalidad del sistema está ordenada en responsabilidades independientes, fácilmente localizable y modificable.

La clave está en que cada componente (llámalo módulo si quieres), sea pequeño, se encargue de algo muy concreto y específico, y que cuando haya que afrontar una funcionalidad más amplia, se pueda distribuir ésta en varios componentes que se hablan entre ellos. ¿Cómo? Pues según la tecnología y el framework de trabajo que se haya utilizado para implementar este esquema.

Hub de Libros cuenta ahora mismo con más de ochenta componentes, mientras que un proyecto sencillo en el que he trabajado recientemente, tiene ya unos treinta (muchos de ellos reutilizados de otros proyectos).

Puede parecer que se desmadra un poco la cosa cuando hablamos de decenas de módulos independientes, aunque quizá solo los que (como yo) hayan sufrido en alguna ocasión una solución monolítica con mucha funcionalidad (cientos de miles de líneas de código), podrán comprobar las bondades de esta arquitectura. En otro proyecto diferente que he dirigido en Solid Stack, actualmente cuenta ya con más de cien (y subiendo).

Si te enfrentas a un proyecto con cientos de kloc (1 kloc = mil líneas de código) y en él no hueles nada a componente o módulos independientes, malo.

Ahora bien, en todo sistema grande existe funcionalidad de alto nivel que afecta o utiliza un conjunto de funcionalidades de bajo nivel. Tenemos siempre la tentación de implementarla directamente y por separado, y aunque esté encapsulada en su propio componente, finalmente lo que tenemos es, de nuevo, un componente grande y monolítico, más difícil de cambiar, de probar y de evolucionar, y que es justo lo que queremos evitar.

Existe otro enfoque para implementar esa funcionalidad de mayor nivel basado en eventos, esto es, cuando ocurre algo en el sistema, un componente hace algo en concreto y simple, tan solo emite el evento correspondiente por si hay otra parte del sistema que necesita saber que ese evento se ha producido. La gestión de ese evento ni siquiera se tiene que producir en la misma aplicación, sino que pueden existir auténticas infraestructuras software para gestionar eventos en aplicaciones independientes. Redis, sin ir más lejos, permite un esquema de suscripción/publicación que facilita esa comunicación entre procesos para casos en los que hay que gestionar cientos o miles de eventos por segundo.

Por poner un ejemplo, si cuando un usuario se loguea en el sistema hay que guardar cierta información en el log de actividad, o lanzar un informe para su panel de control personalizado o cualquier otra cosa, todo eso no se debe implementar en el mismo componente que se encarga de la seguridad de los usuarios, éste tan solo emite un evento de tipo "users.userloggedin" (es tan solo un nombre descriptivo), y algo en alguna parte del sistema se encargará de realizar lo que haya que hacer cuando eso ocurre.

De este modo, existen componentes base que implementan funcionalidades muy canónicas, pero también, y como parte de una arquitectura bien estructurada en responsabilidades, existen otros componentes que se encargan de implementar funcionalidad de más alto nivel que afecta a grupos de componentes. ¿Cómo? Gestionando eventos y orquestando la funcionalidad de diversos componentes del primer tipo.

Rara es la funcionalidad de alto nivel que no se pueda implementar de este modo. En ocasiones, toda esa funcionalidad de ese tipo, se incluye en lo que se denomina capa de integración, e incluso se implementa bajo el concepto de flujo de trabajo o proceso de negocio.

La gestión de esos eventos no tiene por qué ser siempre síncrona (retrasando quizá la interacción del usuario con el sistema), sino que se puede plantear hacerla en segundo plano.

Con esta estrategia, todo sigue encapsulado en componentes sencillos, mientras que aquellos que se encargan de integrar funcionalidad más compleja tan solo orquestan los primeros, manteniendo incluso una implementación sencilla: ante el evento tal, hago esto y después lo otro.

Sin duda, la gestión de eventos y su orquestación son herramientas fundamentales para implementar sistemas software grandes.

En breve, voy a publicar en GitHub un proyecto en el que he ido trabajando desde hace un año y que da soporte a mi propia plataforma de publicación abierta (Hub de Libros). Se trata de un framework al que le he puesto el nombre de Mantra Framework, escrito en Node.js y que permite crear componentes altamente desacoplados para encarar proyectos grandes y que van a evolucionar mucho, tal y como describo con más detalle técnico en mi último libro (El Arte del Emprendedor Digital). Confío en basar en este framework muchos proyectos de aquí en adelante, al menos todos los basados en Node.

Tanto a un proyecto como al otro, le dedico todo el tiempo que puedo con la ayuda además de algunos colaboradores; en cualquier caso, analizando Mantra Framework, no me deja de sorprender la naturaleza de una actividad como es la programación, después de dedicarme a esto profesionalmente toda mi vida (en mis primeros escarceos tenía tan solo doce años).

Mi actividad profesional se reparte entre atender responsabilidades de desarrollo de negocio, tratar con clientes directamente, dirigir un equipo de desarrollo y también desarrollar y diseñar directamente proyectos como el anterior, además de todo lo relacionado con la publicación de mis libros (que, por el momento, son cinco técnicos y dos novelas).

Cualquiera que haya leído tan solo alguno de mis libros, sabrá que todo lo que hago está relacionado directamente con el desarrollo de software, más orientado a productos que a proyectos específicos y particulares para clientes, esto es, paso parte de mi tiempo programando, de ahí las siguientes reflexiones sobre el acto de programar y las sutilezas que esconde esta actividad y esta profesión.

Ciertamente, programar es una actividad poliédrica que se puede considerar sencilla, pero también puede ser muy compleja. Como suelo poner como ejemplo, no es lo mismo construir un chamizo que un rascacielos, como tampoco lo es construir algo pensando en que dure tan solo unas semanas a diferencia de que deba aguantar años. Y, sin embargo, paradójicamente, puedes tener éxito afrontado el software desde un lado y el otro, aunque el coste sea diferente, como veremos a continuación.

A menos que te lo propongas, cualquiera puede aprender en un videocurso de un fin de semana algunas nociones y comenzar a hacer cosas útiles, mientras que los más experimentados, no dejamos de tener nuevas percepciones y descubrir nuevos detalles que nos sorprenden en algo que llevamos haciendo años (“¡ah!, mira, nunca había reparado en esto o en las consecuencias de hacer esto otro de este modo, curioso…”)

Del mismo modo que un autor siempre escribe para contar algo que sea de utilidad a otros (entretenimiento, formación, cultura, crítica, opinión, etc), en esencia, programar consiste en resolver algún tipo de problema utilizando algún dispositivo para dar también utilidad a otros.

Esto es, salvo que programes por puro juego y divertimiento (como hago yo en ocasiones para experimentar), programamos para servir a los demás.

No importa de qué modo, en qué entornos, con qué lenguajes de programación, si dentro de una pequeña o gran empresa o como freelance, siempre programamos para ofrecerle algo a alguien. En mi opinión, esta es la actitud esencial que deberíamos tener los desarrolladores profesionales, cierta vocación de servicio de cara a nuestros clientes, usuarios de nuestros proyectos y productos y cualquiera que consuma lo que hacemos. En otras palabras, nuestro cliente final es lo más importante, mientras que en ocasiones esto se nos olvida en nuestro día a día.

Por llevarlo al terreno de lo concreto: hace años enfocaba proyectos personales centrándome en lo que a mí me gusta y que confundía con lo que podían necesitar otros. Corregí a tiempo (creo), me sumergí en toda la cultura lean (Lean Startup, de Eric Ries) y está claro que ahora, en todo lo que hago, me centro no solo en un tema que me apasiona (como todo lo relacionado con la literatura y la publicación abierta), sino que lo enfoco desde la perspectiva del usuario final o del cliente. Nos guste o no, esto afecta a nuestra forma de enfocar el software porque cambiamos la naturaleza y la prioridad de los requisitos.

Por otra parte, no solo servimos a una comunidad, sea la que sea, sino también a nuestros propios compañeros que algún día heredarán nuestro código (y lo bendecirán o se acordarán cada día de algún miembro de tu familia). Esto es, programamos también para hacerle la vida un poco más fácil a otros programadores cuando continúen con tu rabajo.

Tu misión como programador consiste en que otros entiendan tu trabajo de la forma más rápida y sencilla posible. Es más, cuanto mejor hagas esto, más podrás delegar y centrarte en aquello en lo que aportas más valor.

En cierto modo, cuanto más útil es lo que hacemos y para más personas, mejor nos irá. Por tanto, no se trata de trabajar más, de programar más y más proyectos, sino de centrarlo todo en escalar la utilidad que éstos ofrecen al mayor número de personas posible.

Programar requiere de un nivel de abstracción que, me temo, no todo el mundo es capaz de desarrollar, puesto que se deben resolver problemas traduciendo la solución usando un lenguaje de programación con sus propios recursos pero también limitaciones. Evidente, pero no lo es tanto que el código que se genera y su calidad depende mucho de ese nivel de abstracción. Observemos tan solo cómo cambia una solución implementada funcionalmente o bien escrita con un lenguaje orientado a objetos: no solo cambia el resultado de lo que se genera, sino la forma de pensar del desarrollador para enfocar el problema. Esto viene a ser algo así como un paradigma mental de trabajo que te hará resolver las cosas de un modo u otro totalmente diferente. En ocasiones, el desarrollador no es que sea malo, es que no ha cambiado aún de paradigma…

Debemos abstraer, sí, pero solo señalo que esta es una habilidad más que debemos tener los desarrolladores, y que no por eso nos convertimos en personas especiales, ni mucho menos.

La programación orientada a objetos no es un capricho académico, es una forma de pensar para traducir un problema programáticamente de un modo más sencillo, generando código con mejor diseño y más reutilizable, qué duda cabe. Sin embargo, es habitual que se utilicen clases como siemple almacén de funciones monolíticas…

Opino que programar es sencillo, cualquiera que se lo proponga puede hacerlo, pero también pienso que programar bien no es fácil, de ahí que me cause cierta sensación extraña esos cursos de dos semanas que prometen hacerte experto de la noche a la mañana. Lo sé, es un simple recurso comercial, claro está.

Programar tiene también connotaciones artísticas además de las técnicas, pensar solo con las segundas y sin las primeras conduce siempre a una mala solución. Lo digo desde la perspectiva de que para programar con éxito, necesitamos desplegar muchísima imaginación y creatividad, más allá de conocer las técnicas y buenas prácticas que sabemos que tenemos que emplear. En muchas ocasiones, la creatividad consiste en encontrar una solución sencilla a un problema que no lo es.

A diferencia de otras disciplinas, algo que también puede resultar extraño es que cuando programamos, tenemos que pensar mucho en hacerlo de un modo que podamos detectar y corregir errores más adelante. Piénsalo, el diseño del código cambia cuando pensamos en el mantenimiento del mismo, del mismo modo que se puede diseñar un coche de cara a que la reparación de sus averías sea sencilla años más tarde. Por alguna razón, esta cuestión cuesta que cale profundo en muchos desarrolladores con los que me cruzo, y si extrapolo, no tengo más remedio que pensar que es algo extendido en nuestro sector.

Inevitablemente, por mucha experiencia que tengamos, por muchas miles de líneas de código que hayamos escrito, siempre (SIEMPRE) programamos cometiendo errores, que bien son detectados por mala sintaxis en tiempo de compilación o en tiempo de ejecución en lenguajes interpretados, además de log bugs que se producirán aunque el código sea perfecto. No conozco ninguna otra actividad en la que se avance creando algo nuevo pero al mismo tiempo corrigiéndolo continuamente.

Como autor de cinco libros técnicos y dos novelas (por el momento), es evidente que una de mis actividades profesionales consiste en la publicación de libros (que para eso, además, he creado Hub de Libros).

Sin embargo, hasta ahora no he compartido nunca las razones por las que siempre recomiendo a todo el mundo (sí, a to-do-el-mun-do), que de una forma u otra, escriban, ya sea desde un diario, posts (como este) o cualquier proyecto de ficción o no ficción. Al respecto, recomiendo las lecturas de autoras como Julia Cameron y Natalie Goldberg (secreto: cada vez que comienzo un nuevo trabajo, siempre releo alguno de sus libros como forma de volver a centrarme en un proyecto literario).

Quiero compartir aquí uno de los capítulos de la guía gratuita que lancé hace poco y de título "El Manifiesto del Autor Libre: Cómo escribir un libro y publicarlo en el siglo XXI".

Ahí va.

Por qué escribir

El 80% de los estadounidenses, reconocen que en algún momento de sus vidas se han planteado la posibilidad de escribir un libro.

Casi nadie lo hace, y lo más seguro es que sea así por esa extraña «áurea» especial que le sobreponemos a autores consagrados y por desconocer cómo comenzar.

No obstante, al margen de nuestra consideración de lo que sea literatura buena o regular, las razones por las que escribir van más allá de tener éxito o no publicando una obra.

«Escribir» es un proceso mental que descarga nuestra percepción del mundo en el papel.

Existe algo mágico que sucede cada vez que ponemos por escrito nuestros pensamientos, sean en la forma de una historia o relato corto, a modo de diario o esa carta de amor que le escribimos a nuestra pareja.

Escribir supone materializar en el papel parte de la existencia que vivimos cada día (y digerir sus sinsabores y celebrar sus luces).

Si supone una de tus pasiones, dedicar media hora al día a sentarte solo contigo mismo, lápiz en mano o con el ordenador portátil sobre tu regazo, escribir es una forma magnífica de entrar fácilmente en ese estado de «fluir» con el que incluso perdemos la noción del tiempo.

Cuando escribes recuerdas que eres una persona libre: de hablar de lo que quieras, de desahogarte, de tratar de darle un significado a lo incomprensible, de digerir aquella discusión con ese ser tan querido, de tener esa fantasía con el vecino entrenador de gimnasio o la vecina enfermera e incluso de escribir caóticamente, y hasta con faltas de ortografía y de puntuación, cualquier cosa que se te ocurra.

Comprende la vida y tus vivencias… escribiendo.

Elimina el rencor externalizándolo sobre le papel.

Celebra la vida contando ese acontecimiento tan feliz en una nueva entrada en tu diario.

No hay nadie que te juzgue ni reglas: tan solo estás tú y el papel.

De ese modo, algo tan aparentemente inofensivo como tu propio diario, se convierte en un compañero fiel al que acudes para contarle «tus cosas», cómo fue el día, tus preocupaciones más profundas o hasta desarrollas en él esas fantasías tan libertinas como necesarias.

En cierto modo, cuando lees, de algún modo te sumerges en la mente del escritor; cuando escribes, plasmas en palabras tu mundo interior.

Si a veces todo nos parece caótico, cuando escribes tú creas tu propio mundo hecho a tu medida sin rendirle cuentas a nadie, en la forma de escuelas de magia, historias de amor, distopías o contando las hazañas de unos superhéroes o detectives sagaces.

La vida en sociedad nos impone límites necesarios, pero en la escritura, no hay límites.

Comienza el día liberando tu mente creativa escribiendo unas cuantas páginas al azar, de lo que sea, tan solo tus pensamientos erráticos mientras tu mente se despierta (Julia Cameron, autora de «El camino del escritor», libro que recomiendo, las llama «páginas matutinas»).

Termina la noche volviendo a esas páginas para destacar en palabras los momentos agradables, los nuevos problemas o acontecimientos que te parezcan importantes, y comprobarás que sientes cierta liberación al haber expresado de algún modo todo ese mundo mental de tu interior.

Recupera esa bella costumbre de redactar un correo (en papel o electrónico) para mantenerte en contacto con amigos que ahora viven lejos.

Escribe como terapia sobre cualquier asunto que te inquiete. También escribe para desarrollar esas ideas semilla que intuyes descubriendo que tan pronto como te obligas a ponerlas por escrito, lo difuso y evanescente se transforma en algo más concreto y factible, definido.

Conócete mejor a ti mismo, expulsando de tu interior con la forma de palabras todo aquello que se cruza por tu mente y tu vida.

Las razones para escribir son muchas, tan solo tienes que elegir de entre todas ellas aquellas que resuenen mejor en ti y, quizá, darle una oportunidad al resto.

Escribir es la mejor herramienta de desarrollo personal que conozco.

Del mismo modo que un paseo errático y sin dirección no sabemos a dónde nos conducirá, escribir, sin duda, te llevará a lugares inesperados y te puedo asegurar que sorprendentes.

Mientras tanto, ese par de golondrinas que cada tarde bailan frente al ventanal de mi salón, ignoran que su bello cortejo con esos rápidos movimientos, fugaces, únicos, irrepetibles, los he captado para siempre en estas palabras.

PD: Este artículo es uno de los capítulos de la guía gratuita "El Manifiesto del Autor Libre", disponible desde la sección de recursos y también disponible en Amazon.

Cómo escribir un libro y publicarlo en el siglo XXI

Acabo de publicar una guía (gratuita) desde Hub de Libros (Plataforma Editorial de Publicación Abierta) en donde describo cómo los modelos con los que se han estado realizando muchas actividades hasta hace unos años, han cambiado radicalmente gracias a la tecnología.

La escritura y la publicación, también, existiendo más oportunidades que nunca para todo el mundo que quiera escribir y publicar.

No me gustan los términos autopublicado ni autor independiente, en un momento en el que grandes y conocidos autores se pasan a este modelo de publicación que ofrece más ventajas que inconvenientes.

De ahí que me guste más el concepto de autor libre.

En esta guía puedes conocer los pasos que tienes que dar para publicar de forma libre, sus ventajas frente a modelos antiguos de publicación (perdirle permiso a editoriales de toda la vida) así como algunos consejos para escribir incluso en mitad de una vida muy ajetreada.

La puedes descargar desde https://www.hubdelibros.com/recursos o también obtenerla en Amazon (esta última opción tiene el precio mínimo ya que en Amazon no se puede indicar el precio de una obra como gratis directamente).

A continuación, incluyo el capítulo de introducción.

El Manifiesto del Autor Libre: Cómo escribir un libro y publicarlo en el siglo XXI. Capítulo de Introducción

¿Qué pasaría si te dijera que puedes escribir un libro (incluso en medio de una vida muy ocupada) y publicarlo para que lo lean en cualquier parte del mundo y además recibir ingresos a partir de él puntualmente cada mes? Esto es una realidad.

Hola, mi nombre es Rafael Gómez Blanes y soy el CEO de Hub de Libros — Plataforma Editorial de Publicación Abierta.

En las siguientes páginas te vamos a mostrar cómo puedes concebir un proyecto literario, ponerlo en marcha (incluso si tienes una vida muy ajetreada) y publicarlo, esto es, ponerlo a disposición de millones de lectores, tal y como he hecho yo.

Pero antes, te voy a hablar un poco sobre mí.

Mi actividad como autor comenzó en el año 2014. Lancé entonces un libro que habla acerca de mi actividad como ingeniero software («El Libro Negro del Programador»). Lo que comencé casi de forma anecdótica en aquel primer libro, constituye hoy día una de mis actividades profesionales.

(Algunos de mis libros disponibles en Amazon y Google Play)

En el momento de escribir esto, cuento con cinco libros de carácter técnico y dos novelas publicadas.

Cada día, y digo, cada día, y desde hace años, algunos de mis títulos se venden en alguna parte del mundo: España, Estados Unidos, México, Chile, Canadá, etc. y hasta Japón, a pesar de que solo uno de ellos está traducido al inglés por el momento.

Gracias a esa experiencia como autor, hemos creado Hub de Libros para ayudar a muchos otros a recorrer el mismo camino que yo he transitado estos años.

Sostengo que «publicar» es un Derecho, al igual que Escribir, como diría Julia Cameron.

Por si aún no te habías dado cuenta, la publicación se ha «democratizado».

En estos años, un factor importante ha venido a modificar la forma en la que los lectores leen, consumen y adquieren libros, y también el modo en que los autores escriben y publican, y este factor no es otro que la tecnología. Esto es: «las editoriales necesitan de los autores, pero éstos ya no necesitan de aquellas».

Este cambio no es ni bueno ni malo, tan solo ciertos modelos de negocio evolucionan, surgen nuevos y otros mueren.

Pero para los autores, esto sí que es una gran noticia.

Lejos quedan los tiempos en los que necesitábamos el permiso de una compañía (que llamaremos «editorial tradicional») para indicarnos y certificar si nuestro trabajo es bueno o no. ¿Para qué están los lectores, si no?

La única medida del éxito de tu obra es la opinión de los lectores. Punto. Esto es una declaración de principios en Hub de Libros.

Las «editoriales tradicionales» tienen un gran papel en la industria del libro y la cultura, qué duda cabe, pero ya no es una exigencia el tener que pasar por los filtros comerciales o de otro tipo para que tu obra llegue al público más amplio posible.

La tecnología ha permitido un cambio de modelo en esta actividad, del mismo modo que ha irrumpido en todos los ámbitos de la economía, y, ¿sabes qué? Lo va a seguir haciendo queramos o no.

Como escritores, aprovechémoslo.

Nos guste o no, la tecnología ha venido para quedarse y transformar totalmente todas las áreas económicas de nuestra vida en sociedad.

La cultura (y la publicación), también.

Algunos datos:

● Los autores más vendidos en la mayor librería del mundo (Amazon) son autopublicados. Reconozco que no me gusta el término «autopublicado», pero de ello hablaremos en las siguientes páginas.

● El libro electrónico sigue su imparable crecimiento (podemos leer desde eReaders, el teléfono móvil, una tablet, etc., desde cualquier dispositivo electrónico), no solo en papel. Si lo piensas, es la consecuencia natural y lógica.

● En el modo de escribir y de encontrar «betareaders» también tenemos más posibilidades que nunca (con servicios como Leanpub o Wattpad y, claro está, Hub de Libros).

Yo, sin ir más lejos, como lector, y tan solo revisando lo que he leído en lo que va de año, puedo decir que más de la mitad han sido autores que no tienen detrás ningún sello editorial (ni grande ni pequeño), superventas como Raimón Samsó, Mario Escobar y Fernando Gamboa, por poner unos ejemplos. En mi opinión, muy buenos escritores.

En esta breve guía te voy a introducir en el mundo de la publicación libre para que sepas qué pasos tienes que dar para que tu libro pueda ser leído en gran parte del mundo sin que una compañía tradicional de «modelo antiguo» adquiera tus derechos de autor (tu trabajo) a precio de saldo.

No me gustan los términos «indies» ni «autopublicación», utilizados a menudo de forma peyorativa por ese sector industrial cuyo modelo de negocio (si no cambia en los próximos años) se va a ver muy amenazado, de modo que en el contexto de este trabajo, vamos a llamar a los autores que controlan todo lo relacionado con su trabajo como «autores libres».

Me gusta considerarme un «autor libre»: yo controlo todo el proceso de escritura de mis libros así como de su publicación. Y lo hago con una calidad que, en mi opinión, es extraordinaria (algunos de los pasos de generación de un libro no los hago yo, sino que delego en gente más experta).

Y de todo eso es precisamente de lo que te quiero hablar en esta guía, porque, además, para eso he fundado Hub de Libros.

Yo me considero, como digo, un «autor libre» con la suerte de que mis obras se venden cada día y ayudan a muchos lectores. Pero como yo, hay miles más que han dado el paso y cientos de miles más que aún no saben cómo empezar. De ahí esta guía gratuita editada desde Hub de Libros.

Pienso que debemos dedicar parte de nuestro tiempo a ayudar a los demás y que esto lo podemos hacer de muy diversas formas. Es más, cuanto más sepamos ayudar a otros, en el sentido que sea, seguramente mejor nos irán las cosas y hasta puede que mejor nos sintamos con nosotros mismos. Por lo menos yo pienso así.

Para ello, hay muchas formas, tantas como se te ocurran: colaborando, escribiendo posts en tu propio blog, participando en proyectos colaborativos y desinteresados en GitHub, realizando mentorías o incluso escribiendo libros cuando crees que tienes algo que aportar a tu comunidad.

También pienso lo siguiente: Si algo me ha funcionado a mí, ¿por qué no contarlo para que otros se beneficien?

Por esa razón fundé Hub de Libros, para que todos esos autores que escriben tengan fácil acceso al mundo de la publicación y que puedan difundir su trabajo por casi todo el planeta y no tengan los obstáculos que yo tuve (y que superé dolorosamente con mucha prueba y error) desde el año 2012, porque sé que muchos se quedan por el camino provocando que, quizá, información o conocimiento muy valisosos queden olvidados en el fondo de un cajón, o porque creen aún que para contar algo y empaquetarlo en un formato libro se necesita del permiso de una editorial de toda la vida (como diría Julia Cameron), en el siglo de la tecnología y de modelos disruptivos como Uber, Etsy, Airbnb y muchos otros.

Del mismo modo, describir a nivel técnico cómo he enfocado un proyecto software tan ambicioso como complejo como Hub de Libros, me ha llevado a trabajar en los últimos meses en El Arte del Emprendedor Digital, mi nuevo libro con el que espero ayudar y animar a toda esa comunidad relacionada con la tecnología y con ganas e inquietud de emprender o de lanzar nuevos proyectos.

Parece ser que vivimos con una dinámica en la que todo el mundo está demasiado ocupado, desde que nos levantamos hasta que nos acostamos.

Pero yo me pregunto lo siguiente: ¿Ocupados en qué?

Para mí la primera medida del éxito consiste en permanecer ocupados, al menos la mayor parte del tiempo, en aquello que nos interesa y en la dirección de nuestras metas a largo plazo y, por supuesto, mantener una vida equilibrada en todas sus áreas.

Sin embargo, he descubierto todos estos años, cruzándome con CEOs, CTOs, gerentes y muchos otros desarrolladores, que se confunde demasiado el estar ocupado con trabajar productivamente y, de ahí, a un paso tenemos una vida llena de estrés y sin saber cómo mejorar.

Esto es, no se trata de trabajar más horas sino de trabajar mejor.

Desarrollar un proyecto como Hub de Libros (y otros anteriores junto con aquellos en los que participo actualmente), consiste también en cierta forma de enfocar el trabajo y de hasta mantener ciertas habilidades de desarrollo personal.

Por esa razón, en El Arte del Emprendedor Digital no solo describo los aspectos técnicos más relevantes de algunos de mis proyectos en marcha, sino también de todas esas técnicas y habilidades que a mí me han servido para poder concentrarme en un trabajo tantas horas y durante muchos meses compatibilizándolo con el resto de mis responsabilidades: desde kaizen hasta las microtareas, la importancia de conseguir concentración, fluir y hasta cómo gestionar las dudas, y un largo etcétera.

Inevitablemente, este nuevo libro tiene, por tanto, un carácter algo personal e intimista, que no me importa compartir puesto que pienso que su contenido puede ser de mucha utilidad a tantas personas que quieren avanzar en sus proyectos o que quieren emprender con la mayor probabilidad de éxito, y del mismo modo, me he tomado la libertad de describir en el mismo libro aspectos técnicos (muy técnicos, de hecho) junto con herramientas de desarrollo personal, porque, en definitiva, por muy buen técnico que se sea, por muy buena la idea que quieres implementar, si no dominas estas últimas estrategias de carácter personal, el camino será mucho más difícil, si es que no se abandona nada más dar los primeros pasos.

Yo abandoné en algunas ocasiones, fracasé en otras, pero también he tenido éxito en muchos otros proyectos, aunque ahora comprendo que lo primero no es más que una fuente de aprendizaje para seguir avanzando.

El Arte del Emprendedor Digital me lo prologa nada más y nada menos que José Murillo, compañero durante algunos años en mi primera etapa laboral y quien después trabajó para Microsoft durante más de quince y que desde hace dos años es el CEO de su propia compañía (Smart IoT Labs).

No sé si el movimiento startup y todo lo relacionado con el emprendimiento (tan de moda últimamente) serán o no el corazón de la nueva economía a la que nos dirigimos, pero de lo que sí estoy seguro es de que aquellos que trabajamos con la tecnología lo tenemos más sencillo para lanzar proyectos que aquellos que trabajan en otros sectores.

En El Arte del Emprendedor Digital describo cómo he afrontado Hub de Libros y cómo se plantea la evolución de un proyecto con metodología lean, junto con los elementos más importantes y paradigmáticos que debe cumplir un proyecto software que va a cambiar continuamente y que desde su comienzo, ni siquiera tenemos claro cómo será esa evolución, entre otros muchos temas.

Confío en que este nuevo trabajo que he realizado con tanta ilusión (y esfuerzo), y que es de los primeros títulos editados por mi propia plataforma editorial, sea de utilidad tanto o más como mis anteriores libros.

Recientemente he publicado en un único ebook los tres libros técnicos que he escrito hasta el momento, dándole el nombre de La Trilogía del Programador Profesional.

En cierto modo, tanto El Libro Negro del Programador, El Libro Práctico del Programador Ágil y The Coder Habits, forman una unidad en su conjunto aportando tanto esa meta visión acerca de nuestra profesión como desarrolladores de software, pasando por las buenas prácticas técnicas y hábitos como programadores profesionales.

Es difícil encontrar gran parte de ese conocimiento, menos aún en castellano, extraído de mi propia experiencia, reunido en un único trabajo.

Me ha parecido práctico reunir los tres libros en uno solo para así facilitar su lectura y adquisición.

He añadido, además, una introducción a este nuevo pack después de lanzar uno de mis proyectos más ambiciosos.

Desde hace unas semanas ya lancé oficialmente un proyecto en el que he trabajado con mucha ilusión y que en algunos aspectos ha sido todo un reto técnico. Toca aquí más hablar de estas cuestiones técnicas que del proyecto en sí. Pero antes, un poco de historia personal...

En 2014 publiqué mi primer libro (El Libro Negro del Programador) y desde entonces no he parado de tener siempre un proyecto literario en marcha, de tipo técnico, novela o relatos cortos. ¿El resultado? Seis libros, cuatro relacionados con el desarrollo de software profesional y dos novelas (éstas bajo el seudónimo de G. Blanes), perto también conocer con detalle todo lo relacionado con la publicación independiente (o indie) y hasta considerar mi trabajo como escritor como un área más de mi profesión.

Para los que aún no lo sepan, ya no hace falta que una editorial "de toda la vida" te elija para que puedas publicar tu libro, y mucho menos venderlo en cualquier parte del mundo. Internet ha permitido explorar miles de nuevos modelos de negocio y el mundo editorial no puede quedarse al margen de ello. Esto es, en cierto modo, se ha democratizado la posibilidad de publicar (ya no se necesita el permiso de nadie para hacerlo).

Me sorprende (y digo esto a modo de reflexión personal), esa extraña áurea que rodea la imagen de un "escritor", y que algunos se sientan bendecidos y pontificados por una mano mágica que los diferencia del resto de los mortales, algo que no ocurre en otras profesiones. Es cierto que siempre habrá buenos pintores y malos, buenos programadores y peores, y por lo tanto, también excelentes escritores que ganan El Nobel y muchos otros aficionados. Sin embargo, hay espacio para todo el mundo que tenga inquietudes creativas, en cualquier área. No en vano, cuántos artistas consagrados hoy en día fueron rechazados en su época, como pareciendo que hace falta morir para que valoren tu trabajo...

Autores cuyas obras nunca habrían visto la luz por no encajar quizá en los intereses comerciales o de nicho de las editoriales tradicionales, pueden ahora dar a conocer su trabajo gracias a la tecnología. Otros, ya consagrados, se pasan a la publicación independiente porque genera más libertad y mayores royalties, qué duda cabe.

No hablo solo de autores de "literatura", sino de cualquier tipo y  género: de desarrollo personal, técnicos, etc. Es más, me atrevo a decir que en nuestra profesión, se echa en falta más y mejor literatura técnica en castellano, quizá porque muchos desarrolladores no exploran ese camino.

No me gusta la expresión publicación independiente, que es tanto como decir, si existiera alguna similitud con otras actividades, escultor independiente, pintor independiente o hasta programador independiente. Suena raro, ¿verdad? ¿Acaso hay que etiquetar de algún modo el hecho de que tú seas el responsable de tu publicación a diferencia de que exista cierta entidad que te "da permiso" para dar a conocer tu trabajo?

Si bien hace diez años quien no conseguía que le publicaran terminaba "autopublicándose", y el término "independiente" se asociaba más a aquellos materiales que no encajaban en las tendencias más clásicas y comerciales de las editoriales, hoy día todo esto ha cambiado radicalmente.

Es más, hoy día la tendencia comienza a ser ésta, incluso autores que vienen "del otro lado", como Matilde Asensi y Raimón Samsó, pasan parte o todo su trabajo a este modelo. ¿Por qué? Por la misma razón por la que Airbnb le permite a los dueños de apartamentos rentabilizarlos mejor o aquel proveedor de suministros decide abrir una tienda en Amazon y llegar a más clientes: porque la tecnología lo permite a un coste mínimo y de escala y porque así tienes el control total de tu activo (sean productos o servicios).

¿Y qué pasa con la labor insustituible que es necesaria para generar un libro de calidad? Estoy hablando de revisar, corregir, diseñar la portada, maquetar el contenido, la promoción, el markenting, etc. Todo eso, qué duda cabe, un trabajo duro que hacen las editoriales, ahora se puede subcontratar, si quieres, a quien quieras y cuando quieras. De esto hablaremos un poco más adelante.

Esto es, publicar de forma independiente consiste básicamente en que tú haces tu trabajo de escribir, pero también te encargas de obtener la portada, maquetar tu libro, revisarlo hasta la saciedad y publicarlo directamente en plataformas como Amazon, Google Play, Kobo, etc. O bien le encargas a otros profesionales ese trabajo por un precio razonable. En cualquier caso, tú tienes la libertad y el control (y los derechos de autor) sobre tu obra, y que sean los lectores únicamente los que tengan la capacidad de juzgarla.

Porque esto es lo que yo pienso y creo: Igual que leer es un Derecho, opino que Escribir también lo es (como dirían Julia Cameron en su libro El Camino del Escritor o Natalie Goldberg), de modo que nadie te puede impedir hacerlo, tanto si consigues rentabilizarlo como si no, de ahí que haya creado Hub de Libros como Plataforma Editorial de Publicación Abierta.

Leí recientemente que más de un ochenta por cierto de la población estadounidense ha deseado en algún momento de su vida escribir un libro. La mayoría no lo hace. 

La diferencia es que ahora es posible a menos que te lo propongas.

¿Y qué pasa con la calidad? Sí, así también cualquiera puede publicar un bodrio (que no va a ser leido por casi nadie, por cierto) o bien una auténtica joya. Pero también puedes mejorar tu texto en cualquier momento (como hago yo cada vez regularmente sobre mis libros), cambiarles el precio, etc.

En cualquier caso, la última palabra la tienen los lectores, solo ellos van a indicar la valoración sobre tu trabajo. 

Pues bien, detrás de toda esta historia y de cierta inquietud personal al afirmar que Escribir es un Derecho que tenemos, está Hub de Libros y la Plataforma Editorial de Publicación Abierta. Es un site donde los lectores pueden encontrar nuevos contenidos pero, sobre todo, nuevos autores y los escritores pueden crearse su propio perfil y publicitar sus trabajos. 

He creado Hub de Libros para que los autores que quieran publicar, lo puedan hacer sin los problemas técnicos que yo tuve en su momento y que fui superando con mucho esfuerzo, prueba y error.

También creo en la economía gig, en la que cada vez más y más profesionales pueden ofrecer sus servicios a cualquier cliente de cualquier parte del mundo, como se hace a través de Fiverr y muchos otros portales. Para ello Hub de Libros dispone de una serie de gigs o servicios que cualquiera puede contratar relacionados con todo lo necesario en el proceso de creación de un libro.

Hub de Libros también es un reto técnico, y me propongo hablar de todas las estrategias que he empleado en él y que permiten que sea una plataforma diseñada para crecer y ser evolucionada fácilmente mediante Mantra Framework, otro proyecto propio en NodeJS en el que comencé a trabajar hace ya dos años en base a mi experiencia de haber lanzado proyectos muy escalables (que soportan un gran número de usuarios y manejan un volumen de datos muy alto), para lo cual hacen falta estrategias de diseño y arquitectura que nada tienen que ver con una aplicación de tamaño pequeño o mediano.

Es cierto que existen otros frameworks muy maduros y con una buena acogida, como NestJS, pero ciertas consideraciones técnicas a largo plazo me llevaron a concretar el desarrollo de Hub de Libros en un framework propio fácilmente evolucionable. En los siguientes puntos entendrás por qué.

Estas son varias de las claves técnicas sobre las que se asienta a nivel de software Hub de Libros: