HACKERS Y PINTORES

Mayo de 2003

(Este ensayo se deriva de una conferencia impartida por un invitado en Harvard, que incorporó una charla anterior en Northeastern).

Cuando terminé la carrera de informática, fui a la escuela de arte para estudiar pintura. A mucha gente le sorprendía que alguien interesado en las computadoras también se interesara por la pintura. Parecían pensar que hackear y pintar eran trabajos muy diferentes: que hackear era frío, preciso y metódico, y que pintar era la expresión frenética de algún impulso primario.

Ambas imágenes son erróneas. La piratería y la pintura tienen mucho en común. De hecho, de todos los tipos de personas que he conocido, los piratas informáticos y los pintores son los que más se parecen.

Lo que los hackers y los pintores tienen en común es que ambos son creadores. Al igual que los compositores, arquitectos y escritores, lo que los hackers y los pintores intentan hacer es crear cosas buenas. No se dedican a la investigación propiamente dicha, aunque si en el proceso de intentar crear cosas buenas descubren alguna técnica nueva, mucho mejor.

Nunca me ha gustado el término "ciencia informática". La razón principal por la que no me gusta es que no existe tal cosa. La ciencia informática es un conjunto de áreas tenuemente relacionadas que se juntaron por un accidente de la historia, como Yugoslavia. En un extremo tienes a gente que en realidad son matemáticos, pero que llaman a lo que hacen ciencia informática para poder obtener subvenciones de la DARPA. En el medio tienes a gente que trabaja en algo parecido a la historia natural de los ordenadores: estudian el comportamiento de los algoritmos para enrutar datos a través de redes, por ejemplo. Y en el otro extremo tienes a los hackers, que intentan escribir software interesante y para quienes los ordenadores son sólo un medio de expresión, como el hormigón lo es para los arquitectos o la pintura para los pintores. Es como si los matemáticos, los físicos y los arquitectos tuvieran que estar todos en el mismo departamento.

A veces, lo que hacen los hackers se denomina "ingeniería de software", pero este término es igualmente 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í. Se encuentra entre el qué y el cómo: los arquitectos deciden qué hacer y los ingenieros descubren cómo hacerlo.

No se debe mantener demasiado separados el qué y el cómo. Si intenta decidir qué hacer sin entender cómo hacerlo, se buscará problemas. Pero hackear puede ser sin duda algo más que decidir cómo implementar una especificación. En el mejor de los casos, consiste en crear la especificación, aunque resulta que la mejor forma de hacerlo es implementarla.

Tal vez algún día la "ciencia informática", como Yugoslavia, se desmembrará en sus componentes. Eso podría ser algo bueno. Especialmente si eso significara la independencia para mi tierra natal, la piratería.

Puede que agrupar todos estos distintos tipos de trabajo en un solo departamento sea conveniente desde el punto de vista administrativo, pero resulta confuso desde el punto de vista intelectual. Ésa es la otra razón por la que no me gusta el nombre de "ciencia informática". Se podría decir que la gente que está en el medio hace algo parecido a una ciencia experimental, pero la gente que está en los extremos, los hackers y los matemáticos, en realidad no hace ciencia.

A los matemáticos no parece importarles. Se ponen a trabajar con alegría demostrando teoremas como los demás matemáticos del departamento de matemáticas y probablemente pronto dejen de notar que el edificio en el que trabajan dice "ciencia informática" 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 un software atractivo, los hackers de las universidades y los 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 sólo 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 esta falta de correspondencia causa problemas. Es fácil dejar de lado la creación de cosas hermosas para dedicarse a la creación de cosas feas que son temas más adecuados para trabajos de investigación.

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

La forma de crear algo bello suele consistir en realizar modificaciones sutiles a algo que ya existe o combinar ideas existentes de una forma 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 siguen juzgando a los hackers por sus publicaciones? Por la misma razón que la "aptitud académica" 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 más tentador que una prueba fácil que funcione.

Medir lo que los hackers realmente intentan hacer, es decir, diseñar un software atractivo, sería mucho más difícil. Se necesita un buen sentido del diseño para juzgar un buen diseño. Y no existe correlación, salvo 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 bellas tienden a prosperar y las cosas feas tienden a ser descartadas. Desafortunadamente, los períodos de tiempo involucrados pueden ser más largos que las vidas humanas. Samuel Johnson dijo que la reputación de un escritor tardó cien años en converger. Hay que esperar a que mueran los amigos influyentes del escritor y luego a que mueran todos sus seguidores.

Creo que los hackers tienen que resignarse a que su reputación tenga un componente aleatorio. En esto no se diferencian de otros creadores. De hecho, tienen suerte en comparación. La influencia de la moda no es tan grande en el mundo de los hackers como en el de la pintura.

Hay cosas peores que el hecho de que la gente no entienda tu trabajo. Un peligro aún mayor es que tú mismo no entiendas tu trabajo. Los campos relacionados son donde vas en busca de ideas. Si te encuentras en el departamento de informática, 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 debería saber más teoría y que era un gran descuido por mi parte haber olvidado todo eso a las tres semanas del examen final.

Ahora me doy cuenta de que estaba equivocado. Los hackers necesitan entender la teoría de la computación tanto como los pintores necesitan entender la química de la pintura. Necesitan saber cómo calcular la complejidad temporal y espacial y sobre la completitud de Turing. Tal vez también quieran recordar al menos el concepto de máquina de estados, en caso de que tengan que escribir un analizador sintáctico 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 de ideas mucho más rica que la teoría de la computación.

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

Durante mucho tiempo me sentí mal por ello, igual que una vez me sentí mal por no sostener el lápiz como me enseñaron en la escuela primaria. Si tan solo hubiera observado a los demás creadores, los pintores o los arquitectos, me habría dado cuenta de que había un nombre para lo que estaba haciendo: dibujar. Hasta donde sé, la forma en que me enseñaron a programar en la universidad estaba completamente equivocada. Uno debe entender los programas a medida que los escribe, tal como lo hacen los escritores, los pintores y los arquitectos.

Comprender esto tiene implicaciones reales para el diseño de software. Significa que un lenguaje de programación debería ser, sobre todo, maleable. Un lenguaje de programación es para pensar en programas, no para expresar programas que ya se han pensado. Debería ser un lápiz, no un bolígrafo. La tipificación estática sería una buena idea si la gente realmente escribiera programas de la forma en que me enseñaron a hacerlo en la universidad. Pero no es así como escriben programas los hackers que conozco. Necesitamos un lenguaje que nos permita garabatear, manchar y emborronar, no un lenguaje en el que tengas que sentarte con una taza de té llena de tipos de letra en equilibrio sobre tu rodilla y mantener una conversación educada con una estricta tía vieja de compilador.

En cuanto a la tipificación estática, identificarnos con los creadores nos salvará de otro problema que afecta a las ciencias: la envidia matemática. Todo el mundo en el mundo de las ciencias cree en secreto 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 haga mucho daño, pero cuanto más nos alejamos de las ciencias naturales, más problemático se vuelve.

Una página de fórmulas resulta impresionante. (Consejo: para que resulte aún más impresionante, utilice variables griegas). Por eso existe una gran tentación de trabajar en problemas que se pueden tratar formalmente, en lugar de problemas que son, por ejemplo, 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 envidia de las matemáticas. Sienten que están haciendo algo completamente ajeno a ellas. Lo mismo les ocurre a los hackers, creo.

Si las universidades y los laboratorios de investigación impiden que los hackers hagan el tipo de trabajo que quieren hacer, tal vez el lugar para ellos sea en las empresas. Lamentablemente, la mayoría de las empresas tampoco permiten 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 lo descubrí hace muy poco. Cuando Yahoo compró Viaweb, me preguntaron qué quería hacer. Nunca me había gustado mucho el aspecto empresarial y dije que sólo quería hackear. Cuando llegué a Yahoo, me di cuenta de que hackear significaba para ellos 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 reduce la desviación estándar del resultado. Sólo un pequeño porcentaje de hackers puede diseñar software, y es difícil para quienes dirigen una empresa identificarlos. Por eso, en lugar de confiar el futuro del software a un hacker brillante, la mayoría de las empresas organizan el diseño de forma que lo diseñe un comité y los hackers se limiten a implementarlo.

Si quieres ganar dinero en algún momento, recuerda esto, porque es una de las razones por las que las empresas emergentes triunfan. Las grandes empresas quieren reducir la desviación estándar de los resultados de diseño porque quieren evitar desastres. Pero cuando se amortiguan las oscilaciones, se pierden tanto los puntos altos como los bajos. Esto no es un problema para las grandes empresas, porque no ganan fabricando grandes productos. Las grandes empresas ganan haciendo menos cosas que otras grandes empresas.

De modo que si se te ocurre una forma de entrar en una guerra de diseño con una empresa lo suficientemente grande como para que su software esté 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 enfrentarse a una gran empresa en una guerra de diseño, del mismo modo que es difícil enfrentarse a un oponente dentro de un castillo en un combate cuerpo a cuerpo. Sería bastante fácil crear un procesador de textos mejor que Microsoft Word, por ejemplo, pero Microsoft, dentro del castillo de su monopolio de sistemas operativos, probablemente ni siquiera se daría cuenta si lo hicieras.

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

Una forma de crear un software excelente es crear tu propia empresa. Sin embargo, esto tiene dos problemas. Uno es que en una empresa emergente tienes que hacer mucho más que escribir software. En Viaweb, me consideraba afortunado si me tocaba hackear una cuarta parte del tiempo. Y las cosas que tenía que hacer las otras tres cuartas partes del tiempo variaban entre tediosas y aterradoras. Tengo un punto de referencia para esto, porque una vez tuve que abandonar una reunión de la junta directiva para que me taparan unas caries. Recuerdo estar sentado en la silla del dentista, esperando a que llegara el torno, 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 tipo que es interesante de escribir. Los lenguajes de programación son interesantes de escribir, y el primer producto de Microsoft lo fue, de hecho, pero ahora nadie paga por lenguajes de programación. Si quieres ganar dinero, tiendes a verte obligado a trabajar en problemas que son demasiado desagradables para que cualquiera los pueda resolver gratis.

Todos los productores se enfrentan a este problema. Los precios están determinados por la oferta y la demanda, y no hay tanta demanda de cosas en las que sea divertido trabajar como de cosas que resuelvan los problemas mundanos de los clientes individuales. Actuar en obras fuera de Broadway no es tan rentable como llevar un traje de gorila en el stand de alguien en una feria comercial. Escribir novelas no es tan rentable como escribir textos publicitarios para trituradores de basura. Y hackear lenguajes de programación no es tan rentable como descubrir 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 que conocen casi todos los creadores: el trabajo diurno. Esta frase empezó con los músicos, que tocan por la noche. En términos más generales, significa que hay un tipo de trabajo que se hace por dinero y otro por amor.

Casi todos los creadores tienen trabajos fijos al principio de sus carreras. Los pintores y escritores son conocidos por ello. Si tienes suerte, puedes conseguir un trabajo fijo que esté estrechamente relacionado con tu trabajo real. Los músicos suelen trabajar en tiendas de discos. Un hacker que trabaje con algún lenguaje de programación o sistema operativo también podría conseguir un trabajo fijo utilizándolo. [1]

Cuando digo que la respuesta es que los hackers tengan trabajos fijos y trabajen en un software hermoso como actividad secundaria, no estoy proponiendo que sea una idea nueva. De eso se trata el hacking de código abierto. Lo que estoy diciendo es que el código abierto es probablemente el modelo correcto, porque ha sido confirmado independientemente por todos los demás creadores.

Me sorprende que cualquier empleador se muestre reacio a dejar que hackers trabajen en proyectos de código abierto. En Viaweb, nos habríamos mostrado reacios a contratar a alguien que no lo hiciera. Cuando entrevistamos 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 te guste, y si te encanta hackear, inevitablemente trabajarás en tus propios proyectos. [2]

Como los hackers son creadores y no científicos, el lugar adecuado para buscar metáforas no es en las ciencias, sino entre otros tipos de creadores. ¿Qué más nos puede enseñar 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. A pintar se aprende 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 sus propios programas a los trece años. Incluso en las clases universitarias, se aprende a hackear principalmente hackeando. [3]

Como los pintores dejan un rastro de trabajo tras de sí, se les puede observar aprender con la práctica. Si observamos el trabajo de un pintor en orden cronológico, descubriremos que cada cuadro se basa en cosas que se han aprendido en cuadros anteriores. Cuando hay algo en un cuadro que funciona muy bien, normalmente se puede encontrar una versión 1 de ese algo en un formato más pequeño en algún cuadro anterior.

Creo que la mayoría de los creadores trabajan de esta manera. Los escritores y arquitectos también parecen hacerlo. Tal vez sería bueno que los hackers actuaran más como pintores y comenzaran regularmente desde cero, en lugar de seguir 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 lo diferente que es el hacking de las ciencias. Los científicos no aprenden ciencia haciéndolo, sino haciendo laboratorios y series de problemas. Los científicos comienzan haciendo un trabajo que es perfecto, en el sentido de que sólo intentan reproducir el trabajo que alguien más ya ha hecho por ellos. Con el tiempo, llegan al punto en el que pueden hacer un trabajo original. Mientras que los hackers, desde el principio, hacen un trabajo original, pero muy malo. Así que los hackers empiezan siendo originales y se vuelven buenos, y los científicos empiezan siendo 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, copiar las obras de los grandes maestros ha sido parte de la educación tradicional de los pintores, porque copiar obliga a observar de cerca la forma en que se hace un cuadro.

Los escritores también hacen lo mismo. Benjamin Franklin aprendió a escribir resumiendo los puntos de vista de los ensayos de Addison y Steele y luego intentando reproducirlos. Raymond Chandler hizo lo mismo con las novelas policiacas.

Los hackers también pueden aprender a programar observando buenos programas, no sólo 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 hecho más fácil aprender a programar. Cuando yo aprendí a programar, teníamos que depender principalmente de ejemplos en libros. El único gran fragmento de código disponible en ese entonces era Unix, pero ni siquiera esto era código abierto. La mayoría de las personas que leyeron el código fuente lo hicieron en fotocopias ilícitas 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 se crean los cuadros mediante un refinamiento gradual. Los cuadros suelen empezar con un boceto. Poco a poco se van completando los detalles. Pero no se trata simplemente de un proceso de rellenado. A veces, los planos originales resultan ser erróneos. Innumerables cuadros, cuando los miramos en radiografías, resultan tener miembros que han sido movidos o rasgos faciales que han sido reajustados.

He aquí un caso en el que podemos aprender de la pintura. Creo que la piratería informática también debería funcionar de esta manera. No es realista esperar que las especificaciones de un programa sean perfectas. Es mejor admitirlo de antemano y escribir programas de forma 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 empresas emergentes tienen una ventaja).

Probablemente, a estas alturas todo el mundo conoce el peligro de la optimización prematura. Creo que deberíamos preocuparnos igual por el diseño prematuro, es decir, decidir demasiado pronto lo que debe 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, hacer que sea fácil cambiar de opinión. El tipado dinámico es una ventaja en este caso porque no hay que comprometerse 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 sea muy corto.

Puede parecer una paradoja, pero un gran cuadro 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, colocó un arbusto de enebro detrás de su cabeza y pintó cuidadosamente cada hoja. Muchos pintores podrían haber pensado que era solo algo para poner en el fondo para enmarcar su cabeza. Nadie lo miraría tan de cerca.

Leonardo no. El esfuerzo que hacía en una parte de un cuadro no dependía en absoluto de la atención que esperaba que le prestaran los demás. Era como Michael Jordan: incansable.

La implacabilidad triunfa porque, en conjunto, los detalles invisibles se hacen visibles. Cuando la gente pasa por delante del retrato de Ginevra de Benci, suele captar inmediatamente su atención, incluso antes de mirar la etiqueta y darse cuenta de que dice Leonardo da Vinci. Todos esos detalles invisibles se combinan para producir algo simplemente asombroso, como mil voces apenas audibles cantando todas al unísono.

Del mismo modo, un buen software requiere una devoción fanática por la belleza. Si miras dentro de un buen software, descubrirás que las partes que nadie debería ver también son hermosas. No digo que escriba un buen software, pero sé que, cuando se trata de código, me comporto de una manera que me haría candidato a medicamentos recetados si abordara la vida cotidiana de la misma manera. Me vuelve loco ver código mal sangrado o que utiliza nombres de variables feos.

Si un hacker fuera un simple implementador que convirtiera una especificación en código, podría simplemente abrirse paso a través de ella de un extremo a otro como quien cava una zanja. Pero si el hacker es un creador, tenemos que tener en cuenta la inspiración.

En el mundo de la piratería, al igual que en el de la pintura, el trabajo se produce en ciclos. A veces te entusiasma un nuevo proyecto y quieres trabajar dieciséis horas al día en él. Otras veces, nada parece interesante.

Para hacer un buen trabajo hay que tener en cuenta estos ciclos, porque se ven afectados por la forma en que reaccionamos ante ellos. Cuando se conduce un coche con transmisión manual en una pendiente, a veces hay que soltar el embrague para evitar que el coche se cale. Reducir el embrague también puede evitar que la ambición se estanque. Tanto en la pintura como en la piratería hay algunas tareas que son terriblemente ambiciosas y otras que son reconfortantemente rutinarias. Es una buena idea reservar algunas tareas fáciles para los momentos en los que, de lo contrario, el coche se estancaría.

En el mundo de la piratería, esto puede significar literalmente guardar errores. Me gusta la depuración: es la única ocasión en la que la piratería es tan sencilla como la gente cree. Tienes un problema totalmente limitado y todo lo que tienes que hacer es resolverlo. Se supone que tu programa debe hacer x, pero en cambio hace y. ¿Dónde falla? Sabes que al final vas a ganar. Es tan relajante como pintar una pared.

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

Hasta donde yo sé, cuando los pintores trabajaban juntos en un cuadro, nunca trabajaban en las mismas partes. Era habitual que el maestro pintara las figuras principales y que los ayudantes pintaran las demás y el fondo. Pero nunca había un pintor pintando sobre la obra de otro.

Creo que este es también el modelo adecuado para la colaboración en el ámbito del software. No hay que llevarlo demasiado lejos. Cuando un fragmento de código está siendo hackeado por tres o cuatro personas diferentes, de las cuales ninguna es realmente la dueña, acabará siendo como una sala común. Tenderá a parecer 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 diseñadas con tanto cuidado y, si es posible, tan articuladas como los lenguajes de programación.

Al igual que la pintura, la mayoría del software está pensado para un público humano. Por eso, los hackers, al igual que los pintores, deben tener empatía para hacer un trabajo realmente bueno. Hay que poder 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. En la práctica, eso siempre significaba 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, estaba equivocado. Resulta que mirar las cosas desde el punto de vista de los demás es prácticamente el secreto del éxito. No significa necesariamente ser abnegado. Todo lo contrario. Entender cómo ve las cosas otra persona no implica que uno vaya a actuar en su beneficio; en algunas situaciones (por ejemplo, en la guerra) uno quiere hacer exactamente lo contrario. [4]

La mayoría de los creadores crean cosas para un público humano, y para atraer a un público hay que entender lo que necesita. Casi todas las mejores pinturas son pinturas de personas, por ejemplo, porque las personas son lo que interesa a la gente.

La empatía es probablemente la diferencia más importante entre un buen hacker y uno excelente. Algunos hackers son bastante inteligentes, pero en lo que se refiere a la empatía son prácticamente solipsistas. A estas personas les resulta difícil diseñar un gran software [5], porque no pueden ver las cosas desde el punto de vista del usuario.

Una forma de saber si una persona es buena para la empatía es observarla mientras explica una pregunta técnica a alguien que no tenga conocimientos técnicos. Probablemente todos conozcamos a personas que, aunque inteligentes en otros aspectos, son ridículamente 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 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. Por lo tanto, para escribir un buen software hay que entender lo poco que entienden los usuarios. Se acercarán al software sin preparación y más vale que haga lo que ellos suponen 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 debería explicarse por sí mismo. Si pudiera lograr que la gente recordara una sola cita sobre programación, sería la que aparece al principio de Estructura e interpretación de programas informáticos.

Los programas deberían escribirse para que la gente los lea y sólo incidentalmente para que las máquinas los ejecuten.

Es necesario que sienta empatía no sólo por sus usuarios, sino también por sus lectores. Es por su propio bien, porque usted será uno de ellos. Muchos hackers han escrito un programa y, al volver a él seis meses después, se han dado cuenta de que no tenían ni idea de cómo funcionaba. Conozco a varias personas que han renunciado a Perl después de experiencias como ésta. [7]

La falta de empatía se asocia con la inteligencia, hasta el punto de que incluso se ha convertido en una moda en algunos lugares. Pero no creo que exista correlación alguna. Se puede obtener buenos resultados en matemáticas y ciencias naturales sin tener que aprender empatía, y la gente que trabaja en esos campos tiende a ser inteligente, por lo que ambas cualidades se han asociado. Pero también hay mucha gente tonta a la que se le da mal la empatía. Basta con escuchar a la gente que llama a los programas de entrevistas para hacer preguntas. Preguntan lo que sea de una forma tan indirecta que los presentadores a menudo tienen que reformular la pregunta.

Entonces, si hackear funciona como pintar y escribir, ¿es tan genial? Después de todo, solo tienes una vida. Bien podrías dedicarla a trabajar en algo grandioso.

Lamentablemente, la pregunta es difícil de responder. Siempre hay un gran desfase temporal en el prestigio. Es como la luz de una estrella lejana. La pintura tiene prestigio ahora debido a las grandes obras que la gente hizo hace quinientos años. En ese momento, nadie pensaba que esas pinturas fueran tan importantes como lo creemos hoy. A la gente de la época le habría parecido muy extraño que Federico da Montefeltro, el duque de Urbino, un día fuera conocido principalmente como el tipo con la nariz extraña en un cuadro de Piero della Francesca.

Si bien admito que hackear no parece tan genial como pintar ahora, deberíamos recordar que pintar en sí no parecía tan genial en sus días de gloria como lo parece ahora.

Lo que sí podemos decir con cierta seguridad es que estamos en la época de gloria de la piratería. En la mayoría de los campos, el gran trabajo se hace al principio. Las pinturas realizadas entre 1430 y 1500 siguen siendo insuperables. Shakespeare apareció justo cuando nacía el teatro profesional.

y llevó el medio tan lejos que todos los dramaturgos desde entonces han tenido que vivir a su sombra. Alberto Durero hizo lo mismo con el grabado y Jane Austen con la novela.

Vemos el mismo patrón una y otra vez: aparece un nuevo medio y la gente se entusiasma tanto con él que explora la mayoría de sus posibilidades en las primeras dos generaciones. El hacking parece estar en esta fase ahora.

En la época de Leonardo, la pintura no era tan genial como su obra contribuyó a que lo fuera. Lo genial que resulte hackear dependerá de lo que podamos hacer con este nuevo medio.

Notas

[1] El mayor daño que la fotografía ha causado a la pintura es quizás el hecho de que acabó con el mejor trabajo diario. La mayoría de los grandes pintores de la historia se ganaban la vida pintando retratos.

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

[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] He aquí un ejemplo de empatía aplicada. En Viaweb, si no pudiéramos decidir entre dos alternativas, nos preguntábamos qué odiarían más nuestros competidores. En un momento dado, un competidor añadió 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, le dieron mucha importancia 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 improvisamos nuestra propia versión esa tarde.

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

[6] Bueno, casi. Se excedieron un poco con la memoria RAM disponible, lo que provocó muchos inconvenientes al cambiar de disco, pero esto podría solucionarse en unos meses comprando una unidad de disco adicional.

[7] La manera de hacer que los programas sean fáciles de leer no es atiborrarlos de comentarios. Yo llevaría la cita de Abelson y Sussman un paso más allá. Los lenguajes de programación deberían estar diseñados para expresar algoritmos y sólo incidentalmente para decirles a las computadoras cómo ejecutarlos. Un buen lenguaje de programación debería ser mejor para explicar software que el inglés. Sólo deberías necesitar comentarios cuando hay algún tipo de chapuza sobre la que necesitas advertir a los lectores, de la misma manera que en una carretera sólo hay flechas en los tramos con curvas inesperadamente pronunciadas.

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