Roba como un artista: una guía honesta para programadores

Hay un libro que llevamos años prestándole a colegas junior cuando preguntan “cómo se me ocurren las cosas”. Se llama Steal Like an Artist — Roba como un artista — y lo escribió Austin Kleon en 2012. Son 160 páginas ilustradas a mano, formato de zine, y básicamente es la refutación más honesta que conocemos del mito de la inspiración espontánea.

Kleon arranca con una afirmación que todo programador con diez años de carrera reconoce inmediatamente: nada es original. No como provocación, no como posmodernismo de sobremesa — como hecho operativo. Todo lo que escribes ya fue escrito. Todo lo que diseñas ya fue diseñado. El trabajo no es inventar, es elegir bien de dónde robas y qué haces después con lo robado.

La frase que nadie dijo

La cita más famosa del libro no es de Kleon. Ni siquiera es la que Kleon elige como epígrafe. Es una que viene rebotando en tu cabeza desde algún keynote: “good artists copy, great artists steal”, atribuida a Picasso. Steve Jobs la popularizó en el documental Triumph of the Nerds en 1996 para explicar el Macintosh. Desde entonces se repite en posts de LinkedIn cada lunes.

Picasso nunca la dijo. O al menos no existe registro documental de que lo hiciera. Quote Investigator rastreó su genealogía hasta W.H. Davenport Adams en 1892 y, sobre todo, hasta T.S. Eliot en 1920 (The Sacred Wood):

Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different.

Eliot la escribió sobre poesía. Jobs la recordó atribuida a Picasso y la usó para vender computadoras. Kleon la hereda ya deformada y la toma como punto de partida. El propio origen de la frase es un ejemplo de la tesis que defiende. Eso ya dice más que el libro entero.

Nothing is original — la cita que sí es exacta

La verdadera brújula del Capítulo 1 de Kleon es otra: Jim Jarmusch, en un ensayo breve para MovieMaker Magazine en 2004, escribió algo que Kleon reproduce casi completo:

Nothing is original. Steal from anywhere that resonates with inspiration or fuels your imagination. Devour old films, new films, music, books, paintings, photographs, poems, dreams, random conversations, architecture, bridges, street signs, trees, clouds, bodies of water, light and shadows. Select only things to steal from that speak directly to your soul. If you do this, your work (and theft) will be authentic. Authenticity is invaluable; originality is non-existent. And don’t bother concealing your thievery — celebrate it if you feel like it.

Esa es la premisa del libro en 12 líneas. Lo que Kleon hace en las 160 páginas siguientes es aplicarla a 10 ideas concretas sobre trabajo creativo. La más importante de todas, la que un programador reconocerá casi sin esfuerzo: “You are a mashup of what you choose to let into your life. You are the sum of your influences.”

Qué tiene que ver esto con escribir código

Todo. Programar es una disciplina que pretende ser ingeniería pero opera como artesanía, y toda artesanía se transmite por copia.

Los ejemplos son ridículamente abundantes:

• React tomó ideas de Elm (arquitectura unidireccional), Elm las tomó de Haskell, Haskell heredó de ML, ML heredó de LISP. Nadie lo oculta. Está documentado en las RFCs originales.
• Git existe porque Linus leyó el código de BitKeeper, decidió que podía hacerlo mejor, y lo hizo distinto. El manifiesto del primer release literalmente decía “the stupid content tracker” — Kleon aprobaría el humor.
• Los patrones de diseño del “Gang of Four” (1994) declaran abiertamente que son una adaptación del libro A Pattern Language de Christopher Alexander (1977), que hablaba de arquitectura de edificios. Stanford-Berkeley-UNIX-Smalltalk heredaron la idea de que “los problemas recurrentes merecen nombre” de un arquitecto que diseñaba plazas en California.
• La regla del Boy Scout que citamos como principio de ingeniería (“dejar el código más limpio de como lo encontraste”) la formuló Bob Martin en Clean Code (2008) tomándola literalmente del manual de los scouts, que a su vez la adaptaba de una carta de Baden-Powell de 1907.
• Stack Overflow es un edificio de 50 millones de respuestas construido sobre el principio de que la mayoría del código que escribes lo escribió alguien antes. Lo único nuevo es tu combinación.

Si aceptas esto honestamente, lo que se derrumba es una idea profundamente narcisista sobre cómo trabaja un programador bueno. Nadie escribe desde cero. Todos somos nodo intermedio en una red de préstamos. La única pregunta útil es a quiénes leemos bien.

Las 10 ideas de Kleon, aplicadas al lab

El libro está estructurado como una lista. Para economía de espacio y honestidad intelectual, esta es la traducción de cada capítulo al oficio de escribir software:

1. Steal like an artist. Lee código. Mucho. El mejor código que vas a leer no es el tuyo — es el de las librerías que usas. Dedica una tarde al mes a leer el source de algo que te ayude todos los días.
2. Don’t wait until you know who you are to get started. Ningún senior empezó sabiendo. Todos pasaron por una fase de imitación vergonzosa. Es requisito, no fase intermedia.
3. Write the book you want to read. Construye la herramienta que te falta. Casi todo OSS útil empezó porque alguien tenía un problema y no encontró solución digna. Redis existe porque Salvatore Sanfilippo estaba cansado de cache malo.
4. Use your hands. Abre un editor y escribe. Piensa menos, tipea más. Los diagramas infinitos antes del primer commit casi siempre son procrastinación disfrazada.
5. Side projects and hobbies are important. El lateral casi siempre alimenta lo principal. Git nació mientras Linus trabajaba en Linux, no en lugar de. DHH inventó Rails haciendo Basecamp. Darius Kazemi publica bots mientras mantiene empleo estable. El lateral no roba tiempo al trabajo — le da combustible.
6. The secret: do good work and share it with people. Dos mitades. Lo primero, obvio. Lo segundo, incómodo. Escribe. Publica. Habla en un meetup chico. El código que nadie vio no existe en la economía del oficio.
7. Geography is no longer our master. Internet hizo que la ciudad donde vives dejara de importar para el trabajo. Este sitio está en Morelia, dos de nuestros clientes más grandes no saben dónde queda Michoacán en el mapa. Kleon escribió esto en 2012 y ahora es tautología.
8. Be nice. (The world is a small town.) El ecosistema de software es absurdamente pequeño. El junior al que hoy le respondes el DM es el CTO que te contrata en seis años. No es estrategia — es aritmética.
9. Be boring. (It’s the only way to get work done.) Trabajo profundo requiere rutina aburrida. Kleon: “Be regular and orderly in your life, so that you may be violent and original in your work.” (La frase original es de Flaubert, claro.) Si tu estética es la de desarrollador rockstar, vas a entregar poco.
10. Creativity is subtraction. Restricción crea — no limita. Esto lo hemos escrito antes en Menos código, mejor criterio. Kleon le da la forma aforística: “It’s in limiting yourself that you actually get things done.”

Lo que el libro omite (y deberías completar)

Kleon escribe un manifiesto, no un tratado. Es honesto al respecto: los headlines son casi todo el contenido. Si quieres profundidad, sigue el hilo:

• Jonathan Lethem, The Ecstasy of Influence (Harper’s, 2007). Un ensayo de 8,000 palabras compuesto íntegramente de frases robadas a otros autores, con la lista de atribuciones al final. Lethem es la pieza que le falta a Kleon para que el argumento pese.
• Lewis Hyde, The Gift (1983). La tesis profunda: la creatividad es un don que se transmite, no una mercancía que se acumula. Explica por qué el open source funciona y por qué los equipos que solo optimizan outputs se atrofian.
• Richard Hamming, You and Your Research (1986). La charla que todo ingeniero serio debería escuchar una vez al año. Coincide con Kleon sin haberlo leído.

Cómo lo usamos en el lab

Tres reglas que adoptamos a partir de este libro y que seguimos escribiendo:

Archivo de préstamos. Un documento simple por proyecto donde anotamos de dónde sacamos qué idea. No para citarlo en el README — para nosotros. Evita auto-engaño cuando revisitamos decisiones seis meses después y recordamos mal.

Leer una pieza de código por semana. Puede ser la implementación de un hook de React, el source de ripgrep, el middleware de autenticación de una gema de Rails. No para copiar — para ver cómo piensa alguien más. El músculo se atrofia si solo lees tu propio repo.

Publicar sin esperar a tener algo “digno”. Este blog es un ejemplo. Ningún post que hemos publicado aquí nos parece terminado. Todos nos parecen honestos.

Veredicto

Si te dedicas a escribir software y nunca has leído este libro, léelo en una tarde. Son 160 páginas con ilustraciones, no un compromiso. Si ya lo leíste, relee el capítulo 10 cada seis meses — la idea de que la creatividad es restricción es la única que realmente necesitas recordar.

Si te resulta demasiado motivacional, quédate con Lethem. Si te parece demasiado académico Lethem, quédate con Jarmusch. Si te parece demasiado cinematográfico Jarmusch, vuelve a Kleon. El trío cubre el mismo territorio desde tres ángulos y, coherentemente con su tesis, se robaron el argumento los unos a los otros.

TL;DR — Kleon escribió en 2012 el manifiesto más accesible sobre una idea que es vieja: todo trabajo creativo es remezcla honesta de influencias. Aplica a programar porque programar es eso. Leer código ajeno no es atajo, es el trabajo. Lo único que el oficio te pide es elegir con cuidado de quién robas y después hacer algo que los demás también puedan robar.