Hace poco me preguntaron: ¿Qué profesión habrías elegido si no pudieses ser desarrollador? La respuesta, meditada con años de antelación, sonó como un impulso: Escritor.
Desde que era un adolescente timorato e introvertido, la literatura ha estado ahí, compañera de viaje. Al principio, lector ávido de novelas de ciencia ficción. Después, a sugerencia de un profesor del instituto, algunas joyas de las letras universales. Por último, creador de pequeñas obras, ensayos, poemas.
Como todo autodidacta, al principio crees que tus trabajos son de calidad abrumadora, te asombra la facilidad con la que puedes avanzar e imaginas que tienes un talento natural para el oficio - el efecto Dunning-Kruger. Las primeros críticas y un par de manuales de iniciación te ponen los pies en el suelo. Revisas tus frases, buscando los errores frecuentes que señala el libro de estilo, y están ahí, burlándose de ti. Miras en los párrafos y la misma palabra repetida diez veces te golpea. Páginas que se suceden, sin coherencia interna, sin estructura. Llegan las dudas. Perseveras. Aprendes más. Y, de repente, te das cuenta de que la clave no está en plasmar las ideas sobre el papel en su forma perfecta y final, sino en la edición posterior.
Cuando desarrollo y cuando escribo noto como se activan partes similares de mi pensamiento. Existe un paralelismo entre ambas profesiones, puntos comunes, sin llegar a ser idénticas. Como dice Robert C. Martin - nada sospechoso de ser mal desarrollador - en Clean Code:
Writing software is like any other kind of writing. When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.
When I write functions, they come out long and complicated. They have lots of indenting and nested loops. They have long argument lists. The names are arbitrary, and there is duplicated code. But I also have a suite of unit tests that cover every one of those clumsy lines of code.
So then I massage and refine that code, splitting out functions, changing names, eliminating duplication. I shrink the methods and reorder them. Sometimes I break out whole classes, all the while keeping the tests passing.
In the end, I wind up with functions that follow the rules I’ve laid down in this chapter. I don’t write them that way to start. I don’t think anyone could.
En este fragmento aparece, no obstante, una de las diferencias más importantes que debilitan la analogía escritura - desarrollo. El código fuente de un proyecto es como un libro que nunca llega a publicarse del todo o sujeto a cambios después de su publicación. Los cambios pueden ser insignificantes (el color de la chaqueta del malo en el capítulo siete) o devastadores (queremos que el protagonista muera en el capítulo dos).