Hackers Y Pintores

Traducción del ensayo original
Paul Graham
Autor

Traductor: Leonardo BoshellHistorial de revisiones
Revisión 1.0 2004-03-22 lb
Traducción original.
Tabla de contenidos
Introducción
Sobre la traducción
Hackers Y Pintores
Introducción

Mayo 2003

Este ensayo se deriva de una charla ofrecida como invitado en Harvard, la cual a su vez incorporaba elementos de una presentación anterior en Northeastern.
Sobre la traducción

Este documento fue traducido a partir del original en Inglés, tomado de http://www.paulgraham.com/hp.html. Los comentarios y correcciones sobre esta traducción son bienvenidos --LB <p@kapcoweb.com>.

Copyright del texto original © 2003 Paul Graham.
Sobre los términos hacker, hackear y demás

En el presente ensayo, el término hacker hace referencia al significado original que adquirió ésta palabra alrededor de los años 60s en el laboratorio de inteligencia artifical del MIT. Puede conocer más sobre su significado consultando el popular Jargon File.

Por su parte, el término hackear, usado (naturalmente) como verbo en esta traducción, se presenta en reemplazo del término "hacking", originalmente usado por el autor para referirse a la acción de producir hacks, es decir, aquello que produce un hacker. En la actualidad, si se realiza una búsqueda web sobre éste término, resulta claro que en la red abundan los sitios que hacen uso de ésta palabra en un sentido diferente y por lo demás irrelevante para este ensayo. Sin embargo, cabe anotar que es posible encontrar ya diccionarios en línea que mencionan "hackear" como el término en Castellano del verbo "to hack".
Hackers Y Pintores

Cuando terminé mi carrera universitaria en ciencia de computación, fui a la escuela de arte a estudiar pintura. Muchas personas parecían sorprendidas de que alguien interesado en computadoras también se interesara en la pintura. Parecían pensar que hackear y pintar eran tipos muy diferentes de trabajo --que hackear era frío, preciso y metódico, y que pintar era la expresión frenética de alguna necesidad primaria.

Ambas imágenes están equivocadas. 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 se encuentran entre los más similares.

Lo que los hackers y los pintores tienen en común es que ambos son creadores. Junto con compositores, arquitectos y escritores, lo que los hackers y los pintores tratan de hacer es crear cosas buenas. No hacen investigación como tal, aunque si en medio de sus intentos por crear cosas buenas descubren alguna nueva técnica, pues tanto mejor.

Nunca me ha gustado el término "ciencia de computación". La razón principal por la que no me gusta es que en realidad no existe tal cosa. Ciencia de computación es una mezcla arbitraria de áreas ligeramente relacionadas, reunidas por un accidente de la historia, como Yugoslavia. Por un lado tiene a personas que son realmente matemáticos, pero que llaman a lo que hacen ciencia de computación de modo que puedan recibir becas en la DARPA. En el medio tiene a personas que trabajan 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 tiene a los hackers, quienes intentan escribir software interesante, y para quienes las computadores son simplemente un medio de expresión, como el concreto lo es para los arquitectos, o la pintura para los pintores. Es como si los matemáticos, físicos y arquitectos, todos tuvieran que estar en el mismo departamento.

En ocasiones lo que los hackers producen es llamado "ingeniería de software", pero éste término es asimismo inexacto. Los buenos diseñadores de software no son más ingenieros que los arquitectos. El límite entre la arquitectura y la ingeniería no está definido con claridad, pero está allí. Se ubica entre el qué y el cómo: los arquitectos deciden qué hacer, y los ingenieros encuentran la forma de hacerlo.

El qué y el cómo no deberían mantenerse muy separados. Se está buscando problemas si se intenta decidir qué hacer sin entender cómo hacerlo. Pero, ciertamente, hackear puede ser más que tan solo decidir cómo implementar alguna especificación. En el mejor de los casos, consiste en crear la especificación --aunque resulte que la mejor forma de hacerlo es encargándose de la implementación.

Quizás algún día la "ciencia de computación", como Yugoslavia, será separada en sus partes que la componen. Eso sería algo positivo. Especialmente si eso significara la independencia de mi tierra nativa, hackear.

Agrupar todos estos tipos diferentes de trabajo en un sólo departamento puede ser conveniente desde el punto de vista administrativo, pero es confuso en un nivel intelectual. Esa es la otra razón por la que no me gusta el nombre "ciencia de computación". Puede decirse que las personas ubicadas en el medio hacen algo como una ciencia experimental. Pero las personas en cada uno de los extremos, los hackers y los matemáticos, no están haciendo ciencia realmente.

Los matemáticos no se ven afectados por esto. Ellos se dedican felizmente a trabajar en demostraciones de teoremas como los demás matemáticos en el departamento de matemáticas, y es probable que no tarden en pasar por alto que el edificio en el que trabajan dice "cienca de computación" en el exterior. Pero para los hackers esta etiqueta es un problema. Si lo que hacen es llamado ciencia, esto les hace sentir que debían estar actuando de forma científica. Así que en lugar de hacer lo que realmente quieren hacer, que es diseñar software hermoso, los hackers en las universidades y laboratorios de investigación sienten que deben estar escribiendo artículos de investigación.

En el mejor de los casos, los artículos son solo una formalidad. Los hackers escriben software interesante, y luego escriben un artículo sobre él, y el documento se convierte en una máscara del logro representado por el software. Pero con frecuencia este desajuste causa problemas. Es fácil alejarse de la construcción de cosas bellas hacia la construcción de cosas feas que constituyen objetos más apropiados como material de un artículo investigativo.

Desafortunadamente, las cosas bellas no siempre constituyen los mejores temas para escribir ensayos. En primer lugar, la investigación debe ser original --y, como bien lo sabe quien ha escrito una disertación de doctorado, la forma de asegurarse de que se está explorando territorio virgen es echar mano de un pedazo de tierra que nadie quiere. Número dos, la investigación debe ser sustancial --y los sistemas enredados llevan a artículos más sustanciosos, ya que puede escribir sobre los obstáculos que tiene que sobrepasar para conseguir aquello que busca. Nada conduce mejor a problemas sustanciosos como arrancar con las premisas equivocadas. La mayoría del trabajo en inteligencia artifical es un ejemplo de esta regla; si asume que el conocimiento puede ser representado como una lista de expresiones lógicas de predicado cuyos argumentos representan conceptos abstractos, usted tendrá que escribir bastantes artículos sobre cómo hacer que esto funcione. Como solía decir Ricky Ricardo, "Lucy, tienes bastante qué explicar".

La forma de crear algo hermoso es, con frecuencia, hacer sutiles correcciones a algo que ya existe, o combinar ideas existentes en una manera ligeramente nueva. Este tipo de trabajo es difícil de plasmar en un artículo investigativo.

Así que, ¿por qué continúan juzgando las universidades y laboratorios de investigación a los hackers por sus publicaciones? Por la misma razón que la "aptitud escolástica" es medida por medio de pruebas simplistas estandarizadas, o la productividad de los programadores se mide en líneas de código. Aquellas pruebas son fáciles de aplicar, y no hay nada más tentador que una prueba sencilla que medio trabaje.

Medir lo que los hackers están tratando de hacer realmente, diseñar software hermoso, sería mucho más difícil. Necesita un buen sentido del diseño para juzgar un buen diseño. Y no hay una correlación, excepto quizás por una negativa, entre la habilidad de las personas para reconocer buenos diseños y su propia confianza de que pueden hacerlo.

La única prueba externa es el tiempo. A lo largo del tiempo, las cosas bellas tienden a prosperar, y los cosas feas tienden a ser descartadas. Desafortunadamente, las cantidades de tiempo involucradas pueden ser mayores que el periodo de vidas humanas. Samuel Johnson dijo que tomaba cien años para que la reputación de un escritor convergiera. Es necesario esperar a que las amistades con influencia del escritor mueran, y luego a que todos sus seguidores lo hagan también.

Pienso que los hackers tienen que resignarse a tener un considerable componente aleatorio en sus reputaciones. En este sentido, ellos no son diferentes de otros creadores. De hecho, tienen suerte en comparación. La influencia de la moda no es, y por mucho, tan grande en la labor de hackear como lo es en la pintura.

Hay cosas peores que contar con que la gente malinterprete su trabajo. Un peligro peor es que usted mismo malinterprete su trabajo. Los campos que se relacionan es en donde se echa un vistazo en busca de ideas. Si usted se encuentra en el departamento de ciencia de computación, existe una tentación natural a creer, por ejemplo, que hackear es la versión aplicada de aquella teoría que provee la ciencia teórica computacional. Todo el tiempo que estuve en pre-grado, tuve una incómoda sensación en la nuca que me decía que debía saber más teoría, y que era muy descuidado de mi parte el haber olvidado todo eso en menos de tres semanas después del examen final.

Ahora entiendo que estaba equivocado. Los hackers necesitan entender la teoría de computación tanto como los pintores necesitan entender sobre química de pinturas. Usted necesita saber cómo calcular complejidad de tiempo y espacio, y sobre la completitud de Turing. También puede que quiera recordar al menos el concepto de máquina de estados, en caso de que tenga que escribir un analizador sintáctio o una librería de expresiones regulares. Los pintores, de hecho, tienen que recordar bastante más sobre la química de pintura que eso.

He encontrado que las mejores fuentes do ideas no son los otros campos que incluyen la palabra "computación" 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 computacional.

Por ejemplo, a mi me enseñaron en la universidad que uno debería modelar un programa completamente en papel antes de acercarse siquiera a una computadora. Encontré que yo no programaba de esa forma. Encontré que me gustaba programar sentado frente a una computadora, no un trozo de papel. Peor aun, en lugar de escribir pacientemente un programa completo asegurándome de que estuviera correcto, yo tendía a simplemente lanzar código que estaba irremediablemente malformado, y gradualmente darle forma. La depuración, me fue inculcado, era une especie de paso final en donde se atrapaban errores de sintaxis y descuidos. Dada la forma en la que yo trabajaba, parecía que la programación consistía en depurar.

Por bastante tiempo me sentí mal debido a esto, así como alguna vez me sentí mal por que no sostenía mi lápiz en la forma que me enseñaron en escuela primaria. Si tan solo hubiera echado un vistazo a los otros creadores, a los pintores o arquitectos, hubiera sabido que había un nombre para lo que yo estaba haciendo: crear bosquejos. Por lo que a mí concierne, la forma en que me enseñaron a programar en la universidad estaba completamente equivocada. Los programas deberían ser modelados en la medida en que van siendo escritos, del mismo modo que actúan pintores y arquitectos.

Caer en cuenta de esto tiene implicaciones reales para el diseño de software. Quiere decir que un lenguaje de programación debería, sobre todas los cosas, ser maleable. Un lenguaje de programación está para pensar sobre los programas, no para expresar programas sobre los que ya ha pensado. Debería ser un lápiz, no un lapicero. El tipado estático sería una idea aceptable si las personas realmente escribieran programas en la forma que me enseñaron en la universidad. Pero esa no es la forma en que escriben programas los hackers que conozco. Necesitamos un lenguaje que nos permita garabatear, manchar y untar, no un lenguaje que le oblige a sentarse con una taza de tipos balanceada en su rodilla y tener una conversación educada con la señora mayor que es el estricto compilador.

Mientras estamos en el tema del tipado estático, identificarse con los creadores nos protegerá de otro problema que aflige a las ciencias: la envidia matemática. Todos en las ciencias creen secretamente que los matemáticos son más inteligentes de lo que realmente son. Pienso que los matemáticos también lo creen. En cualquier medida, el resultado es que los científicos tienden a hacer que su trabajo luzca tan matemático como sea posible. En un campo como la física, esto probablemente no hace mucho daño, pero entre más se aleje de las ciencias naturales, mayor es el problema.

Una página de fórmulas luce bastante impresionante. (Consejo: para mayor efecto, use variables Griegas). Así que hay una gran tentación a trabajar en problemas que puedan ser manejados formalmente, en lugar de problemas que sean, 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 los pintores no sufren de envidia matemática. Ellos se sienten como si estuvieran haciendo algo que no se relaciona en absoluto. Lo mismo ocurre con los hackers, creo yo.

Si las universidades y laboratorios de investigación previenen a los hackers de que hagan el tipo de trabajo que quieren hacer, quizás el lugar de éstos se encuentra en las compañías. Desafortunadamente, la mayoría de compañías no permiten que los hackers hagan lo que quieren hacer tampoco. Las universidades y laboratorios de investigación obligan a los hackers a ser científicos, y las compañías los obligan a ser ingenieros.

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

Este parece ser el plan predeterminado en las grandes compañías. Ellos lo hacen porque reduce la desviación estándar del resultado. Solo un pequeño porcentaje de hackers pueden realmente diseñar software, y es difícil para quienes manejan una compañía señalar a aquellos. Así que en lugar de confiar el futuro del software en un hacker brillante, la mayoría de compañías arreglan las cosas de modo que sea diseñado por un comité, y los hackers se limitan a implementar el diseño.

Si desea hacer dinero en algún momento, recuerde esto, ya que ésta es una de las razones por las que las iniciativas individuales triunfan. Las grandes compañías quieren reducir la desviación estándar de los resultados del diseño, ya que quieren evitar desastres. Pero cuando se reducen las oscilaciones, se pierden los picos altos al igual que los bajos. Esto no es un problema para las grandes compañías, ya que éstas no ganan al hacer productos grandiosos. Las grandes compañías ganan al fracasar menos que las otras compañías grandes.

De modo que si puede encontrar un modo de verse involucrado en una guerra de diseños con una compañía lo suficientemente grande como para que su software sea diseñado por adiminstradores de productos, ellos nunca serán capaces de darle la talla. Sin embargo, estas oportunidades no son fáciles de encontrar. Es difícil involucrarse en una guerra de diseño con una compañía grande, tal como es difícil retar a un oponente a un combate mano a mano al interior de un castillo. Sería bastante fácil escribir un mejor procesador de palabras que Microsoft Word, por ejemplo, pero Microsoft, al interior de su castillo del monopolio en sistemas operativos, probablemente ni lo note siquiera.

El lugar para pelear guerras de diseño es en los nuevos mercados, en donde nadie ha logrado establecer fortalezas. Allí es donde usted puede ganar considerablemente al tomar un enfoque valiente de diseño, y tener a las mismas personas que diseñen e implementen el producto. El mismo Microsoft hizo esto en sus comienzos. Asimismo Apple. Y Hewlett-Packard. Sospecho que prácticamente toda iniciativa exitosa lo ha hecho.

Así que una forma de escribir software genial es arrancar con su iniciativa propia. Aunque, hay dos problemas con esto. Uno es que en una iniciativa usted tiene que hacer mucho más que escribir software. En Viaweb me consideraba afortunado si tenía la oportunidad de hackear una cuarta parte del tiempo. Y las cosas que tenía que hacer en las otras tres cuartas partes oscilaban entre lo tedioso a lo terrorífico. Tengo una forma de medirlo, ya que una vez tuve que abandonar una junta de consejo para hacerme poner unas placas. Recuerdo sentarme en la silla del dentista, esperando por la fresa, y sentir como si estuviera en vacaciones.

El otro problema con las iniciativas individuales es que no hay una intersección muy grande entre el tipo de software que hace dinero y aquel 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 el día de hoy. Si quiere hacer dinero, sufrirá una tendencia a verse obligado a trabajar en problemas que son demasiado sucios para que alguien los resuelva gratis.

Todos los creadores se enfrentan con este problema. Los precios están determinados por la oferta y la demanda, y simplemente no hay tanta demanda por las cosas que son divertidas para trabajar como la hay para cosas que resuelven problemas mundanos de clientes individuales. Actuar en obras por fuera de Broadway no paga tan bien como vestir un traje de gorila en el cubículo de alguien en una feria de exposición. Escribir novelas no paga tan bien como escribir sentencias publicitarias que irán sobre bolsas de basura. Y hackear lenguajes de programación no paga tan bien como encontrar una forma de conectar la base de datos histórica de una compañía con su servidor web.

Creo que la solución a este problema, en el caso del software, es un concepto conocido por casi todos los creadores: el trabajo de día. Esta frase comenzó con los músicos, quienes actúan de noche. De forma más general, hace referencia al fenómeno presente cuando se tiene un trabajo que se hace por dinero, y otro por amor.

Prácticamente todos los creadores tienen trabajos de día en las etapas tempranas de sus carreras. Entre ellos, quizás el caso más notable sea el de pintores y escritores. Si se tiene suerte, es posible conseguir un trabajo de día que se relacione cercanamente con su trabajo real. Los músicos con frecuencia recurren a trabajos con almacenes de música. Un hacker que trabaje en algún lenguaje de programación o sistema operativo puede, de forma semejante, ser capaz de conseguir un trabajo de día usando su herramienta. [1]

Cuando digo que la respuesta para los hackers consiste en tener trabajos de día, y trabajar en software hermoso de forma lateral, no lo propongo como una idea nueva. Esa es la idea detrás de la labor de hackear código-abierto. Lo que digo es que el código-abierto es probablemente el modelo correcto, ya que ha sido confirmado independientemente por todos los otros creadores.

Me parece sorprendente que cualquier encargado de personal se sienta renuente a permitir que los hackers trabajen en proyectos de código-abierto. En Viaweb, hubiéramos estado renuentes a contratar a alguien que no lo hiciera. Cuando entrevistábamos programadores, lo que más nos importaba era el tipo de software que escribían en su tiempo libre. Es imposible hacer algo realmente bien a menos que usted le tenga amor, y si ama hackear, inevitablemente estará trabajando en sus propios proyectos. [2]

Ya que los hackers son creadores en lugar de científicos, el lugar apropiado para buscar metáforas no es en las ciencias, sino entre otras clases de creadores. ¿Qué otra cosa nos puede enseñar la pintura sobre hackear?

Una cosa que podemos aprender, o por lo menos confirmar, del ejemplo de la pintura es cómo aprender a hackear. La pintura se aprende principalmente al pintar. Es lo mismo en el caso de hackear. La mayoría de hackers no aprenden a hackear tomando cursos universitaros en programación. Aprenden a hackear por medio de la escritura de sus propios programas cuando tienen trece años. Incluso en clases universitarias, se aprende a hackear principalmente haciéndolo. [3]

Dado que los pintores dejan un rastro de trabajo tras ellos, es posible apreciar su proceso de aprendizaje mediante la práctica. Si se observa el trabajo de un pintor en orden cronológico, se encuentra que cada pintura ha sido construida sobre cosas que fueron aprendidas en pinturas previas. Cuando hay algo en una pintura que trabaja muy bien, usualmente puede encontrar su primera versión en una forma más modesta en alguna pintura anterior.

Pienso que la mayoría de creadores trabajan en esta forma. Los escritores y los arquitectos parecen hacerlo. Quizás sea bueno para los hackers actuar más como los pintores, y empezar desde ceros con cierta regularidad, en lugar de continuar trabajando por años en un proyecto, y tratando de incorporar todas sus ideas recientes como revisiones.

El hecho de que los hackers aprenden su oficio mediante la práctica es otro signo de qué tan diferente es hackear de la actividad en las ciencias. Los científicos no aprenden ciencia practicándola, sino mediante laboratorios y conjuntos de problemas. Los científicos comienzan realizando un trabajo que es perfecto, en el sentido en que ellos tan solo intentan reproducir el trabajo que alguien más ha hecho por ellos. Eventualmente, ellos llegan al punto en el que pueden crear trabajo original. Mientras que, por su parte, los hackers, desde el comienzo, están haciendo trabajo original; es solo que es muy malo. Así que los hackers parten siendo originales, y se vuelven buenos, y los científicos comienzan siendo buenos, y se vuelven originales.

La otra forma en que aprenden los creadores es por medio de ejemplos. Para un pintor, un museo es una librería de referencia de técnicas. Por cientos de años ha sido parte de la educación de los pintores el copiar de trabajos de grandes maestros, ya que la copia le obliga a mirar detenidamente el modo en que se crea una pintura.

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

Los hackers, de forma semejante, pueden aprenden a programar a partir del estudio de buenos programas --no solamente de lo que hacen, sino del código fuente también. Uno de los beneficios menos publicitados del movimiento de código-abierto es que ha hecho más fácil el aprender a programar. Cuando yo aprendí a programar, teníamos que depender más que todo de ejemplos tomados de libros. El único trozo significativo de código disponible entonces era Unix, pero incluso éste no era código abierto. La mayoría de personas que leyeron el código fuente lo hicieron en copias ilícitas del libro de John Lions, del que, aunque escrito en 1977, no fue permitida su publicación hasta 1996.

Otro ejemplo que podemos tomar de la pintura es la forma en que las pinturas son creadas por la refinación gradual. Las pinturas usualmente comienzan con un esbozo. Gradualmente, los detalles son puestos en su lugar. Pero no se trata simplemente de un proceso de llenar detalles. Algunas veces los planes originales resultan ser equivocados. Innumerables pinturas, cuando se les ve bajo rayos-x, resultan tener un borde que ha sido movido, o elementos faciales que han sido reajustados.

Este es un caso en donde podemos aprender de la pintura. Pienso que hackear debería trabajar de esta forma también. Es poco realista esperar que las especificaciones de un programa sean perfectas. Se está en una mejor posición si se admite esto de entrada, y se escriben los programas en una forma que permita que las especificaciones cambien en el camino.

(La estructura de compañías grandes hace que esto les resulte difícil, así que este es otro lugar en donde las iniciativas tienen una ventaja.)

Podría esperarse que todos conozcan hoy en día sobre el peligro de la optimización prematura. Pienso que deberíamos preocuparnos otro tanto por el diseño prematuro --decidir muy temprano lo que debería hacer un programa.

Las herramientas apropiadas nos pueden ayudar a evitar este peligro. Un buen lenguaje de programación debería, como la pintura de aceite, facilitarle los cambios de opinión. El tipado dinámico representa una gran ventaja en este sentido, ya que no tiene que comprometerse con representaciones específicas de datos desde el comienzo. Pero la clave para la flexibilidad, pienso yo, es hacer que el lenguaje sea bastante abstracto. El programa más fácil de modificar es aquel que es bastante corto.

Suena como una paradoja, pero un gran pintor 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, él colocó un arbusto de enebro tras su cabeza. En él, pintó cuidadosamente cada hoja individual. Muchos pintores hubieran pensado, esto es solo algo para colocar en el fondo y enmarcar su cabeza. Nadie se fijará detenidamente en esto.

No Leonardo. Qué tan duro trabajaba en una parte de una pintura no dependía en absoluto de qué tanto esperaba que la gente se fijara en esa parte. Era como Michael Jordan. Implacable.

La implacabilidad tiene éxito ya que, en conjunto, los detalles sutiles se hacen visibles. Cuando las personas pasan al lado del retrato de Ginevra de Benci, su atención es capturada con frecuencia por él, incluso antes de que se fijen en la etiqueta y noten que dice Leonardo da Vinci. Todos esos detalles sutiles se combinan para producir algo que es simplemente impactante, como mil voces suaves cantando todas en armonía.

El software grandioso, de forma similar, requiere una devoción fanática por la belleza. Si se mira al interior de buen software, se encuentra que las partes en las que nadie debería fijarse son hermosas también. No afirmo que yo escriba software grandioso, pero se que cuando de código se trata, me comporto de una forma que me haría apto para medicación de drogas si asumiera la vida diaria en la misma manera. Me enloquece ver código que se encuentre con la sangría equivocada, o que use nombres horribles de variables.

Si un hacker fuera tan solo alguien que implementa, que convierte una especificación en código, entonces aquél podría hacerse camino de un extremo al otro, como alguien que cava un foso. Pero si el hacker es un creador, tenemos que tener en cuenta la inspiración.

En la labor del hacker, como en la pintura, el trabajo viene en ciclos. Algunas veces usted se emociona con algún proyecto nuevo y quiere trabajar en él diesciseis horas al día. Otras veces nada parece interesante.

Para hacer un buen trabajo hay que tener en cuenta estos ciclos, ya que ellos se ven afectados por la manera en que reacciona a ellos. Cuando se maneja un automóvil con transmisión manual en una pendiente, hay que soltar el pedal en ocasiones para evitar un atascamiento. Asimismo, retroceder puede prevenir que la ambición se atasque. Tanto en la pintura como en el caso de los hackers, existen tareas que son terriblemente ambiciosas, y otras que constituyen una rutina comfortable. Es una buena idea guardar algunas tareas sencillas para los momentos en los que de otra forma se atascaría.

En el oficio del hacker, esto puede significar literalmente guardar fallos. Me gusta la depuración: es el único momento en el que hackear es tan directo como la gente piensa que es. Se tiene un problema delimitado, y todo lo que hay que hacer es resolverlo. Su programa debe hacer x. En cambio, está haciendo y. ¿En dónde empieza a fallar? Usted sabe que al final va a resultar victorioso. Es tan relajante como pintar una pared.

El ejemplo de la pintura puede enseñarnos no solo sobre cómo manejar nuestro propio trabajo, sino también a cómo trabajar en conjunto. Bastante del arte genial del pasado es el trabajo de múltiples manos, aunque puede que haya solo un nombre al costado en la pared del museo. Leonardo era un aprendiz en el taller de Verrocchio y pintó uno de los ángeles en su Bautizo de Cristo. Este tipo de cosas eran la regla, no la excepción. Miguel Ángel era considerado de una dedicación especial por insistir en pintar todas las figuras en el techo de la Capilla Sistina él mismo.

Por lo que conozco, cuando los pintores trabajaban juntos en una obra, nunca trabajaban sobre 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 se tenía a una persona pintando sobre el trabajo de otro.

Pienso que este es el modelo correcto de colaboración para el software también. No hay que llevarlo demasiado lejos. Cuando un pedazo de código es hackeado por tres o cuatro personas diferentes, de las cuales ninguna es realmente el dueño, terminará siendo como un cuarto comunitario. Tenderá a sentirse oscuro y abandonado, y a acumular basura. La forma correcta de colaborar, pienso yo, es dividir los proyectos en módulos nítidamente definidos, cada uno con un dueño definido, y con interfaces entre ellos que sean diseñadas con tanto cuidado como sea posible, y, de ser posible, tan articuladas como lenguajes de programación.

Como en la pintura, la mayoría del software es dirigido a una audiencia humana. Y por esto los hackers, como los pintores, deben tener empatía para producir trabajo realmente genial. Se tiene que ser capaz de ver las cosas desde el punto de vista del usuario.

Cuando era niño, siempre me decían que viera las cosas desde el punto de vista de los demás. Lo que esto significaba siempre en la práctica era que hiciera lo que otra persona quería, en lugar de hacer lo que yo quería. Esto, por supuesto, le dió un mal nombre a la empatía, e hice un esfuerzo por no cultivarla.

Vaya si estaba equivocado. Resulta que ver las cosas desde el punto de vista de otras personas es prácticamente el secreto del éxito. No quiere decir necesariamente que haya que sacrificarse a sí mismo. Para nada. Entender cómo alguien más ve las cosas no implica que uno actúe en los intereses de aquél; en algunas situaciones --en la guerra, por ejemplo-- se querrá hacer exactamente lo opuesto. [4]

La mayoría de creadores hacen cosas para una audencia humana. Y para atrapar a una audencia se tiene que entender sus necesidades. Casi todas las grandes pinturas son pinturas sobre personas, por ejemplo, debido a que la gente es en lo que la gente está interesada.

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

Una forma de conocer qué tan buenas son las personas en cuanto a empatía se refiere es observarles explicar una pregunta técnica a alguien sin un trasfondo técnico. Probablemente todos conozcamos a personas que, aunque de otra forma son muy inteligentes, son simplemente cómicamente malos en esto. Si alguien les pregunta en una reunión social qué es un lenguaje de programación, ellos 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 lo que es un lenguaje de programación obviamente no sabe lo que son éstas cosas tampoco.

Parte de lo que debe hacer el software es explicarse a sí mismo. De modo que para escribir buen software hay que entender qué tan poco entienden los usuarios. Ellos van a recorrer el software sin preparación, y es mejor que haga lo que ellos esperan que haga, ya que no van a leer el manual. El mejor sistema que he visto en este sentido fue el Macintosh original, en 1985. Éste hacía lo que el software casi nunca hace: simplemente funcionaba. [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 aquella al comienzo de Estructura e Interpretación de Programas de Computadora.

Los programas deberían ser escritos para que las personas los lean, y, solo incidentalmente, para que las máquinas los ejecuten.
Es necesario tener empatía no solo para sus usuarios, sino para sus lectores. Hace parte de sus intereses, ya que usted mismo será uno de ellos. En varias ocasiones, un hacker ha escrito un programa solo para encontrar que seis meses después, al volver a él, no tiene idea de cómo trabaja. Conozco varias personas que han maldecido Perl después de tal tipo de experiencias. [7]

La falta de empatía se asocia con la inteligencia, al punto en que incluso hay algo de moda en carecer de empatía en algunas partes. Pero yo no creo que haya correlación alguna. Es posible ser bueno en matemáticas y ciencias naturales sin tener que aprender de empatía, y las personas en estos campos tienden a ser inteligentes, así que las dos cualidades han sido asociadas. Pero hay cantidades de gente tonta que son malos en empatía también. Tan solo escuche a las personas que llaman con preguntas a los talk shows. Ellos hacen sus preguntas en una forma tan redundante y confusa que los anfitriones con frecuencia tienen que refrasear la pregunta por ellos.

Así que, si hackear es en cierta forma como pintar y escribir, ¿es igual de interesante? Después de todo, solo se tiene una vida. Bien podría dedicarla a trabajar en algo grandioso.

Desafortunadamente, es difícil dar respuesta a tal pregunta. Siempre hay un gran retraso de tiempo en el prestigio. Es como la luz de una estrella distante. La pintura tiene prestigio ahora debido al grandioso trabajo que hicieron las personas hace quinientos años. En su momento, nadie pensaba que estas pinturas fueran tan importantes como las consideramos ahora. En ese entonces le hubiera parecido extraño a la gente que Federico da Montefeltro, el Duque de Urbino, sería conocido algún día principalmente como el tipo de la nariz curiosa en una pintura de Piero della Francesca.

Así que aunque admito que hackear no parece tan interesante como la pintura ahora, debemos recordar que la pintura como tal no parecía tan interesante en sus días de gloria como lo hace ahora.

Lo que podemos decir con cierta confianza es que éstos son los días de gloria de los hackers. En la mayoría de campos, el trabajo genial se produce en las etapas tempranas. Las pinturas hechas entre 1430 y 1500 siguen siendo inigualables. Shakespeare apareció justo cuando el teatro profesional estaba naciendo, y llevó a este medio tan lejos que toda obra desde aquel entonces ha tenido que vivir bajo su sombra. Albrecht Durer hizo lo mismo con el grabado, y Jane Austen con la novela.

Una y otra vez observamos el mismo patrón. Un nuevo medio aparece, y las personas se emocionan tanto con él que exploran la mayoría de sus posibilidades en el primer par de generaciones. La labor del hacker parece estar en esa fase ahora.

La pintura no era, en la época de Leonardo, tan interesante como su trabajo le ayudó a ser. Qué tan interesante resulte ser hackear dependerá de lo que podemos hacer en este nuevo medio. En algunas formas, el retraso de tiempo en el interés que genera es una ventaja. Cuando conozca a alguien que está escribiendo un compilador o hackeando un kernel tipo Unix, al menos sabrá que no lo está hacienda tan sólo para conocer chicas.

Gracias a Trevor Blackwell, Robert Morris, Dan Giffin, y Lisa Randall por leer borradores de este ensayo, y a Henry Leitner y Larry Finkelstein por invitarme a dar la charla.

Por qué el Buen Diseño Proviene del Mal Diseño

Traducción al Japonés
[1] El mayor daño que la fotografía le ha hecho a la pintura puede ser el hecho de que acabó con el mejor trabajo de día. La mayoría de grandes pintores de la historia se mantenían pintando retratos.

[2] Me han dicho que Microsoft desalienta a sus empleados a que contribuyan con proyectos de código-abierto, incluso en su tiempo libre. Pero tantos hackers de los mejores están trabajando en proyectos de código-abierto ahora que el principal efecto de esta política puede ser asegurarse de que no puedan contratar a ningún programador de primera línea.

[3] Lo que se aprende sobre programación en la universidad se parece bastante a aquello que se aprende sobre libros, o ropa o salidas románticas: qué tan mal gusto se tenía en los últimos años escolares.

[4] Aquí hay un ejemplo de empatía aplicada. En Viaweb, si no podíamos decidir entre dos alternativas, nos preguntaríamos, ¿que odiarían más nuestros competidores? En cierto punto un competidor agregó una característica a su software que era básicamente inútil, pero ya que se trataba de una de las pocas que ellos tenían y nosotros no, ellos hicieron un gran alboroto sobre esa característica en la prensa. Hubiéramos podido tratar de explicar que la característica era inútil, pero decidimos que molestaría más a nuestro competidor si nosotros mismos la implementáramos, así que hackeamos nuestra propia versión esa tarde.

[5] Excepto en el caso de editores de texto y compiladores. Los hackers no necesitan empatía para diseñar éstos, ya que ellos mismos son usuarios típicos.

[6] Bueno, casi. Sobrecargaron un poco la RAM disponible, causando bastante actividad de intercambio en disco, algo poco conveniente, pero esto podía repararse en unos meses mediante la compra de una unidad de disco adicional.

[7] La forma de hacer que los programas sean fáciles de leer no es llenarlos con comentarios. Yo llevaría la cita de Abelson y Sussman un paso más adelante. Los lenguajes de programación deberían ser diseñados para expresar algoritmos, y, solo incidentalmente, para decirle a las computadoras cómo ejecutarlos. Un buen lenguaje de programación debía ser mejor que el Inglés para explicar el software. Solo debería necesitar comentarios cuando hay algo peculiar sobre lo que desea advertir a los lectores, del mismo modo en que un camino sólo tiene flechas en las partes con curvas inesperadamente pronunciadas.