Hace muchos años leí un libro que me impactó: Como una novela, del francés Daniel Pennac. No sólo me gustó porque estimulara a leer como una actividad esencial en la vida, sino porque también me reveló la importancia de estar en el otro lado: el de quien lee, pero también escribe.
Desde hace más años de los que recuerdo, me ha interesado mucho la escritura creativa. Incluso realicé un curso presencial al borde del siglo pasado (literalmente, creo que fue en 1998 o 1999) con una escritora sevillana relevante. En aquella época recuerdo que estaba enfrascado totalmente en interfaces de usuario con Visual C++ (¡qué tiempos!).
Y, desde entonces, he escrito con mayor o menor regularidad no sólo mi proyecto de El Libro Negro del Programador, publicado hace tres años, sino también relatos cortos, intentos de novelas que no terminé, otras cosas que sí terminé pero que no me parecieron de suficiente calidad como para darlas a conocer, posts en El Blog Alternativo, etc. Hasta el año pasado, cuando terminé y publiqué lo que considero mi primera novela publicable.
¿Y qué hace uno hablando sobre novelas en un blog de software, más relacionado con mi actividad profesional del día a día?
Porque, aunque no lo parezca, hay muchas similitudes entre escribir software y escribir una novela, entre comenzar un proyecto de software y asumir un proyecto literario con una metodología.
Si quieres saber todas las cosas que he descubierto al respecto en estos años, sigue leyendo.
Este primer proyecto literario es una novela con un argumento un poco romanticón, pero que tiene una trama de desarrollo personal importante, así como su propia intriga y ritmo. Se titula Patricia: una nueva relación que lo cambiará todo. Puedes ver más al respecto en la web literaria en la que trabajaré en todo lo relacionado con mi lado novelesco ;-) (www.gblanes.com).
Ejem… hay autores a los que admiro mucho por su actividad profesional, como Raimón Samsó, que además tiene algunas novelas de corte romántico (que, por cierto, es el género que mejor funciona comercialmente…).
Entonces, ¿qué relación hay entre un proyecto de software y un proyecto literario?
Estas son las similitudes que encontré y que, sin ninguna duda, me ayudaron a completar un proyecto de cerca de cuatrocientas páginas, realizado a base de microtareas durante unos ocho meses:
- En primer lugar, un libro no se escribe, se construye. Es un trabajo con un proceso y, como siempre digo, el proceso es más importante que la tecnología que se vaya a usar (o el texto que se vaya a escribir). Cuando asumimos que algo se debe construir, nos damos cuenta de que tiene muchas partes independientes, que se pueden realizar a ritmos diferentes.
- Al igual que un proyecto de software con una metodología basada en sprints y entregas, que necesita planificación (porque esto lo tienes claro, ¿no?), un proyecto literario también se planifica. Lo siento si acabo de poner en duda tu idea del escritor sentado en una buhardilla, mirando por la ventana un paisaje bucólico y esperando la inspiración para plasmarla en una hoja en blanco. De ningún modo: como dice Joanna Penn, escritora independiente a la que sigo, “un libro es un 5 % inspiración y un 95 % trabajo duro y planificación”. Créeme, es así.
- Igual que cuando escribimos código lo revisamos y aplicamos estrategias de refactoring, ocurre lo mismo con un texto, capítulo o sección: una vez escrito, se revisa para buscar typos, errores ortográficos, tipográficos o gramaticales, mejorar una frase o eliminar algo para rehacerlo. Se dedica más tiempo a revisar y corregir que a escribir. Esto siempre sorprende a quienes no conocen bien el trabajo de un escritor.
- Se distingue entre avanzar y mejorar. Del mismo modo que nos concentramos para cerrar una funcionalidad de software (aunque después se refactorice y mejore), en una novela ocurre lo mismo: hay una fase de escritura, que algunos autores aconsejan que sea rápida para terminar cuanto antes la sección o el capítulo, y otra fase muy distinta de revisión. Puesto que mucha gente comienza a escribir pero la mayoría no termina el trabajo, hay quien sugiere terminar un borrador lo antes posible, aunque tenga muchos fallos e incongruencias que después se pueden corregir. Aunque haga falta revisarlo, al menos tienes una primera versión y eso te anima mucho. Tiene sentido.
- Como digo, los capítulos se revisan hasta la saciedad, y es sorprendente cómo, después de varias vueltas, uno sigue encontrando detalles que mejorar (¿a que esto resuena en nuestras mentes de programadores?). Porque, al igual que no hay ningún proyecto de software perfecto, tampoco hay un libro perfecto, y nunca lo podrá haber: el ideal de perfección es demasiado subjetivo. Aunque sí hay otros elementos que se pueden medir (complejidad ciclomática frente a ritmo literario, tamaño de métodos frente a subtramas, etc.).
- ¿Funciona el software? Quiero decir, respaldamos el código con pruebas unitarias, de integración, etc. ¿Y un libro? Pues igual: se plantean preguntas que el libro debe responder con éxito. ¿Está bien descrito este personaje? ¿Es demasiado pesada esa subtrama? ¿Es coherente a lo largo del libro la historia familiar de los protagonistas? ¿Se usan los tiempos verbales correctamente y de forma coherente? Es decir: pruebas, pruebas y pruebas.
- Un proyecto de software se despliega, se publica, al igual que un libro. Para ello hay que compilar el texto y generarlo en formato PDF, EPUB o MOBI junto con sus portadas, contraportadas, etc. Nota: en la herramienta Scrivener se incluye el concepto de “compilar” el texto, que no es más que generar el libro en el formato configurado y parametrizado. Dicho así parece sencillo, pero tiene un trabajo importante.
- Y todo ello debe estar bajo el marco o paraguas de una metodología. Para el libro (al igual que hice con El Libro Negro del Programador), creé mi propia metodología, adaptada al tiempo que tenía disponible para escribir: división en tareas pequeñas, sesiones de una hora, definición de cada sección del texto (antes de empezar a escribir, hice un guion con unas ochenta secciones), etc.
- Pruebas de validación: si no, ¿para qué sirven los beta readers? Le di el manuscrito a mi pareja y a una amiga cuando ya lo di por terminado y, por supuesto, me indicaron bastantes mejoras.
- Te documentas leyendo un montón de libros y blogs, como suelo hacer cada vez que me interesa una tecnología en particular.
- Y hace falta mucho, muchísimo compromiso para alcanzar cada semana los hitos que uno mismo se plantea (y que no siempre consigue).
Cuando menos, interesante.
Por cierto, si planeas escribir un libro, no utilices Word, por favor; merece la pena gastarse unos eurillos en una herramienta como Scrivener.