HACKERS Y PINTORES

May 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 informática, fui a la escuela de arte para estudiar pintura. A muchas personas les sorprendía que alguien interesado en computadoras también estuviera interesado en la pintura. Parecía que pensaban que hackear y pintar eran tipos de trabajo muy diferentes: que hackear era frío, preciso y metódico, y que pintar era la expresión frenética de algún impulso primitivo.

Ambas imágenes son incorrectas. Hackear y pintar tienen mucho en común. De hecho, de todos los diferentes tipos de personas que he conocido, los hackers y los pintores están entre los más parecidos.

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

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 un mezcolanza de áreas tenuemente relacionadas reunidas por un accidente de la historia, como Yugoslavia. En un extremo tienes personas que son realmente matemáticos, pero llaman a lo que hacen ciencia de la computación para poder obtener subvenciones de DARPA. En el medio tienes personas trabajando en algo como la historia natural de las computadoras: estudiando el comportamiento de algoritmos para enrutar datos a través de redes, por ejemplo. Y luego, en el otro extremo, tienes a los hackers, que están tratando de escribir software interesante, y para quienes las computadoras son solo un medio de expresión, como el concreto para los arquitectos o la pintura para los pintores. Es como si los matemáticos, físicos y 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 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 existe. Cae entre qué y cómo: los arquitectos deciden qué hacer, y los ingenieros averiguan cómo hacerlo.

Qué y cómo no deberían mantenerse demasiado separados. Estás pidiendo problemas si intentas decidir qué hacer sin entender cómo hacerlo. Pero hackear 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 implementarla.

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

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". Se podría argumentar que las personas en el medio están haciendo algo como una ciencia experimental. Pero las personas en cualquiera de los extremos, los hackers y los matemáticos, no están realmente haciendo ciencia.

A los matemáticos no parece preocuparles esto. Se ponen a trabajar felizmente probando teoremas como los otros matemáticos en el departamento de matemáticas, y probablemente pronto dejan 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 lo que están haciendo se llama ciencia, les hace sentir que deberían actuar científicamente. 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 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 sobre ello, y el artículo se convierte en un proxy para el logro representado por el software. Pero a menudo este desajuste causa problemas. Es fácil desviarse de construir cosas hermosas hacia construir 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 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 asegurarte de que estás explorando territorio virgen es reclamar un terreno que nadie quiere. Número dos, la investigación debe ser sustancial, y los sistemas torpes producen artículos más sustanciosos, porque puedes escribir sobre los obstáculos que tienes que superar para lograr que las cosas funcionen. Nada produce problemas sustanciosos como comenzar con las suposiciones incorrectas. La mayor parte de la IA es un ejemplo de esta regla; si asumes que el conocimiento puede ser representado 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 publicaciones? Por la misma razón que la "aptitud escolar" se mide mediante 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 de alguna manera.

Medir lo que los hackers están tratando de 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 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 los amigos influyentes del escritor mueran, y luego a que todos sus seguidores mueren.

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

Hay cosas peores que hacer que las personas malinterpreten tu trabajo. Un peligro peor es que tú mismo malinterpretes tu trabajo. Los campos relacionados son donde vas a buscar ideas. Si te encuentras en el departamento de ciencia de la computación, hay una tentación natural de creer, por ejemplo, que hackear es la versión aplicada de lo que la ciencia de la computación teórica es la teoría de. 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 muy negligente de mi parte haber olvidado todas esas cosas dentro de las tres semanas posteriores al 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. 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, 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 encontrado 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 acercarse a una computadora. Descubrí que no programaba de esta 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 soltar código que estaba irremediablemente roto, y gradualmente darle forma. Me enseñaron que depurar era una especie de pase final donde capturabas errores tipográficos y descuidos. De la manera en que trabajaba, parecía que programar consistía en depurar.

Durante mucho tiempo me sentí mal por esto, así como una vez me sentí mal por no sostener mi lápiz de la manera en que me enseñaron en la escuela primaria. Si tan 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: bocetar. Hasta donde puedo decir, la manera en que me enseñaron a programar en la universidad estaba completamente equivocada. Deberías idear programas mientras los escribes, así como lo hacen los escritores, pintores y arquitectos.

Darse cuenta de esto tiene implicaciones reales para el diseño de software. Significa que un lenguaje de programación debería, 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 una pluma. La tipificación estática sería una buena idea si las personas realmente escribieran programas de la manera en que me enseñaron en la universidad. Pero así no es como escriben programas los hackers que conozco. Necesitamos un lenguaje que nos permita garabatear, difuminar y manchar, no un lenguaje en el que tengas que sentarte con una taza de tipos equilibrada en tu rodilla y hacer una conversación educada con una estricta tía anciana que es el compilador.

Mientras estamos en el tema de la tipificación estática, identificarse con los creadores nos salvará de otro problema que afecta a las ciencias: la envidia matemática. 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 se vea lo más matemático posible. En un campo como la física, esto probablemente no causa mucho daño, pero cuanto más te alejas de las ciencias naturales, más problema se convierte.

Una página de fórmulas simplemente se ve tan impresionante. (Sugerencia: para mayor impresión, usa variables griegas). Y así hay una gran tentación de trabajar en problemas que puedes 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. Se sienten como si estuvieran haciendo algo completamente no relacionado. 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 su lugar 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 hace poco. 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 hackear significaba para ellos era implementar software, no diseñarlo. Los programadores eran vistos como técnicos que traducían las visiones (si esa es la palabra) de los gerentes de producto en código.

Este 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 realmente diseñar software, y es difícil para las personas que dirigen una empresa identificar a estos. Así que en lugar de confiar el futuro del software a un brillante hacker, la mayoría de las empresas organizan las cosas para 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 así como los bajos. Este no es un problema para las grandes empresas, porque no ganan haciendo grandes productos. Las grandes empresas ganan al ser menos malas 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, 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 mejor procesador de texto que Microsoft Word, por ejemplo, pero Microsoft, dentro del castillo de su monopolio de sistemas operativos, probablemente ni siquiera notaría si lo hicieras.

El lugar para librar guerras de diseño es en nuevos mercados, donde nadie ha logrado establecer fortificaciones. Ahí es donde puedes ganar mucho al adoptar un enfoque audaz hacia el diseño, y tener a las mismas personas tanto diseñando como implementando el producto. Microsoft lo hizo 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 construir un gran software es comenzar 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 consideraba que tenía suerte si podía hackear un cuarto 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 la junta para que me rellenasen algunas caries. Recuerdo estar sentado en la silla del dentista, esperando el taladro, y sintiendo que estaba 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 fue uno, de hecho, pero nadie pagará por lenguajes de programación ahora. Si quieres ganar dinero, tiendes a ser forzado a trabajar en problemas que son demasiado desagradables para que alguien los resuelva gratis.

Todos los creadores enfrentan este problema. Los precios son determinados por la oferta y la demanda, y simplemente no hay tanta demanda por cosas que son divertidas de trabajar como por cosas que resuelven los problemas mundanos de los clientes individuales. Actuar en obras de teatro fuera de Broadway simplemente no paga tan bien como vestirse de gorila en el stand de alguien en una feria comercial. Escribir novelas no paga tan bien como escribir copias publicitarias 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 diario. 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 diarios al principio de sus carreras. Los pintores y escritores lo hacen notoriamente. Si tienes suerte, puedes conseguir un trabajo diario 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 igualmente ser capaz de conseguir un trabajo diario usándolo. [1]

Cuando digo que la respuesta es que los hackers tengan trabajos diarios, y trabajen en software hermoso por su cuenta, no estoy proponiendo esto como una nueva idea. Esto es de lo que se trata el hackeo 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 otros creadores.

Me parece sorprendente 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 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 lo ames, y si amas hackear, inevitablemente estarás trabajando en proyectos propios. [2]

Porque 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 hackear?

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 hackear. 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 clases universitarias, aprendes a hackear principalmente hackeando. [3]

Debido a 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 de ello 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 parecen hacerlo también. Quizás sería bueno que los hackers actuaran más como los pintores, y comenzaran regularmente desde cero, en lugar de continuar trabajando durante años en un proyecto, y tratar de 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 hackear 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 están tratando de reproducir el trabajo que alguien más ya ha hecho por ellos. Eventualmente, llegan al punto en el 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 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 te obliga a mirar de cerca la forma en que se hace una pintura.

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

Los hackers, igualmente, 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 aprender a programar. Cuando aprendí a programar, teníamos que depender principalmente de ejemplos en libros. El único gran bloque de código disponible entonces era Unix, pero incluso esto no era código abierto. La mayoría de las personas que leyeron el código lo leyeron 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 las pinturas se crean mediante un refinamiento gradual. Las pinturas generalmente comienzan con un boceto. Gradualmente se van llenando los detalles. Pero no es meramente un proceso de llenado. A veces los planes originales resultan ser erróneos. Incontables pinturas, cuando las miras en 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 hackear debería funcionar de esta manera también. Es poco realista esperar que las especificaciones para un programa sean perfectas. Estás mejor si admites esto desde el principio, y escribes programas de una manera que permita que las especificaciones cambien sobre la marcha.

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

Supongo que todos saben ya sobre el peligro de la optimización prematura. Creo que deberíamos preocuparnos tanto 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 cambiar de opinión. La tipificación dinámica es una ventaja aquí porque no tienes que comprometerte con representaciones de datos específicas desde el principio. Pero la clave para 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 como 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 que poner en el fondo para enmarcar su cabeza. Nadie mirará tan de cerca.

No Leonardo. Cuánto trabajó en parte de una pintura no dependía en absoluto de cuán de cerca esperaba que alguien la mirara. Era como Michael Jordan. Implacable.

La implacabilidad gana porque, en conjunto, los detalles no vistos se vuelven visibles. Cuando las personas pasan junto al retrato de Ginevra de Benci, su atención a menudo se ve inmediatamente atrapada por él, incluso antes de mirar la etiqueta y notar que dice Leonardo da Vinci. Todos esos detalles no vistos se combinan para producir algo que es simplemente impresionante, como mil voces apenas audibles cantando todas a la vez.

El gran software, igualmente, requiere una devoción fanática a la belleza. Si miras dentro de un buen software, encuentras que las partes que nunca se supone que se vean también son hermosas. No estoy afirmando que escriba 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 abordara la vida cotidiana de la misma manera. Me vuelve loco ver código que está mal indentado, o que usa nombres de variables feas.

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

En hackear, como en la pintura, el trabajo viene en ciclos. A veces te entusiasmas 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 están afectados por cómo reaccionas a ellos. Cuando estás conduciendo un automóvil con transmisión manual en una colina, a veces tienes que soltar el embrague para evitar que se apague. Soltar también puede prevenir que la ambición se detenga. En la pintura y en el hackeo hay algunas tareas que son aterradoramente ambiciosas, y otras que son consoladoramente rutinarias. Es una buena idea guardar algunas tareas fáciles para momentos en los que de otro modo te detendrías.

En hackear, esto puede significar literalmente guardar errores. Me gusta depurar: es la única vez que hackear es tan directo como la gente piensa que es. Tienes un problema totalmente restringido, y todo lo que tienes que hacer es resolverlo. Tu programa se supone que debe hacer x. En cambio, 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 el trabajo de múltiples manos, aunque puede haber solo un nombre en la pared junto a él en el museo. Leonardo fue un aprendiz en el taller de Verrocchio y pintó uno de los ángeles en su Bautismo de Cristo. Este tipo de cosa era la regla, no la excepción. Michelangelo fue considerado especialmente dedicado por insistir en pintar todas las figuras en el techo de la Capilla Sixtina él mismo.

Hasta donde 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 un fragmento de código está siendo hackeado por tres o cuatro personas diferentes, ninguna de las cuales realmente lo posee, terminará siendo como un salón común. Tendrá tendencia a sentirse desolado y abandonado, y acumulará desechos. La forma correcta de colaborar, creo, es dividir los proyectos en módulos bien 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.

Como la pintura, la mayoría del software está destinado a una audiencia humana. Y así los hackers, como los pintores, deben tener empatía para hacer un trabajo realmente grandioso. 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 alguien más quería, en lugar de lo que yo quería. Esto, por supuesto, le dio a la empatía un mal nombre, y me propuse no cultivarla.

Vaya, estaba equivocado. Resulta que mirar las cosas desde el punto de vista de otras personas es prácticamente el secreto del éxito. No significa necesariamente ser autocrítico. Lejos de eso. Entender cómo alguien más ve las cosas 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 grandes pinturas son pinturas de personas, por ejemplo, porque las personas son lo que a la gente le interesa.

La empatía es probablemente la diferencia más importante entre un buen hacker y uno grandioso. Algunos hackers son bastante inteligentes, pero cuando se trata de empatía son prácticamente solipsistas. Es difícil para tales personas diseñar 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 observar cómo explican una pregunta técnica a alguien sin un fondo técnico. Probablemente todos conocemos personas que, aunque son inteligentes, 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 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 no sabe qué son estas cosas tampoco.

Parte de lo que el software tiene que hacer es explicarse a sí mismo. Así que para escribir buen software tienes que entender cuán poco entienden los usuarios. Van a acercarse al software sin preparación, y más les vale que haga lo que adivinan 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 a sí mismo. Si pudiera hacer que la gente recordara solo una cita sobre programación, sería la que está al principio de Estructura e Interpretación de Programas de Computadora.

Los programas deben escribirse para que las personas los lean, 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 algo de moda por ello en algunos lugares. Pero no creo que haya ninguna correlación. Puedes hacerlo bien en matemáticas y ciencias naturales sin tener que aprender empatía, y las personas en estos campos tienden a ser inteligentes, así que las dos cualidades han llegado a estar asociadas. Pero hay muchas personas tontas que también son malas en empatía. Solo escucha a las personas que llaman con preguntas en programas de entrevistas. Preguntan lo que sea que estén preguntando de una manera tan indirecta que los anfitriones a menudo tienen que reformular la pregunta para ellos.

Entonces, si hackear funciona como la pintura y la escritura, ¿es tan genial? Después de todo, solo tienes una vida. Podrías gastar tu tiempo 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 pensaba que estas pinturas eran tan importantes como lo son hoy. Habría parecido muy extraño a las personas de la época que Federico da Montefeltro, el Duque de Urbino, sería conocido principalmente como el tipo con la nariz extraña en una pintura de Piero della Francesca.

Así que aunque admito que hackear no parece tan genial como pintar ahora, deberíamos recordar que la pintura misma no parecía tan genial en sus días de gloria como lo parece ahora.

Lo que podemos decir con cierta confianza es que estos son los días de gloria del hackeo. En la mayoría de los campos, el gran trabajo se realiza al principio. Las pinturas hechas entre 1430 y 1500 siguen siendo insuperadas. Shakespeare apareció justo cuando el teatro profesional estaba naciendo,

y llevó el medio tan lejos que cada dramaturgo desde entonces ha tenido que vivir a la sombra de él. 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 las personas están tan emocionadas por él que exploran la mayoría de sus posibilidades en las primeras generaciones. El hackeo 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 resulta ser el hackeo dependerá de lo que podamos hacer con este nuevo medio.

Notas

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

[2] Me han dicho que Microsoft desanima a los empleados de contribuir 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 efecto principal de esta política puede ser asegurar 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 o 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é es lo que más odiarían nuestros competidores? En un momento, un competidor agregó una característica a su software que era básicamente inútil, pero dado que era una de las pocas que tenían que nosotros no, hicieron mucho de ello en la prensa comercial. Podríamos haber intentado explicar que la característica era inútil, pero decidimos que molestaría más a nuestro competidor si simplemente la implementábamos nosotros mismos, así que esa tarde hackeamos nuestra propia versión.

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

[6] Bueno, casi. Excedieron un poco la RAM disponible, causando un inconveniente intercambio de disco, pero esto podría solucionarse dentro de unos meses comprando una unidad de 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 estar diseñados para expresar algoritmos, y solo incidentalmente para decir 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 temporal de la que necesites advertir a los lectores, así como en una carretera solo hay flechas en 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.