HACKERS Y PINTORES

Mayo 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. Mucha gente parecía sorprendida de 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 un impulso primario.

Ambas imágenes son incorrectas. 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 de los más parecidos.

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

Nunca me ha gustado el término "ciencia de la computación". La principal razón por la que no me gusta es que no existe tal cosa. La ciencia de la computación es una bolsa de áreas vagamente relacionadas agrupadas por un accidente de la historia, como Yugoslavia. En un extremo tienes a personas que son realmente matemáticos, pero llaman a lo que están haciendo ciencia de la computación para que puedan obtener subvenciones de DARPA. En el medio tienes a 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 para los arquitectos o la pintura para los pintores. Es como si los matemáticos, los físicos y los arquitectos tuvieran que estar en el mismo departamento.

A veces lo que hacen los hackers se llama "ingeniería de software", pero este término también es engañoso. Los buenos diseñadores de software no son más ingenieros que los arquitectos. La frontera entre la arquitectura y la 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 averiguan cómo hacerlo.

El qué y el cómo no deben mantenerse demasiado separados. Estás pidiendo problemas si intentas decidir qué hacer sin entender cómo hacerlo. Pero el hacking ciertamente puede ser más que simplemente decidir cómo implementar una especificación. En su mejor momento, es crear la especificación, aunque resulta que la mejor manera de hacerlo es implementarla.

Quizás algún día la "ciencia de la computación" se divida, como Yugoslavia, en sus partes componentes. Eso podría ser una buena cosa. Especialmente si significaba la independencia de mi tierra natal, el hacking.

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

A los matemáticos no parece molestarles esto. Felizmente se ponen a trabajar demostrando teoremas como los otros matemáticos en el departamento de matemáticas, y probablemente pronto dejen de notar que el edificio en el que trabajan dice "ciencia de la computación" en el exterior. Pero para los hackers esta etiqueta es un problema. Si a lo que están haciendo se le llama ciencia, les hace sentir que deberían estar actuando de manera científica. Así que en lugar de hacer lo que realmente quieren hacer, que es diseñar un software hermoso, los hackers en las universidades y laboratorios de investigación sienten que deberían estar escribiendo 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 al respecto, 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 la construcción de cosas hermosas hacia la construcción de cosas feas que se prestan mejor como temas de artículos de investigación.

Desafortunadamente, las cosas hermosas no siempre se convierten en los mejores temas para los artículos. Número uno, la investigación debe ser original, y como cualquiera que haya escrito una disertación de doctorado sabe, la forma de asegurarse de que se está explorando un territorio virgen es delimitar un pedazo de terreno que nadie quiere. Número dos, la investigación debe ser sustancial, y los sistemas incómodos producen artículos más sustanciosos, porque puedes escribir sobre los obstáculos que tienes que superar para lograr las cosas. Nada produce problemas más sustanciosos que comenzar con los supuestos equivocados. 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 sutiles ajustes 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 la "aptitud académica" se mide mediante pruebas estandarizadas simples, 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, los períodos de tiempo involucrados pueden ser más largos que una vida humana. Samuel Johnson dijo que se necesitaban cien años para que la reputación de un escritor se consolidara. 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 ni de cerca tan grande en el hacking como lo es en la pintura.

Hay cosas peores que la gente malinterprete tu trabajo. Un peligro mayor 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, hay una tentación natural de creer, por ejemplo, que el hacking es la versión aplicada de lo que la teoría de la computación teórica es la teoría.

Todo el tiempo que estuve en la escuela de posgrado tuve una sensación incómoda en la parte posterior de mi mente de que debería saber más teoría y que era muy negligente de mi parte haber olvidado todo eso en tres semanas del examen final.

Ahora me doy cuenta de que estaba equivocado. Los hackers necesitan entender la teoría de la computación más o menos tanto como los pintores necesitan entender la química de la pintura. Necesitas saber cómo calcular la complejidad de tiempo y espacio y sobre la completitud de Turing. También podrías querer recordar al menos el concepto de una máquina de estados, por si tienes que escribir un analizador o una biblioteca de expresiones regulares. De hecho, los pintores 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 mucho más rica de ideas que la teoría de la computación.

Por ejemplo, me enseñaron en la universidad que uno debe resolver un programa por completo en papel antes de acercarse siquiera a una computadora. Descubrí que no programaba de esta manera. Descubrí que me gustaba programar sentado frente a una computadora, no en un pedazo de papel. Peor aún, en lugar de escribir pacientemente un programa completo y asegurarme de que era correcto, tendía a simplemente vomitar código que estaba desesperadamente roto y gradualmente lo convertía en forma. El depurado, me enseñaron, era una especie de paso final donde se atrapaban errores tipográficos y descuidos. La forma en que 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 porque no sostenía mi lápiz de la manera que 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: boceto. Por lo que puedo ver, la forma en que me enseñaron a programar en la universidad estaba completamente equivocada. Deberías resolver programas mientras los estás escribiendo, al igual que los escritores, los pintores y los arquitectos.

Darse cuenta de esto tiene implicaciones reales para el diseño de software. Significa que un lenguaje de programación debe, sobre todo, ser maleable. Un lenguaje de programación es 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 idea excelente si la gente realmente escribiera programas de la manera en que me enseñaron en la universidad. Pero esa no es la forma en que escriben programas ninguno de los hackers que conozco. Necesitamos un lenguaje que nos permita garabatear, difuminar y manchar, no un lenguaje donde tengas que sentarte con una taza de té de tipos equilibrada en la rodilla y mantener una conversación educada con una tía estricta y anciana de un compilador.

Mientras estamos en el tema del tipado estático, identificarse con los creadores nos salvará de otro problema que afecta a las ciencias: la envidia de las matemáticas. Todos en las ciencias creen en secreto que los matemáticos son más inteligentes que ellos. Creo que los matemáticos también creen esto. 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, probablemente esto no cause mucho daño, pero cuanto más te alejes de las ciencias naturales, más problema se vuelve.

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

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

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 esté en las empresas. Desafortunadamente, la mayoría de las empresas tampoco dejarán que los hackers hagan 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 bastante recientemente. Cuando Yahoo compró Viaweb, me preguntaron qué quería hacer. Nunca me había gustado mucho el lado empresarial 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. A los programadores se les veía como técnicos que traducían las visiones (si es que se les puede llamar así) de los gerentes de producto en código.

Esto parece ser el plan predeterminado 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 realmente software, y es difícil para las personas que dirigen una empresa identificarlos. Entonces, en lugar de confiar el futuro del software a un brillante hacker, la mayoría de las empresas lo configuran de manera que sea diseñado por un comité y los hackers simplemente implementen 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 y los bajos. Esto no es un problema para las grandes empresas, porque no ganan haciendo grandes productos. Las grandes empresas ganan siendo menos malas que otras grandes empresas.

Entonces, 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 mantenerse al día contigo. Estas oportunidades no son fáciles de encontrar, sin embargo. Es difícil involucrar a una gran empresa en una guerra de diseño, así como 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 texto 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 nuevos mercados, donde nadie ha logrado establecer aún ninguna fortificación. Ahí es donde puedes ganar mucho adoptando un enfoque audaz en el diseño y teniendo a las mismas personas que diseñan y que implementan el producto. Incluso Microsoft, Apple y Hewlett-Packard hicieron esto al principio. Sospecho que casi todas las startups exitosas lo han hecho.

Así que una forma de crear un gran software 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 solo escribir software. En Viaweb me consideraba afortunado si lograba hackear una cuarta parte del tiempo. Y las cosas que tenía que hacer el resto 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 la junta directiva para que me rellenaran algunas caries. Recuerdo estar sentado en el sillón del dentista, esperando el taladro, y sentir que estaba de vacaciones.

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

Todos los creadores se enfrentan a este problema. Los precios se determinan por la oferta y la demanda, y simplemente no hay tanta demanda por las cosas que son divertidas de trabajar como la hay por las cosas que resuelven los problemas mundanos de los clientes individuales. Actuar en obras de teatro off-Broadway simplemente no paga tan bien como vestir un traje de gorila en el stand de alguien en una feria comercial. Escribir novelas no paga tan bien como escribir publicidad para trituradoras de basura. Y hackear lenguajes de programación no paga tan bien como averiguar cómo conectar la base de datos heredada de una 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 se presentan por la noche. En términos más generales, 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 los escritores lo hacen notoriamente. 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 u sistema operativo también podría poder conseguir un trabajo diurno usándolo. [1]

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

Me sorprende que cualquier empleador se muestre reacio a dejar 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 a 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 lo ames, y si te encanta hackear, inevitablemente estarás trabajando en proyectos propios. [2]

Debido a que los hackers son creadores en lugar de científicos, el lugar adecuado 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 hackeo?

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 hackeo. La mayoría de los hackers no aprenden a hackear tomando cursos universitarios de programación. Aprenden a hackear escribiendo programas propios a los trece años. Incluso en las clases universitarias, aprendes a hackear principalmente hackeando. [3]

Debido a que los pintores dejan un rastro de trabajo detrás de ellos, puedes ver cómo aprenden 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 de eso 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 los arquitectos también parecen hacerlo. Tal vez sería bueno que los hackers actuaran más como los pintores y comenzaran regularmente de cero, en lugar de seguir trabajando durante años en un solo 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 lo diferentes que son los hackers 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 el trabajo que alguien más ya ha hecho por ellos. Eventualmente, llegan al punto en el que pueden hacer un trabajo original. Mientras que los hackers, desde el principio, están haciendo un trabajo original; solo que es muy malo. Así que los hackers comienzan originales y se vuelven buenos, y los científicos comienzan buenos y se vuelven originales.

La otra forma en que los creadores aprenden es a partir 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 los obliga a mirar 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 intentando reproducirlos. Raymond Chandler hizo lo mismo con las historias de detectives.

Los hackers, de manera similar, 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 yo aprendí a programar, teníamos que confiar principalmente en los ejemplos de los libros. El único gran bloque de código disponible entonces era Unix, pero ni siquiera era de código abierto. La mayoría de las personas que leían el código lo hacían en fotocopias ilegales del libro de John Lions, que, aunque fue escrito en 1977, no se permitió publicar hasta 1996.

Otro ejemplo que podemos tomar de la pintura es la forma en que los cuadros se crean mediante un refinamiento gradual. Los cuadros suelen comenzar con un boceto. Gradualmente se van llenando los detalles. Pero no se trata simplemente de rellenar. A veces los planes originales resultan ser erróneos. Innumerables pinturas, cuando las miras en rayos X, resultan tener miembros que se han movido o rasgos faciales que se han reajustado.

Aquí tenemos un caso en el que podemos aprender de la pintura. Creo que el hacking también debería funcionar de esta manera. Es poco realista esperar que las especificaciones de un programa sean perfectas. Es mejor si admites esto de antemano y escribes programas en una forma que permita que las especificaciones cambien sobre la marcha.

(La estructura de las grandes empresas hace que esto les resulte difícil de hacer, por lo que aquí es otro lugar donde las startups tienen una ventaja).

Todos supongo que ahora conocen el peligro de la optimización prematura. Creo que deberíamos preocuparnos tanto por el diseño prematuro, es decir, decidir demasiado pronto qué debería hacer un programa.

Las herramientas adecuadas pueden ayudarnos a evitar este peligro. Un buen lenguaje de programación debe, como la pintura al óleo, facilitar cambiar de opinión. La tipificación dinámica 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 el que es muy corto.

Esto parece una 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 Galería Nacional, 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.

No Leonardo. 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 ocultos se vuelven visibles. Cuando la gente pasa por el retrato de Ginevra de Benci, a menudo su atención se detiene de inmediato en él, incluso antes de que miren la etiqueta y se den cuenta de que dice Leonardo da Vinci. Todos esos detalles ocultos se combinan para producir algo simplemente impresionante, como mil voces apenas audibles cantando al unísono.

El gran software, de la misma manera, requiere una devoción fanática por la belleza. Si miras dentro del buen software, encuentras que las partes que nadie se supone que vea también son hermosas. No estoy afirmando que yo escriba un gran software, pero sé que cuando se trata de código me comporto de una manera que me haría elegible para medicamentos recetados si me acercara a la vida cotidiana de la misma manera. Me vuelve loco ver código que está 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 a través de ella de un extremo a otro como alguien cavando 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 nuevo proyecto 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 a ellos. Cuando conduces un coche con transmisión manual cuesta arriba, tienes que soltar el embrague a veces para evitar que se cale. Soltar también puede evitar que la ambición se atasque. Tanto en la pintura como en el hacking hay algunas tareas que son terriblemente ambiciosas, y otras que son reconfortantemente rutinarias. Es una buena idea guardar algunas tareas fáciles para los momentos en los que de lo contrario te atrasarías.

En el hacking, esto literalmente puede significar guardar errores. Me gusta depurar: es el único momento en que el hacking es tan sencillo como la gente piensa que es. Tienes un problema totalmente limitado, y todo lo que tienes que hacer es resolverlo. Tu programa se supone que debe hacer x. En su lugar, hace y. ¿Dónde se equivoca? 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 norma, no la excepción. Michelangelo fue considerado especialmente dedicado por insistir en pintar él mismo todas las figuras del techo de la Capilla Sixtina.

Que yo sepa, cuando los pintores trabajaban juntos en un cuadro, nunca trabajaban en las mismas partes. Era común que el maestro pintara las figuras principales y que los asistentes pintaran las demás y el fondo. Pero nunca tuviste 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 un trozo de código está siendo hackeado por tres o cuatro personas diferentes, ninguna de las cuales realmente lo posee, terminará pareciéndose a una sala común. Tenderá a sentirse deprimente y abandonado, y acumulará suciedad. 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 parte del software está destinado a una audiencia humana. Y por lo tanto, los hackers, como los pintores, deben tener empatía para hacer un trabajo realmente excelente. Tienes que ser capaz de ver las cosas desde el punto de vista del usuario.

Cuando era niño siempre me decían que mirara 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 a la empatía mala fama, y me hice un punto de no cultivarla.

Caramba, me equivoqué. Resulta que mirar las cosas desde el punto de vista de otras personas es prácticamente el secreto del éxito. No necesariamente significa ser autosacrificio. Lejos de eso. Entender 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 necesitan. Casi todas las pinturas más grandes son pinturas de personas, por ejemplo, porque las personas son en lo que las personas están interesadas.

La empatía es probablemente la única diferencia más importante entre un buen hacker y un gran hacker. Algunos hackers son bastante inteligentes, pero cuando se trata de empatía son prácticamente solipsistas. Es difícil que tales personas diseñen un gran software [5], porque no pueden ver las cosas desde el punto de vista del usuario.

Una forma de saber cuán buenos son las personas en empatía es observarlos explicar una pregunta técnica a alguien sin antecedentes técnicos. Probablemente todos conocemos a personas que, aunque de lo contrario son inteligentes, son simplemente cómicamente malas en esto. Si alguien les pregunta en una fiesta qué es un lenguaje de programación, dirán algo como "Oh, un lenguaje de alto nivel es lo que el compilador usa 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. Entonces, para escribir un buen software tienes que entender cuán poco entienden los usuarios. Van a acercarse al software sin preparación, y más vale que haga lo que ellos adivinen que hará, porque no van a leer el manual. El mejor sistema que he visto en este sentido 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 solo una 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 también por tus lectores. Es en tu interés, porque serás uno de ellos. Muchos hackers han escrito un programa solo para encontrar, al volver a él seis meses después, que no tienen idea de cómo funciona. Conozco a varias personas que han jurado no usar Perl después de tales experiencias. [7]

La falta de empatía se asocia con la inteligencia, hasta el punto de que incluso hay algo de moda por ella en algunos lugares. Pero no creo que haya ninguna correlación. Puedes tener éxito en las matemáticas y las ciencias naturales sin tener que aprender empatía, y las personas en estos campos tienden a ser inteligentes, por lo que las dos cualidades se han asociado. Pero también hay mucha gente tonta que es mala en empatía. Solo escucha a las personas que llaman con preguntas en los programas de entrevistas. Hacen la pregunta que sea de una manera tan indirecta que los presentadores a menudo tienen que reformularla para ellos.

Entonces, si el hacking funciona como la pintura y la escritura, ¿es tan genial? Después de todo, solo tienes una vida. Podrías pasar el tiempo trabajando en algo genial.

Desafortunadamente, la pregunta es difícil de responder. Siempre hay un gran retraso 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 pensaba que estas pinturas fueran tan importantes como lo son hoy. Le habría parecido muy extraño a la gente de la época que Federico da Montefeltro, el Duque de Urbino, fuera conocido principalmente como el tipo con la nariz extraña en una pintura de Piero della Francesca.

Así que si bien 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 sin ser superadas. Shakespeare apareció justo cuando el teatro profesional estaba naciendo, y empujó el medio tan lejos que cada dramaturgo desde entonces ha 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 emocionada 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 la época 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 de día. La mayoría de los grandes pintores de la historia se mantenían pintando retratos.

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

[3] Lo que aprendes sobre programación en la universidad es muy parecido a lo que aprendes sobre libros, ropa o citas: el mal gusto que 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, un competidor agregó una función a su software que era básicamente inútil, pero como era una de las pocas que tenían que nosotros no, lo destacaron mucho en la prensa comercial. Podríamos haber intentado explicar que la función era inútil, pero decidimos que molestaría más a nuestro competidor si simplemente la implementáramos nosotros mismos, así que esa misma tarde hackeamos nuestra propia versión.

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

[6] Bueno, casi. Se excedieron un poco en la RAM disponible, lo que causó mucho intercambio de disco incómodo, pero esto se podía arreglar en unos pocos meses comprando un disco adicional.

[7] La forma de hacer que los programas sean fáciles de leer no es llenarlos de comentarios. Llevaría la cita de Abelson y Sussman un paso más allá. Los lenguajes de programación deberían diseñarse para expresar algoritmos y solo incidentalmente para decirles a las computadoras cómo ejecutarlos. Un buen lenguaje de programación debería ser mejor para explicar el software que el inglés. Solo deberías necesitar comentarios cuando haya algún tipo de parche 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.