Hackers y Pintores

Mayo de 2003

(Este ensayo se deriva de una conferencia invitada en Harvard, que incorporó una charla anterior en Northeastern.)

Cuando terminé la escuela de posgrado en ciencias de la computación, fui a la escuela de arte para estudiar pintura. A mucha gente le sorprendió que alguien interesado en las computadoras también estuviera interesado en la pintura. Parecían pensar que el hacking y la pintura eran tipos de trabajo muy diferentes: que el hacking era frío, preciso y metódico, y que la pintura era la expresión frenética de algún impulso primordial.

Ambas imágenes son erróneas. El hacking y la pintura tienen mucho en común. De hecho, de todos los diferentes tipos de personas que he conocido, los hackers y los pintores son los más parecidos.

Lo que los hackers y los pintores tienen en común es que ambos son creadores. Junto con los compositores, arquitectos y escritores, lo que los hackers y los pintores intentan hacer es crear cosas buenas. No están investigando per se, aunque si en el curso de intentar crear cosas buenas descubren alguna nueva técnica, tanto mejor.

Nunca me ha gustado el término "ciencias de la computación". La razón principal por la que no me gusta es que no existe tal cosa. Las ciencias de la computación son una bolsa de trucos de áreas tenuemente relacionadas, unidas por un accidente histórico, como Yugoslavia. Por un lado, tienes a personas que son realmente matemáticas, pero que llaman "ciencias de la computación" a lo que están haciendo para poder obtener subvenciones de DARPA. En el medio, tienes personas que trabajan en algo así como la historia natural de las computadoras: estudiando el comportamiento de los algoritmos para enrutar datos a través de redes, por ejemplo. Y luego, en el otro extremo, tienes a los hackers, que intentan escribir software interesante, y para quienes las computadoras son solo un medio de expresión, como el hormigón lo es para los arquitectos o la pintura para los pintores. Es como si matemáticos, físicos y arquitectos tuvieran que estar todos en el mismo departamento.

A veces, lo que hacen los hackers se llama "ingeniería de software", pero este término es igual de engañoso. Los buenos diseñadores de software no son más ingenieros que los arquitectos. La frontera entre arquitectura e ingeniería no está claramente definida, pero está ahí. Cae entre el qué y el cómo: los arquitectos deciden qué hacer y los ingenieros descubren cómo hacerlo.

El qué y el cómo no deben mantenerse demasiado separados. Te estás buscando problemas si intentas decidir qué hacer sin entender cómo hacerlo. Pero el hacking ciertamente puede ser más que solo decidir cómo implementar alguna especificación. En su mejor momento, es crear la especificación, aunque resulta que la mejor manera de hacerlo es implementándola.

Quizás algún día las "ciencias de la computación", como Yugoslavia, se descompongan en sus partes componentes. Eso podría ser algo bueno. Especialmente si significara la independencia para mi tierra natal, el hacking.

Agrupar todos estos diferentes tipos de trabajo en un solo departamento puede ser conveniente administrativamente, pero es confuso intelectualmente. Esa es la otra razón por la que no me gusta el nombre "ciencias de la computación". Podría decirse que las personas en el medio están haciendo algo parecido a una ciencia experimental. Pero las personas en ambos extremos, los hackers y los matemáticos, en realidad no están haciendo ciencia.

Los matemáticos no parecen molestarse por esto. Se dedican felizmente a demostrar teoremas como los otros matemáticos del departamento de matemáticas, y probablemente pronto dejan de notar que el edificio en el que trabajan dice "ciencias de la computación" en el exterior. Pero para los hackers, esta etiqueta es un problema. Si lo que están haciendo se llama ciencia, les hace sentir que deberían actuar de manera científica. Así que, en lugar de hacer lo que realmente quieren hacer, que es diseñar software hermoso, los hackers en universidades y laboratorios de investigación sienten que deberían escribir artículos de investigación.

En el mejor de los casos, los artículos son solo una formalidad. Los hackers escriben software genial y luego escriben un artículo sobre él, y el artículo se convierte en un sustituto del logro representado por el software. Pero a menudo este desajuste causa problemas. Es fácil alejarse de crear cosas hermosas hacia crear cosas feas que son temas más adecuados para artículos de investigación.

Desafortunadamente, las cosas hermosas no siempre son los mejores temas para los artículos. En primer lugar, la investigación debe ser original, y como cualquiera que haya escrito una disertación doctoral sabe, la forma de asegurarse de que está explorando territorio virgen es delimitar un terreno que nadie quiere. En segundo lugar, la investigación debe ser sustancial, y los sistemas torpes producen artículos más sustanciosos, porque se puede escribir sobre los obstáculos que hay que superar para hacer las cosas. Nada produce problemas sustanciosos como empezar con las suposiciones equivocadas. La mayor parte de la IA es un ejemplo de esta regla; si asumes que el conocimiento se puede representar como una lista de expresiones de lógica de predicados cuyos argumentos representan conceptos abstractos, tendrás muchos artículos que escribir sobre cómo hacer que esto funcione. Como solía decir Ricky Ricardo: "¡Lucy, tienes mucho que explicar!".

La forma de crear algo hermoso a menudo es hacer ajustes sutiles a algo que ya existe, o combinar ideas existentes de una manera ligeramente nueva. Este tipo de trabajo es difícil de transmitir en un artículo de investigación.

Entonces, ¿por qué las universidades y los laboratorios de investigación continúan juzgando a los hackers por sus publicaciones? Por la misma razón que el "aptitud escolar" se mide con pruebas estandarizadas simplistas, o la productividad de los programadores se mide en líneas de código. Estas pruebas son fáciles de aplicar, y no hay nada tan tentador como una prueba fácil que funciona más o menos.

Medir lo que los hackers realmente intentan hacer, diseñar software hermoso, sería mucho más difícil. Necesitas un buen sentido del diseño para juzgar un buen diseño. Y no hay correlación, excepto posiblemente una negativa, entre la capacidad de las personas para reconocer un buen diseño y su confianza en que pueden hacerlo.

La única prueba externa es el tiempo. Con el tiempo, las cosas hermosas tienden a prosperar y las cosas feas tienden a ser descartadas. Desafortunadamente, las cantidades de tiempo involucradas pueden ser más largas que las vidas humanas. Samuel Johnson dijo que se necesitaban cien años para que la reputación de un escritor convergiera. Tienes que esperar a que mueran los amigos influyentes del escritor, y luego a que mueran todos sus seguidores.

Creo que los hackers simplemente tienen que resignarse a tener un gran componente aleatorio en sus reputaciones. En esto no son diferentes de otros creadores. De hecho, tienen suerte en comparación. La influencia de la moda no es tan grande en el hacking como en la pintura.

Hay cosas peores que tener gente que malinterprete tu trabajo. Un peligro peor es que tú mismo malinterpretes tu trabajo. Los campos relacionados son donde buscas ideas. Si te encuentras en el departamento de ciencias de la computación, existe una tentación natural de creer, por ejemplo, que el hacking es la versión aplicada de lo que la informática teórica es la teoría. Durante todo el tiempo que estuve en la escuela de posgrado, tuve una sensación incómoda en el fondo de mi mente de que debía saber más teoría, y que era muy negligente de mi parte haber olvidado todo eso tres semanas después del examen final.

Ahora me doy cuenta de que me equivoqué. Los hackers necesitan entender la teoría de la computación tanto como los pintores necesitan entender la química de la pintura. Necesitas saber cómo calcular la complejidad temporal y espacial y sobre la completitud de Turing. También podrías querer recordar al menos el concepto de una máquina de estados, en caso de que tengas que escribir un analizador o una biblioteca de expresiones regulares. Los pintores, de hecho, tienen que recordar mucho más sobre la química de la pintura que eso.

He descubierto que las mejores fuentes de ideas no son los otros campos que tienen la palabra "computadora" en sus nombres, sino los otros campos habitados por creadores. La pintura ha sido una fuente de ideas mucho más rica que la teoría de la computación.

Por ejemplo, me enseñaron en la universidad que uno debería idear un programa completamente en papel antes de siquiera acercarse a una computadora. Descubrí que no programaba de esa manera. Descubrí que me gustaba programar sentado frente a una computadora, no a un trozo de papel. Peor aún, en lugar de escribir pacientemente un programa completo y asegurarme de que era correcto, tendía a simplemente lanzar código que estaba irremediablemente roto, y gradualmente lo iba puliendo. La depuración, me enseñaron, era una especie de pase final donde se atrapaban errores tipográficos y descuidos. Tal como yo trabajaba, parecía que la programación consistía en depurar.

Durante mucho tiempo me sentí mal por esto, al igual que una vez me sentí mal por no sostener mi lápiz como me enseñaron en la escuela primaria. Si solo hubiera mirado a los otros creadores, los pintores o los arquitectos, me habría dado cuenta de que había un nombre para lo que estaba haciendo: esbozar. Por lo que puedo decir, la forma en que me enseñaron a programar en la universidad estaba completamente equivocada. Deberías idear programas mientras los escribes, al igual que lo hacen los escritores, los pintores y los arquitectos.

Darme cuenta de esto tiene implicaciones reales para el diseño de software. Significa que un lenguaje de programación debe ser, sobre todo, maleable. Un lenguaje de programación sirve para pensar en programas, no para expresar programas que ya has pensado. Debería ser un lápiz, no un bolígrafo. El tipado estático sería una buena idea si la gente realmente escribiera programas como me enseñaron en la universidad. Pero así no es como escriben programas los hackers que conozco. Necesitamos un lenguaje que nos permita garabatear, emborronar y difuminar, no un lenguaje donde tengas que sentarte con una taza de té de tipos equilibrada en tu rodilla y mantener una conversación educada con una tía estricta de un compilador.

Mientras hablamos de tipado estático, identificarnos con los creadores nos salvará de otro problema que aflige a las ciencias: la envidia matemática. Todos en las ciencias creen secretamente que los matemáticos son más inteligentes que ellos. Creo que los matemáticos también lo creen. En cualquier caso, el resultado es que los científicos tienden a hacer que su trabajo parezca lo más matemático posible. En un campo como la física, esto probablemente no hace mucho daño, pero cuanto más te alejas de las ciencias naturales, más se convierte en un problema.

Una página de fórmulas simplemente se ve muy impresionante. (Consejo: para una mayor impresión, use variables griegas). Y por lo tanto, hay una gran tentación de trabajar en problemas que se pueden tratar formalmente, en lugar de problemas que son, digamos, importantes.

Si los hackers se identificaran con otros creadores, como escritores y pintores, no se sentirían tentados a hacer esto. Los escritores y pintores no sufren de envidia matemática. Sienten que están haciendo algo completamente diferente. Yo también creo que los hackers lo son.

Si las universidades y los laboratorios de investigación impiden que los hackers hagan el tipo de trabajo que quieren hacer, quizás el lugar para ellos sean las empresas. Desafortunadamente, la mayoría de las empresas tampoco les permitirán a los hackers hacer lo que quieren. Las universidades y los laboratorios de investigación obligan a los hackers a ser científicos, y las empresas los obligan a ser ingenieros.

Yo mismo descubrí esto muy recientemente. Cuando Yahoo compró Viaweb, me preguntaron qué quería hacer. Nunca me había gustado mucho el lado comercial, y dije que solo quería hackear. Cuando llegué a Yahoo, descubrí que lo que significaba hackear para ellos era implementar software, no diseñarlo. Los programadores eran vistos como técnicos que traducían las visiones (si es que esa es la palabra) de los gerentes de producto a código.

Este parece ser el plan por defecto en las grandes empresas. Lo hacen porque disminuye la desviación estándar del resultado. Solo un pequeño porcentaje de hackers puede diseñar software, y es difícil para los responsables de una empresa identificarlos. Así que, en lugar de confiar el futuro del software a un hacker brillante, la mayoría de las empresas establecen las cosas de manera que sea diseñado por un comité, y los hackers simplemente implementan el diseño.

Si quieres ganar dinero en algún momento, recuerda esto, porque esta es una de las razones por las que las startups ganan. Las grandes empresas quieren disminuir la desviación estándar de los resultados de diseño porque quieren evitar desastres. Pero cuando amortiguas las oscilaciones, pierdes los puntos altos tanto como los bajos. Esto no es un problema para las grandes empresas, porque no ganan creando productos geniales. Las grandes empresas ganan apestando menos que otras grandes empresas.

Así que si puedes encontrar una manera de entrar en una guerra de diseño con una empresa lo suficientemente grande como para que su software sea diseñado por gerentes de producto, nunca podrán seguirte el ritmo. Sin embargo, estas oportunidades no son fáciles de encontrar. Es difícil involucrar a una gran empresa en una guerra de diseño, al igual que es difícil involucrar a un oponente dentro de un castillo en combate cuerpo a cuerpo. Sería bastante fácil escribir un procesador de textos mejor que Microsoft Word, por ejemplo, pero Microsoft, dentro del castillo de su monopolio del sistema operativo, probablemente ni siquiera se daría cuenta si lo hicieras.

El lugar para librar guerras de diseño es en mercados nuevos, donde nadie ha logrado aún establecer fortificaciones. Ahí es donde puedes ganar a lo grande adoptando un enfoque audaz para el diseño, y haciendo que las mismas personas diseñen e implementen el producto. Microsoft hizo esto mismo al principio. También lo hizo Apple. Y Hewlett-Packard. Sospecho que casi todas las startups exitosas lo han hecho.

Así que una forma de crear software genial es iniciar tu propia startup. Sin embargo, hay dos problemas con esto. Uno es que en una startup tienes que hacer mucho más que escribir software. En Viaweb, me consideraba afortunado si lograba hackear una cuarta parte del tiempo. Y las cosas que tenía que hacer el otro tres cuartos del tiempo iban desde tediosas hasta aterradoras. Tengo un punto de referencia para esto, porque una vez tuve que salir de una reunión de junta para que me empastaran unas caries. Recuerdo estar sentado en el sillón del dentista, esperando el taladro, y sentirme como si estuviera de vacaciones.

El otro problema con las startups es que no hay mucha superposición entre el tipo de software que genera dinero y el que es interesante de escribir. Los lenguajes de programación son interesantes de escribir, y el primer producto de Microsoft fue uno, de hecho, pero nadie pagará por lenguajes de programación ahora. Si quieres ganar dinero, tiendes a verte obligado a trabajar en problemas que son demasiado desagradables para que cualquiera los resuelva gratis.

Todos los creadores se enfrentan a este problema. Los precios los determinan la oferta y la demanda, y simplemente no hay tanta demanda de cosas en las que sea divertido trabajar como de cosas que resuelven los problemas mundanos de los clientes individuales. Actuar en obras de teatro off-Broadway simplemente no paga tan bien como usar un traje de gorila en el stand de alguien en una feria comercial. Escribir novelas no paga tan bien como escribir copys publicitarios para trituradores de basura. Y hackear lenguajes de programación no paga tan bien como averiguar cómo conectar la base de datos heredada de alguna empresa a su servidor web.

Creo que la respuesta a este problema, en el caso del software, es un concepto conocido por casi todos los creadores: el trabajo diurno. Esta frase comenzó con los músicos, que actúan por la noche. Más generalmente, significa que tienes un tipo de trabajo que haces por dinero, y otro por amor.

Casi todos los creadores tienen trabajos diurnos al principio de sus carreras. Los pintores y escritores notoriamente lo hacen. Si tienes suerte, puedes conseguir un trabajo diurno que esté estrechamente relacionado con tu trabajo real. Los músicos a menudo parecen trabajar en tiendas de discos. Un hacker que trabaja en algún lenguaje de programación o sistema operativo podría, de manera similar, conseguir un trabajo diurno usándolo. [1]

Cuando digo que la respuesta es que los hackers tengan trabajos diurnos y trabajen en software hermoso aparte, no propongo esto como una idea nueva. De esto se trata el hacking de código abierto. Lo que digo es que el código abierto es probablemente el modelo correcto, porque ha sido confirmado de forma independiente por todos los demás creadores.

Me parece sorprendente que cualquier empleador se muestre reacio a permitir que los hackers trabajen en proyectos de código abierto. En Viaweb, habríamos sido reacios a contratar a alguien que no lo hiciera. Cuando entrevistábamos programadores, lo principal que nos importaba era qué tipo de software escribían en su tiempo libre. No puedes hacer nada realmente bien a menos que te apasione, y si te encanta hackear, inevitablemente trabajarás en tus propios proyectos. [2]

Dado que los hackers son creadores en lugar de científicos, el lugar correcto para buscar metáforas no está en las ciencias, sino entre otros tipos de creadores. ¿Qué más puede enseñarnos la pintura sobre el hacking?

Una cosa que podemos aprender, o al menos confirmar, del ejemplo de la pintura es cómo aprender a hackear. Aprendes a pintar principalmente haciéndolo. Lo mismo ocurre con el hacking. La mayoría de los hackers no aprenden a hackear tomando cursos universitarios de programación. Aprenden a hackear escribiendo sus propios programas a los trece años. Incluso en las clases universitarias, aprendes a hackear principalmente hackeando. [3]

Dado que los pintores dejan un rastro de trabajo detrás de ellos, puedes verlos aprender haciendo. Si miras el trabajo de un pintor en orden cronológico, encontrarás que cada pintura se basa en cosas que se han aprendido en las anteriores. Cuando hay algo en una pintura que funciona muy bien, generalmente puedes encontrar la versión 1 en una forma más pequeña en alguna pintura anterior.

Creo que la mayoría de los creadores trabajan de esta manera. Los escritores y arquitectos también parecen hacerlo. Quizás sería bueno que los hackers actuaran más como pintores, y comenzaran regularmente de nuevo desde cero, en lugar de continuar trabajando durante años en un proyecto, e intentar incorporar todas sus ideas posteriores como revisiones.

El hecho de que los hackers aprendan a hackear haciéndolo es otra señal de cuán diferente es el hacking de las ciencias. Los científicos no aprenden ciencia haciéndola, sino haciendo laboratorios y conjuntos de problemas. Los científicos comienzan haciendo un trabajo que es perfecto, en el sentido de que solo intentan reproducir un trabajo que alguien más ya ha hecho por ellos. Eventualmente, llegan al punto en que pueden hacer trabajo original. Mientras que los hackers, desde el principio, están haciendo trabajo original; simplemente es muy malo. Así que los hackers empiezan originales y mejoran, y los científicos empiezan bien y se vuelven originales.

La otra forma en que los creadores aprenden es a través de ejemplos. Para un pintor, un museo es una biblioteca de referencia de técnicas. Durante cientos de años, ha sido parte de la educación tradicional de los pintores copiar las obras de los grandes maestros, porque copiar te obliga a observar de cerca la forma en que se hace una pintura.

Los escritores también hacen esto. Benjamin Franklin aprendió a escribir resumiendo los puntos de los ensayos de Addison y Steele y luego tratando de reproducirlos. Raymond Chandler hizo lo mismo con las historias de detectives.

Los hackers, asimismo, pueden aprender a programar mirando buenos programas, no solo lo que hacen, sino también el código fuente. Uno de los beneficios menos publicitados del movimiento de código abierto es que ha facilitado el aprendizaje de la programación. Cuando aprendí a programar, tuvimos que depender principalmente de ejemplos en libros. El único bloque grande de código disponible entonces era Unix, pero incluso este no era de código abierto. La mayoría de las personas que leían el código fuente lo hacían en fotocopias ilícitas del libro de John Lions, que aunque escrito en 1977, no se permitió publicar hasta 1996.

Otro ejemplo que podemos tomar de la pintura es la forma en que las pinturas se crean mediante el refinamiento gradual. Las pinturas suelen comenzar con un boceto. Gradualmente se van rellenando los detalles. Pero no es meramente un proceso de rellenado. A veces, los planes originales resultan ser erróneos. Innumerables pinturas, cuando las miras con rayos X, resultan tener extremidades que han sido movidas o rasgos faciales que han sido reajustados.

Aquí hay un caso en el que podemos aprender de la pintura. Creo que el hacking también debería funcionar así. No es realista esperar que las especificaciones de un programa sean perfectas. Es mejor si admites esto de antemano y escribes programas de manera que permitan que las especificaciones cambien sobre la marcha.

(La estructura de las grandes empresas hace que esto sea difícil para ellas, por lo que aquí hay otro lugar donde las startups tienen una ventaja.)

Todo el mundo conoce ahora el peligro de la optimización prematura. Creo que deberíamos estar igual de preocupados por el diseño prematuro: decidir demasiado pronto qué debería hacer un programa.

Las herramientas adecuadas pueden ayudarnos a evitar este peligro. Un buen lenguaje de programación debería, como la pintura al óleo, facilitar el cambio de opinión. El tipado dinámico es una ventaja aquí porque no tienes que comprometerte con representaciones de datos específicas de antemano. Pero la clave de la flexibilidad, creo, es hacer que el lenguaje sea muy abstracto. El programa más fácil de cambiar es uno que es muy corto.

Esto suena a paradoja, pero una gran pintura tiene que ser mejor de lo que tiene que ser. Por ejemplo, cuando Leonardo pintó el retrato de Ginevra de Benci en la National Gallery, puso un arbusto de enebro detrás de su cabeza. En él pintó cuidadosamente cada hoja individual. Muchos pintores podrían haber pensado: esto es solo algo para poner en el fondo para enmarcar su cabeza. Nadie lo mirará tan de cerca.

Leonardo no. Lo mucho que trabajó en una parte de una pintura no dependía en absoluto de lo de cerca que esperaba que alguien la mirara. Era como Michael Jordan. Implacable.

La implacabilidad gana porque, en conjunto, los detalles invisibles se vuelven visibles. Cuando la gente pasa junto al retrato de Ginevra de Benci, su atención a menudo se ve inmediatamente cautivada por él, incluso antes de que miren la etiqueta y noten que dice Leonardo da Vinci. Todos esos detalles invisibles se combinan para producir algo simplemente impresionante, como mil voces apenas audibles cantando a la vez.

El gran software, asimismo, requiere una devoción fanática por la belleza. Si miras dentro de un buen software, encontrarás que las partes que nadie debe ver también son hermosas. No pretendo escribir software genial, pero sé que cuando se trata de código, me comporto de una manera que me haría elegible para medicamentos recetados si abordara la vida cotidiana de la misma manera. Me vuelve loco ver código mal indentado, o que usa nombres de variables feos.

Si un hacker fuera un mero implementador, convirtiendo una especificación en código, entonces podría simplemente trabajar de un extremo a otro como alguien que cava una zanja. Pero si el hacker es un creador, tenemos que tener en cuenta la inspiración.

En el hacking, como en la pintura, el trabajo viene en ciclos. A veces te emocionas con algún proyecto nuevo y quieres trabajar dieciséis horas al día en él. Otras veces nada parece interesante.

Para hacer un buen trabajo, tienes que tener en cuenta estos ciclos, porque se ven afectados por cómo reaccionas ante ellos. Cuando conduces un coche con transmisión manual en una cuesta, a veces tienes que soltar el embrague para evitar que se cale. Soltarlo también puede evitar que la ambición se cale. Tanto en la pintura como en el hacking hay algunas tareas que son aterradoramente ambiciosas, y otras que son reconfortantemente rutinarias. Es una buena idea guardar algunas tareas fáciles para los momentos en que de otro modo te atascarías.

En el hacking, esto puede significar literalmente guardar errores. Me gusta depurar: es la única vez que el hacking es tan sencillo como la gente cree. Tienes un problema totalmente restringido, y todo lo que tienes que hacer es resolverlo. Tu programa se supone que hace x. En cambio, hace y. ¿Dónde sale mal? Sabes que vas a ganar al final. Es tan relajante como pintar una pared.

El ejemplo de la pintura puede enseñarnos no solo cómo gestionar nuestro propio trabajo, sino cómo trabajar juntos. Gran parte del gran arte del pasado es obra de múltiples manos, aunque solo haya un nombre en la pared junto a él en el museo. Leonardo fue aprendiz en el taller de Verrocchio y pintó uno de los ángeles en su Bautismo de Cristo. Este tipo de cosas era la regla, no la excepción. Miguel Ángel fue considerado especialmente dedicado por insistir en pintar él mismo todas las figuras del techo de la Capilla Sixtina.

Por lo que sé, cuando los pintores trabajaban juntos en una pintura, nunca trabajaban en las mismas partes. Era común que el maestro pintara las figuras principales y que los asistentes pintaran las otras y el fondo. Pero nunca tenías a un tipo pintando sobre el trabajo de otro.

Creo que este es el modelo correcto para la colaboración en software también. No lo lleves demasiado lejos. Cuando una pieza de código está siendo hackeada por tres o cuatro personas diferentes, ninguna de las cuales realmente la posee, terminará siendo como una sala común. Tenderá a sentirse sombría y abandonada, y acumulará basura. La forma correcta de colaborar, creo, es dividir los proyectos en módulos claramente definidos, cada uno con un propietario definido, y con interfaces entre ellos que estén tan cuidadosamente diseñadas y, si es posible, tan articuladas como los lenguajes de programación.

Al igual que la pintura, la mayoría del software está destinado a una audiencia humana. Y por lo tanto, los hackers, al igual que los pintores, deben tener empatía para hacer un trabajo realmente genial. Tienes que ser capaz de ver las cosas desde el punto de vista del usuario.

Cuando era niño, siempre me decían que viera las cosas desde el punto de vista de otra persona. Lo que esto siempre significaba en la práctica era hacer lo que otra persona quería, en lugar de lo que yo quería. Esto, por supuesto, le dio mala fama a la empatía, y me propuse no cultivarla.

Vaya, qué equivocado estaba. Resulta que ver las cosas desde el punto de vista de otras personas es prácticamente el secreto del éxito. No significa necesariamente ser abnegado. Ni mucho menos. Comprender cómo ve las cosas otra persona no implica que actuarás en su interés; en algunas situaciones, en la guerra, por ejemplo, quieres hacer exactamente lo contrario. [4]

La mayoría de los creadores hacen cosas para una audiencia humana. Y para atraer a una audiencia, tienes que entender lo que necesita. Casi todas las pinturas más grandes son pinturas de personas, por ejemplo, porque las personas son lo que más interesa a las personas.

La empatía es probablemente la diferencia más importante entre un buen hacker y uno genial. Algunos hackers son bastante inteligentes, pero en cuanto a empatía son prácticamente solipsistas. Es difícil para esas personas diseñar software genial [5], porque no pueden ver las cosas desde el punto de vista del usuario.

Una forma de saber qué tan buenas son las personas en empatía es verlas explicar una pregunta técnica a alguien sin antecedentes técnicos. Probablemente todos conocemos personas que, aunque inteligentes en otros aspectos, son cómicamente malas en esto. Si alguien les pregunta en una cena qué es un lenguaje de programación, dirán algo como "Oh, un lenguaje de alto nivel es lo que el compilador utiliza como entrada para generar código objeto". ¿Lenguaje de alto nivel? ¿Compilador? ¿Código objeto? Alguien que no sabe qué es un lenguaje de programación, obviamente, tampoco sabe qué son estas cosas.

Parte de lo que el software tiene que hacer es explicarse a sí mismo. Así que para escribir buen software, tienes que entender cuánto saben poco los usuarios. Se acercarán al software sin preparación, y será mejor que haga lo que ellos adivinan que hará, porque no leerán el manual. El mejor sistema que he visto a este respecto fue el Macintosh original, en 1985. Hizo lo que el software casi nunca hace: simplemente funcionó. [6]

El código fuente también debe explicarse a sí mismo. Si pudiera hacer que la gente recordara una sola cita sobre programación, sería la que está al principio de Structure and Interpretation of Computer Programs.

Los programas deben escribirse para que la gente los lea, y solo incidentalmente para que las máquinas los ejecuten.

Necesitas tener empatía no solo por tus usuarios, sino por tus lectores. Está en tu interés, porque tú serás uno de ellos. Muchos hackers han escrito un programa solo para descubrir, al volver a él seis meses después, que no tienen idea de cómo funciona. Conozco a varias personas que han renunciado a Perl después de tales experiencias. [7]

La falta de empatía se asocia con la inteligencia, hasta el punto de que incluso hay una cierta moda por ella en algunos lugares. Pero no creo que haya ninguna correlación. Puedes tener éxito en matemáticas y ciencias naturales sin tener que aprender empatía, y las personas en estos campos tienden a ser inteligentes, por lo que las dos cualidades han llegado a asociarse. Pero también hay muchas personas tontas que son malas en empatía.

Entonces, si el hacking funciona como la pintura y la escritura, ¿es tan genial? Después de todo, solo se vive una vez. Bien podrías pasarlo trabajando en algo grandioso.

Desafortunadamente, la pregunta es difícil de responder. Siempre hay un gran desfase temporal en el prestigio. Es como la luz de una estrella distante. La pintura tiene prestigio ahora debido al gran trabajo que la gente hizo hace quinientos años. En ese momento, nadie pensó que estas pinturas fueran tan importantes como lo hacemos hoy. Le habría parecido muy extraño a la gente de la época que Federico da Montefeltro, el Duque de Urbino, fuera conocido algún día principalmente como el tipo con la nariz extraña en una pintura de Piero della Francesca.

Así que, aunque admito que el hacking no parece tan genial como la pintura ahora, debemos recordar que la propia pintura no parecía tan genial en sus días de gloria como lo hace ahora.

Lo que podemos decir con cierta confianza es que estos son los días de gloria del hacking. En la mayoría de los campos, el gran trabajo se realiza al principio. Las pinturas realizadas entre 1430 y 1500 siguen siendo insuperables. Shakespeare apareció justo cuando el teatro profesional estaba naciendo, y llevó el medio tan lejos que todos los dramaturgos posteriores han tenido que vivir a su sombra. Albrecht Durer hizo lo mismo con el grabado, y Jane Austen con la novela.

Una y otra vez vemos el mismo patrón. Aparece un nuevo medio, y la gente está tan entusiasmada con él que explora la mayoría de sus posibilidades en las primeras generaciones. El hacking parece estar en esta fase ahora.

La pintura no era, en tiempos de Leonardo, tan genial como su trabajo ayudó a hacerla. Qué tan genial resulte ser el hacking dependerá de lo que podamos hacer con este nuevo medio.

Notas

[1] El mayor daño que la fotografía le ha hecho a la pintura puede ser el hecho de que mató el mejor trabajo diurno. La mayoría de los grandes pintores de la historia se mantenían pintando retratos.

[2] Me han dicho que Microsoft desaconseja a los empleados que contribuyan a proyectos de código abierto, incluso en su tiempo libre. Pero tantos de los mejores hackers trabajan en proyectos de código abierto ahora que el principal efecto de esta política puede ser asegurar que no podrán contratar programadores de primera categoría.

[3] Lo que aprendes sobre programación en la universidad es muy parecido a lo que aprendes sobre libros o ropa o citas: qué mal gusto tenías en la escuela secundaria.

[4] Aquí hay un ejemplo de empatía aplicada. En Viaweb, si no podíamos decidir entre dos alternativas, preguntábamos: ¿qué odiarían más nuestros competidores? En un momento dado, un competidor agregó una característica a su software que era básicamente inútil, pero como era una de las pocas que tenían y nosotros no, la promocionaron mucho en la prensa especializada. Podríamos haber intentado explicar que la característica era inútil, pero decidimos que molestaría más a nuestro competidor si la implementábamos nosotros mismos, así que hackeamos nuestra propia versión esa tarde.

[5] Excepto editores de texto y compiladores. Los hackers no necesitan empatía para diseñar estos, porque ellos mismos son usuarios típicos.

[6] Bueno, casi. Se pasaron un poco de la RAM disponible, causando mucho intercambio de disco inconveniente, pero esto podría solucionarse en unos meses comprando una unidad de disco adicional.

[7] La forma de hacer que los programas sean fáciles de leer no es rellenarlos de comentarios. Llevaría la cita de Abelson y Sussman un paso más allá. Los lenguajes de programación deben diseñarse para expresar algoritmos, y solo incidentalmente para decirle a las computadoras cómo ejecutarlos. Un buen lenguaje de programación debería ser mejor para explicar software que el inglés. Solo deberías necesitar comentarios cuando haya algún tipo de solución improvisada de la que necesites advertir a los lectores, al igual que en una carretera solo hay flechas en las partes con curvas inesperadamente pronunciadas.

Gracias a Trevor Blackwell, Robert Morris, Dan Giffin y Lisa Randall por leer borradores de esto, y a Henry Leitner y Larry Finkelstein por invitarme a hablar.