HACKERS Y PINTORES

Mayo 2003

(Este ensayo se deriva de una conferencia como invitado en Harvard, que incorporó una charla antes expuesta en Northeastern.)

Cuando terminé la universidad en ciencias de la computación asistí a la escuela de arte para estudiar pintura. Mucha gente se sorprendió de que alguien interesado en computadoras también estuviera interesado en la pintura. Parecían pensar que la programación y la pintura eran tipos de trabajo muy diferentes— que la programación era fría, precisa y metódica; y que la pintura era la expresión frenética de algún impulso primario.

Ambas imágenes están equivocadas. Programar y pintar tienen mucho en común. De hecho, de todos los diferentes tipos de personas que he conocido, los hackers [a] y los pintores se encuentran entre los más parecidos.

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



Nunca me ha gustado el término "ciencias de la computación". La razón principal por la que no me gusta es que no hay tal cosa. La informática es una bolsa de sorpresas de áreas tenuemente relacionadas que se encuentran juntas por un accidente de la historia, como Yugoslavia. En un extremo están las personas que en realidad son matemáticos, pero llaman a lo que están haciendo ciencia de la computación para poder obtener becas de DARPA [b]. En el medio hay gente trabajando en algo así como la historia natural de las computadoras: estudiando el comportamiento de los algoritmos de enrutamiento de datos a través de redes, por ejemplo. Y luego en el otro extremo tienes a los hackers, que tratan de escribir software interesante, y para quienes las computadoras son sólo un medio de expresión, al igual que el concreto para los arquitectos o la pintura para los pintores. Es como si los matemáticos, físicos y arquitectos tuvieran que estar juntos en el mismo departamento.

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

Qué y cómo, no deben estar muy separados. Buscas problemas si intentas decidir qué hacer sin entender cómo hacerlo. Pero sin duda hackear puede ser algo más que decidir cómo poner en práctica algunas especificaciones. En el mejor de los casos, es  crear la especificación: aunque resulta que la mejor manera de hacerlo es implementandola.



Tal vez algún día "las ciencias de la computación", al igual que Yugoslavia, se separarán en sus partes constitutivas. Eso podría ser una cosa buena. Sobre todo si eso significa la independencia para mi tierra natal, la programación.

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 de "ciencias de la computación". Podría decirse que la gente en el medio esta haciendo algo parecido a una ciencia experimental. Pero la gente en cada extremo, los hackers y los matemáticos, no están en realidad haciendo ciencia.

Los matemáticos no parecen molestarse por esto. Se ponen a trabajar con mucho gusto en comprobar teoremas matemáticos 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 “ciencias de la computación” en el exterior. Pero para los hackers esta etiqueta es un problema. Si lo que están haciendo se llama ciencia, les hace sentir que deben actuar científicamente. 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, estos articulos son sólo una formalidad. Los hackers escriben buen software, y luego escriben un artículo sobre el mismo, y el articulo se convierte en un sustituto para el logro representado por el software. Pero a menudo esta falta de coincidencia causa problemas. Es fácil alejarse de la creación de cosas bellas hacia la creación de cosas feas que hacen temas más adecuados para trabajos de investigación.

Por desgracia, las cosas bellas no siempre hacen los mejores temas de ponencias. Número uno, la investigación debe ser original  —y como cualquier persona que ha escrito una tesis doctoral sabe, la manera de estar seguro de que estamos explorando territorio virgen es apostar por un pedazo de tierra que nadie quiere—. Número dos, la investigación debe ser sustancial  —y los sistemas complicados producen artículos más sustanciosos, porque se puede escribir sobre los obstáculos que hay que superar para hacer las cosas—. Nada produce problemas más sustanciosos como partir de la hipótesis equivocada. La mayor parte de la Inteligencia Artificial es un ejemplo de esta regla; si se asume que el conocimiento puede ser representado como una lista de expresiones lógicas de predicados cuyos argumentos representan conceptos abstractos, tendrás un montón de artículos por escribir acerca de cómo hacer este trabajo. Como Ricky Ricardo solía decir: "—Lucy, usted tiene mucho que explicar."

La manera de crear algo bello a menudo es haciendo sutiles ajustes a algo existente, o combinar ideas ya existentes de una manera ligeramente nueva. Este tipo de trabajo es difícil de transmitir en un articulo de investigación.



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

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

La única prueba externa es el tiempo. Con el tiempo, las cosas bellas tienden a prosperar y las feas a ser descartadas. Lamentablemente, las cantidades de tiempo involucradas pueden ser superiores a las vidas humanas. Samuel Johnson [c] dijo que tomaba un siglo para que se consolidara la reputación de un escritor. Hay que esperar a que mueran los amigos influyentes del escritor, y luego todos sus seguidores.

Creo que a los hackers sólo les queda resignarse a tener un gran componente de azar en su reputación. En esto no son diferentes de otros creadores. De hecho, tienen suerte en comparación. La influencia de la moda no es tan grande en la programación, como lo es en la pintura.



Hay cosas peores que el que la gente malinterprete tu trabajo. Un peligro mayor es que tú mismo lo malinterpretes. Es a los campos relacionados a donde vas en busca de ideas. Por ejemplo, si te encuentras en el departamento de ciencias de la computación, hay una tentación natural a creer que programar equivale a la versión aplicada de las ciencias de la computación. Todo el tiempo que estuve en la universidad tuve una sensación incómoda en lo más profundo de mi mente de que debería saber más teoría, y que era muy negligente de mi parte haber olvidado todo eso a tres semanas del examen final.

Ahora me doy cuenta que estaba equivocado. Los hackers necesitan comprender la teoría de la computación tanto como los pintores necesitan comprender la química de la pintura. Necesitas saber cómo calcular la complejidad del tiempo y el espacio y sobre la completitud de Turing [d]. Es posible que también te convenga recordar al menos el concepto de una máquina de estados, en caso de tener que escribir un programa de análisis o una biblioteca de expresiones regulares. Los pintores, de hecho, tienen que recordar mucho más sobre la química de la pintura que eso.

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

Por ejemplo, en la universidad me enseñaron que uno debe idear un programa completamente en papel antes, incluso, de acercarse a una computadora. Descubrí que yo no programo de esta manera. Descubrí que me gustaba programar sentado delante de una computadora, no frente a un pedazo de papel. Peor aún, en lugar de escribir pacientemente todo un programa completo y asegurarme a mí mismo que estaba en lo correcto, tendía a sacar sólo código que estaba irremediablemente roto, y al que poco a poco le daba forma. La depuración, se me enseñó, era una especie de paso final en la que atrapas erratas y descuidos. Parecia como si la forma en que yo trabajaba la programación consistía en depuración.

Durante mucho tiempo me sentí mal por esto, al igual que alguna vez me sentí mal por no sostener mi lápiz de la manera en que me enseñaron en la primaria. Si tan sólo hubiera visto a otros creadores, a los pintores o a los arquitectos, habría descubierto que había un nombre para lo que estaba haciendo: bosquejar. Hasta donde sé, la forma en que me enseñaron a programar en la universidad esta mal. Comprendes los programas a medida que los escribes, tal como 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 debe, sobre todo, ser maleable. Un lenguaje de programación es para pensar en programas, no para expresar los programas que ya has pensado. Debería ser un lápiz, no una pluma. El carácter estático sería una buena idea si la gente realmente escribiera programas de la forma en que me enseñaron en la universidad. Pero no es así como cualquiera de los hackers que conozco escribe programas. Necesitamos un lenguaje que nos permita hacer garabatos y borrones y frotis, no un lenguaje donde tienes que sentarte con una taza de caracteres balanceándose sobre tu rodilla, para tener una conversación cortés con un compilador que es como una tía vieja y estricta.



Ya que estamos en el tema de tipado estático, identificarse con sus fabricantes nos salvará de otro problema que aqueja a las ciencias: la envidia a las matemáticas. Todo mundo en las ciencias cree, en secreto, que los matemáticos son más inteligentes de lo que son. Pienso que también los matemáticos creen esto. En cualquier caso, 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 a medida que nos alejamos de las ciencias naturales, se vuelve un problema más grande.

Una página de fórmulas luce simplemente impresionante. (Consejo: para que luzca todavía más impresionante, utiliza variables en Griego.) Así, hay una gran tentación por trabajar en problemas que se puedan tratar formalmente, en lugar de problemas que son, digamos, importantes.

Si los hackers se identificaran con otros creadores, ya sea escritores o pintores, no se sentirían tentados a hacer esto. Los escritores y los pintores no sufren de envidia a las matemáticas. Sienten como si estuvieran haciendo algo completamente diferente. Los hackers son iguales, creo.



Si las universidades y laboratorios de investigación impiden que los hackers hagan el tipo de trabajo que quieren hacer, tal vez el lugar para ellos esta en las empresas. Desafortunadamente, la mayoría de las empresas tampoco permiten a los hackers hacer lo que quieren. Las universidades y los laboratorios de investigación forzan a los hackers a ser científicos, y las empresas los forzan a ser ingenieros.

Descubrí esto sólo hace muy poco. Cuando Yahoo compró Viaweb [e], me preguntaron qué quería hacer. Nunca me había gustado mucho el aspecto comercial, asi que les dije que sólo quería hackear. Cuando llegué a Yahoo, me encontré con que lo que hackear significaba para ellos era implementar software, no diseñarlo. Los programadores eran vistos como los técnicos que traducían a código las visiones (si esa es la palabra) de los jefes de producto.

Este parece ser el plan predeterminado en las grandes empresas. Lo hacen porque disminuye la desviación estándar de los resultados. Sólo un pequeño porcentaje de hackers pueden en realidad diseñar software, y es difícil para las personas que dirigen una empresa seleccionarlos. Así que en vez de confiar el futuro del software a un hacker brillante, la mayoría de las empresas acomodan las cosas de modo que este sea diseñado por un comité, y los hackers simplemente implementan el diseño.

Si quieres hacer dinero en algún momento, recuerda esto, porque esta es una de las razones por la que las startups [f] ganan. Las grandes compañías quieren disminuir la desviación estándar en los resultados del diseño, pues desean evitar los desastres. Pero cuando moderas las oscilaciones, pierdes los puntos altos, así como los bajos. Este no es un problema para las grandes empresas, porque no ganan por hacer grandes productos. Las grandes empresas ganan siendo un poco menos malas que otras grandes empresas.

Así que si puedes encontrar una manera de entrar en una guerra de diseño con una compañía tan grande que su software es diseñado por los jefes de producto, nunca serán  capaces de mantenerte el paso. Sin embargo, estas oportunidades no son fáciles de encontrar. Es difícil hacer que una gran empresa entre en una guerra de diseño, al igual que es difícil atraer a un oponente que esta dentro de un castillo a un combate mano a mano. Por ejemplo, sería muy fácil escribir un procesador de texto mejor que Microsoft Word, pero Microsoft, dentro del castillo monopolico de su sistema operativo, probablemente ni siquiera se daría cuenta si lo haces.

El lugar para luchar guerras de diseño se encuentra en los nuevos mercados, donde nadie haya conseguido todavia establecer alguna fortificación. Ahí es donde se puede ganar a lo grande, tomando un enfoque audaz para diseñar, y hacer que las mismas personas diseñen e implementen el producto. El mismo Microsoft hizo esto en sus inicios. Lo mismo hizo Apple. Y Hewlett-Packard. Sospecho que casi todas las startups exitosas lo han hecho.



Así que una manera de construir software grandioso es empezar tu propia startup. Sin embargo, hay dos problemas con esto. Uno de ellos es que en una startup tienes que hacer muchas cosas, además de escribir software. En Viaweb me consideraba afortunado si podía programar una cuarta parte del tiempo. Y las cosas que tenía que hacer las otras tres cuartas partes oscilaban entre tediosas y aterradoras. Tengo un punto de referencia para esto, porque una vez tuve que salir de una reunión de consejo para rellenarme algunas caries. Recuerdo estar sentado en la silla del dentista, esperando el taladro, y sentir como si estuviera de vacaciones.

El otro problema con las startups es que no hay mucho solapamiento entre el tipo de software que hace dinero y el del tipo que es interesante para escribir. Los lenguajes de programación son interesantes para escribir, y el primer producto de Microsoft de hecho, fue uno, pero ahora nadie paga por los lenguajes de programación. Si quieres ganar dinero, tiendes a ser obligado a trabajar en problemas que son demasiado desagradables para que cualquier persona los resuelva de forma gratuita.

Todos los creadores se enfrentan a este problema. Los precios son determinados por la oferta y la demanda, y no existe tanta demanda por cosas que son divertidas para trabajar como la hay por cosas que resuelven los mundanos problemas de clientes individuales. Actuar en obras fuera de Broadway no paga tan bien como usar un traje de gorila en el stand de alguien en una feria comercial. Escribir novelas no paga tan bien como escribir anuncios para bolsas de basura. Y crear lenguajes de programación no paga tan bien como encontrar la manera de conectar la anticuada base de datos de alguna empresa a su servidor Web.



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

Casi todos los creadores tienen trabajos diurnos al iniciar sus carreras. Asi es, notoriamente, con pintores y escritores. Si eres afortunado puedes conseguir un trabajo diurno que estará muy relacionado con tu trabajo real. Los músicos a menudo suelen trabajar en tiendas de discos. Un hacker trabajando en algún lenguaje de programación o sistema operativo podría igualmente conseguir un trabajo diurno utilizandolo. [1]

Cuando digo que la solución es que los hackers tengan trabajos diurnos, y trabajen en software bello por otro lado, no lo estoy proponiendo como una idea nueva. De esto es de lo que se trata la programación de código abierto. Lo que estoy diciendo es que probablemente el modelo de código abierto sea el correcto, porque ha sido confirmado de forma independiente por todos los demás creadores.

Me parece sorprendente que cualquier empleador este reacio a dejar que los hackers trabajen en proyectos de código abierto. En Viaweb, habríamos estado renuentes a contratar a alguien que no lo hiciera. Cuando entrevistábamos a los programadores, lo que más nos interesaba era qué tipo de software escribían en su tiempo libre. No puedes hacer nada realmente bien a menos que lo ames, y si te gusta programar, inevitablemente estarás trabajando en proyectos propios. [2]



Debido a que los hackers son creadores en vez de científicos, el lugar adecuado para buscar metáforas no es en las ciencias, sino entre los otros tipos de creadores. ¿Qué otra cosa puede la pintura enseñarnos acerca de la programación?

Una cosa que podemos aprender, o al menos confirmar, desde el ejemplo de la pintura, es la forma de aprender a hackear. Aprendes a pintar sobre todo haciendolo. Lo mismo ocurre con la programación. La mayoría de los hackers no aprenden a hackear tomando cursos universitarios en programación. Aprenden a hackear escribiendo sus propios programas a la edad de trece años. Incluso en las clases de la universidad, aprendes a hackear sobre todo, hackeando. [3]

Debido a que los pintores dejan una estela de trabajo trás ellos, puedes ver como aprenden con la practica. Si nos fijamos en la obra de un pintor en orden cronológico, encontraras que cada cuadro se basa en cosas que han aprendido en los anteriores. Cuando hay algo en un cuadro que funciona muy bien, puedes encontrar la versión 1 de la misma en un formato más pequeño en algunas pinturas anteriores.

Creo que la mayoría de los creadores trabajan de esta manera. Parece que los escritores y los arquitectos también. Tal vez sería bueno que los hackers actuaran más como pintores, y empezaran regularmente desde cero, en lugar de seguir trabajando durante años en un proyecto, intentando incorporar todas sus ideas posteriores como revisiones.

El hecho de que los hackers aprendan a hackear practicando es otro signo de lo diferente que es la programación, a las ciencias. Los científicos no aprenden ciencia haciendola, sino realizando conjuntos de problemas y laboratorio. Los científicos comienzan haciendo un trabajo que es perfecto, en el sentido de que están tratando de reproducir el trabajo que ya alguien más ha hecho por ellos. Eventualmente, llegan al punto en que pueden hacer trabajo original. Mientras que los hackers, desde el principio, están haciendo trabajo original; sólo que muy malo. Así que los hackers son originales de inicio, y se hacen buenos, y los científicos comienzan bien, y se hacen originales.



La otra forma en que los creadores aprenden es de los ejemplos. Para un pintor, un museo es una biblioteca de referencia de las 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 ver detenidamente la forma en que se hizo una pintura.

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

Los hackers, pueden, del mismo modo, aprender a programar viendo buenos programas: no sólo en lo que hacen, sino viendo el código fuente también. Una de las ventajas menos publicitadas del movimiento de código abierto es que se ha hecho más fácil aprender a programar. Cuando aprendí a programar, dependiamos, sobre todo, de ejemplos en los libros. El gran trozo de código disponible entonces era Unix, pero incluso este no era de código abierto. La mayoría de la gente que leyó la fuente lo hizo en fotocopias ilegales del libro de John Lions [g], que, aunque fue escrito en 1977, no se permitió su publicación hasta 1996.



Otro ejemplo que podemos tomar de la pintura es que la forma en que las pinturas son creadas es a base de refinamientos graduales. Estas por lo general comienzan con un boceto. Poco a poco se llenan los detalles. Pero no es simplemente un proceso de rellenado. A veces los planes originales resultan estar equivocados. Innumerables pinturas, cuando se las ve en radiografías, resultan tener miembros que se han movido o rasgos faciales que han sido reajustados.

He aquí un caso en el que podemos aprender de la pintura. Creo que la programación debe funcionar también de esta manera. No es realista esperar que las especificaciones de un programa serán perfectas. Te ira mejor si admites esto desde el principio, y escribes programas de una manera que le permita a las especificaciones cambiar sobre la marcha.

(La estructura de las grandes empresas hace que esto sea difícil para ellos, así que este es otro lugar donde las startups tienen una ventaja.)

Probablemente, a estas alturas ya todo el mundo sabe sobre el peligro de la optimización prematura. Creo que deberíamos estar igualmente preocupados por el diseño prematuro― decidir demasiado pronto lo que un programa debe hacer.

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 representa un triunfo aquí, porque no tienes que comprometerte a representaciones de datos específicos por adelantado. Pero la clave de la flexibilidad, creo yo, es hacer el lenguaje 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 debe ser mejor de lo que tiene que ser. Por ejemplo, cuando Leonardo pintó el retrato de Ginevra de Benci que se encuentra en la Galería Nacional, puso un arbusto de enebro detrás de su cabeza. En este, pintó cuidadosamente cada hoja individual. Muchos pintores podrían haber pensado que esto es sólo algo para poner de fondo y que sirva para enmarcar la cabeza. Nadie prestará mucha atención.

No asi Leonardo. Qué tan duro trabajaba en alguna parte de la pintura no dependía en absoluto de con cuanta atención esperaba que alguien la mirara. Él era como Michael Jordan. Implacable.

La implacabilidad gana porque, en el agregado, los detalles no vistos se hacen visibles. Cuando la gente camina al lado del retrato de Ginevra de Benci, su atención es a menudo inmediatamente apresada por este, incluso antes de que vean la etiqueta y el aviso que dice Leonardo da Vinci. Todos esos detalles invisibles se combinan para producir algo que es simplemente impresionante, como mil voces apenas audibles cantando todas al unísono.

El software grandioso, de igual forma, requiere una devoción fanática a la belleza. Si se mira el interior de un buen programa, encontrarás que algunas partes que no se supone que alguien vea son hermosas también. No estoy afirmando que escribo software grandioso, pero sé que cuando se trata de código me comporto de una manera que me haría elegible a medicación si abordara la vida cotidiana de la misma manera. Me trastorna ver código que está mal delimitado, o que utiliza nombres de variables horrendos.

 

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

En la programación, como en la pintura, el trabajo viene en ciclos. A veces te emocionas con un nuevo proyecto y deseas 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 son susceptibles a la manera en cómo reaccionas ante ellos. Cuando conduces un coche con transmisión manual sobre una colina en ocasiones tienes que liberar el embrague para evitar el estancamiento. Liberar puede, también, impedir que la ambición se estanque. Tanto en la pintura como en la programación hay algunas tareas que son terriblemente ambiciosas, y otras que son confortable rutina. Es una buena idea guardar algunas tareas fáciles para momentos en los que de otra manera te estancarías.

En la programación, esto literalmente puede significar dejar que se acumulen algunos errores. Me gusta la depuración: es la única ocasión que la programación es tan sencilla como la gente piensa que es. Tienes un problema totalmente contenido, y todo lo que tienes que hacer es resolverlo. Tu programa se supone que debe hacer x. En su lugar, hace y. ¿En dónde esta mal? Sabes que al final ganarás. Es tan relajante como pintar una pared.



El ejemplo de la pintura puede enseñarnos no sólo cómo manejar nuestro propio trabajo, sino como trabajar juntos. Muchas de las grandes obras de arte del pasado son fruto de varias manos, aunque puede ser que sólo haya un nombre en la pared junto a ella en el museo. Leonardo era un aprendiz en el taller de Verrocchio y pintó uno de los ángeles en su Bautismo de Cristo. Este tipo de cosas era la regla y no la excepción. Miguel Ángel era considerado especialmente dedicado por insistir en pintar él mismo todas las figuras en el techo de la Capilla Sixtina.

Hasta donde yo sé, cuando los pintores trabajaban juntos en un cuadro, nunca lo hacian en las mismas partes. Era común que el maestro pintara las figuras principales y los asistentes pintaran a los demás y el fondo. Pero nunca tenias a alguien pintando sobre el trabajo de otro.

Creo que también este es el modelo adecuado para la colaboración en el software. No presiones demasiado. Cuando una pieza de código está siendo programada por tres o cuatro personas diferentes, ninguno de los cuales la posee realmente, terminara siendo como una sala común. Tenderá a sentirse triste y abandonada, y se acumulara el polvo. La forma correcta de colaborar, creo, es que los proyectos se dividan en módulos bien definidos, cada uno con un titular definitivo, con las interfaces entre ellas tan cuidadosamente diseñadas y, si es posible, tan articuladas como lenguajes de programación.

 

Al igual que la pintura, la mayor parte del software está destinado a un público humano. Asi que los hackers, como los pintores, deben tener empatía para realmente hacer un gran trabajo. Tienes que ser capaz de ver las cosas desde el punto de vista del usuario.

Cuando era niño siempre se me decía que viera las cosas desde el punto de vista de alguien más. Lo que esto significaba, en la práctica, era hacer siempre lo que alguien más quería, en lugar de lo que yo quería. Por supuesto, esto le dio mala fama a la empatía, y me propuse 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 significa necesariamente que te auto-sacrifiques. Ni mucho menos. Comprender cómo ve las cosas otra persona no implica que vas a obrar en su interés; en algunos casos —en la guerra, por ejemplo— querras hacer exactamente lo contrario. [4]

La mayoría de los creadores hacen las cosas para un público humano. Y para cautivar al público tienes que entender lo que necesitan. Por ejemplo, casi todas las grandes pinturas son pinturas de personas, porque son personas en lo que otras personas se interesan.

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

Una forma de saber que tan buena es la gente respecto a la empatía es verlos explicar una cuestión técnica a alguien sin conocimientos técnicos. Probablemente todos conocemos a personas que, aunque inteligentes en otro sentido, son, sencillamente, cómicamente malos en esto. Si alguien en una cena les pregunta que es un lenguaje de programación, diran algo así como: —“¡Oh!, un lenguaje de alto nivel es lo que el compilador utiliza como entrada para generar el 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 tampoco lo que son estas cosas.

Parte de lo que el software tiene que hacer es explicarse a sí mismo. Así que para escribir buen software tienes que entender que los usuarios comprenden muy poco. Ellos llegaran a este sin ninguna preparación, y más vale que haga lo que se supone que hace, porque no van a leer el manual. El mejor sistema que he visto en este sentido fue la Macintosh original de 1985. Hizo lo que el software casi nunca hace: Funcionaba. [6]

El código fuente, también, debería explicarse a si mismo. Si pudiera hacer que la gente recordara tan sólo una cita sobre la programación, sería la que esta al principio de Estructura e Interpretación de Programas Computacionales. [h]

 

Los programas deben ser escritos para que la gente los lea, y sólo incidentalmente para que las máquinas los ejecuten.

Necesitas tener empatía no sólo para tus usuarios, sino además para tus lectores. Está en tu interés, ya que serás uno de ellos. Más de un hacker ha escrito un programa sólo para descubrir, al regresar al mismo seis meses más tarde, que no tiene idea de cómo funciona. Conozco varias personas que han renunciado a Perl después de semejantes experiencias. [7]

La falta de empatía se asocia con la inteligencia, a tal punto, que hay incluso una especie de moda para esto en algunos lugares. Pero no creo que haya ninguna correlación. Puede irte bien en las matemáticas y las ciencias naturales sin tener que aprender empatía, y las personas en estos campos tienden a ser inteligentes, por lo que las dos cualidades han llegado a ser asociadas. Pero hay mucha gente tonta que también es mala para la empatía. Tan sólo escucha a las personas que llaman con preguntas a los programas de entrevistas. Piden lo que sea que están pidiendo, de forma tan indirecta, que los anfitriones a menudo tienen que reformular la pregunta por ellos.



Entonces, si hackear funciona como la pintura y la escritura, ¿es igual de atractivo? Después de todo, sólo tienes una vida. Bien podrías pasarla trabajando en algo grandioso.

Por desgracia, la pregunta es difícil de contestar. Siempre hay un desfase importante respecto al prestigio. Es como la luz de una estrella distante. La pintura tiene prestigio ahora debido a las grandes obras que la gente hizo hace 500 años. En ese momento, nadie pensó que estas pinturas fueran tan importantes como lo hacemos hoy en día. Hubiera parecido muy extraño a la gente en su momento que Federico da Montefeltro, duque de Urbino, sería un día conocido sobre todo como el hombre con la nariz extraña en una pintura de Piero della Francesca.

Así, aunque admito que hoy hackear no parece tan atractivo como la pintura, debemos recordar que la pintura en sí no parecía tan atractiva en sus días de gloria como lo es ahora.

Lo que podemos decir con cierta seguridad es que estos son los días de gloria de la programación. En la mayoría de los campos, las grandes obras se crean en sus inicios. Las pinturas realizadas entre 1430 y 1500 siguen sin ser superadas. Shakespeare apareció justo cuando el teatro profesional estaba naciendo, y elevó el medio en tal medida, que cada autor desde entonces ha tenido que vivir bajo su sombra. Alberto Durero hizo lo mismo con el grabado, y Jane Austen con la novela.

Una y otra vez vemos el mismo patrón. Un nuevo medio aparece, y la gente está tan entusiasmada que explora casi todas sus posibilidades en el primer par de generaciones. Hackear parece estar en esta fase ahora.

La pintura no era, en la época de Leonardo, tan atractiva como su trabajo le ayudó a serlo. Que tan atractiva resulte ser la programación dependerá de lo que podamos hacer con este nuevo medio.

 

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

[2] Me han dicho que Microsoft desalienta a los empleados a contribuir en proyectos de código abierto, incluso en su tiempo libre. Pero muchos de los mejores hackers trabajan en proyectos de código abierto ahora que el principal efecto de esta política puede ser garantizar que no van a poder contratar programadores de primer nivel.

[3] Lo que descubres acerca de la programación en la universidad es muy parecido a lo que descubres de los libros, la ropa o las citas: el mal gusto que tenias.

[4] He aquí un ejemplo de empatía aplicada. En Viaweb, si no podíamos decidir entre dos alternativas, nos preguntábamos que odiarían más nuestros competidores. En un momento un competidor agregó una función para su software que era básicamente inútil, pero como era una de las pocas que ellos tenían y nosotros no, hicieron mucho alboroto acerca de ella en la prensa especializada. Podríamos haber tratado de explicar que la función era inútil, pero decidimos que sería más molesto para nuestro competidor si tan solo la implementábamos nosotros mismos, por lo que hicimos nuestra propia versión esa tarde.

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

[6] Bueno, casi. Sobrepasaron la memoria RAM disponible un poco, causando inconvenientes cambios de disco, pero esto podía arreglarse en unos pocos meses comprando una unidad de disco adicional.

[7] La forma de hacer que los programas sean fáciles de leer es no llenarlos con comentarios. Llevaria la cita de Abelson y Sussman un paso más allá. Los lenguajes de programación deben ser diseñados para expresar algoritmos, y sólo incidentalmente para decirle a las computadoras cómo ejecutarlos. Un buen lenguaje de programación debería ser mejor para explicar el software que el inglés. Los comentarios sólo son necesarios cuando hay algún tipo de truco acerca del que necesitas advertir a los lectores, al igual que en un camino sólo hay flechas en lugares con curvas inesperadamente fuertes.

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

Traducido de Hackers and Painters por Paul Graham. Traducción al Español Armando Alvarez.

 

[a] En La Palabra Hacker Paul Graham da la siguiente descripción: “Para la prensa popular, "hacker" significa alguien que irrumpe en las computadoras. Entre los programadores significa: un buen programador. Pero los dos sentidos están conectados. Para los programadores, "hacker" connota dominio en el sentido más literal: alguien que puede hacer que una computadora haga lo que él quiere—ya sea que la computadora quiera o no...”

[b] DARPA acrónimo de la expresión en inglés Defense Advanced Research Projects Agency (Agencia de Investigación de Proyectos Avanzados de Defensa) es una agencia del Departamento de Defensa de los Estados Unidos responsable del desarrollo de nuevas tecnologías para uso militar. Fue creada en 1958 como consecuencia tecnológica de la llamada Guerra Fría, y del que surgieron, décadas después, los fundamentos de ARPANET, red que dio origen a Internet. [Fuente: Wikipedia. Ver.)

[c] Samuel Johnson (Lichfield, Staffordshire, 18 de septiembre de 1709 - Londres, 13 de diciembre de 1784), por lo general conocido simplemente como el Dr. Johnson, es una de las figuras literarias más importantes de Inglaterra: poeta, ensayista, biógrafo, lexicógrafo, está considerado por muchos como el mejor crítico literario en idioma inglés. Johnson era poseedor de un gran talento y de una prosa con un estilo inigualable. [Fuente: Wikipedia. Ver.]

[d] En la teoría de computadoras reales e imaginarias, de los lenguajes de programación y de otros sistemas lógicos, un sistema Turing completo es aquel que tiene un poder computacional equivalente a la máquina universal de Turing. En otras palabras, el sistema y la máquina universal de Turing pueden emularse entre sí. [Fuente: Wikipedia. Ver.]

[e] Viaweb era una empresa que propocionaba software y herramientas de informes para construir y hacer funcionar sitios de comercio electrónico en la Web. Su producto de comercio electrónico se implementó inicialmente en lenguaje Common Lisp.

La empresa fue fundada por Paul Graham y Robert Tappan Morris en 1995. Fue adquirida en el verano de 1998 por Yahoo!, mediante un intercambio de acciones equivalente a unos 49 millones de dólares. En Yahoo!, el producto se denominó Yahoo! Store. [Fuente: Wikipedia. Ver.]

[f] El termino startup define a una empresa de reciente creación orientada a la tecnología. El mismo Paul Graham la define a la perfección en Como Financiar una Startup: "Una empresa tiene que ser más que pequeña y de reciente creación para ser una startup. Hay millones de pequeñas empresas en Estados Unidos, pero sólo unas pocas miles son startups. Para ser una startup, una compañía tiene que ser un negocio de productos, no un negocio de servicios. Lo que no quiere decir que tiene que hacer algo físico, sino que tiene que tener una cosa que vende a mucha gente, en vez de hacer trabajos a medida para clientes individuales. El trabajo sobre encargo no es escalable. Para ser una startup tienes que ser la banda que vende un millón de copias de una canción, no el grupo que gana dinero tocando en bodas y Bar Mitzvahs individuales."

[g] El libro Lions' Commentary on UNIX 6th Edition, with Source Code (Comentario de Lion a la 6ta. Edición de UNIX, con Codigo Fuente) por John Lions (1976) contiene el código fuente completo de la sexta edición del kernel Unix, más un comentario. Comúnmente se le conoce como el Libro de Lions. A pesar de su edad, todavía se considera un excelente comentario sobre código sencillo pero de alta calidad.

Durante muchos años, el Libro de Lions fue la única documentación del kernel Unix disponible fuera de los Laboratorios Bell. Aunque la licencia de la 6ª edición permitía el uso en clase del código fuente, la licencia de la 7ª Edición excluía expresamente dicho uso, por lo que el libro se propagó por samizdat. Se sostuvo comúnmente que era el libro más copiado de la informática.

El libro fue reeditado en 1996 por comunicaciones Peer-to-Peer. [Fuente: Wikipedia en Inglés. Ver.]

[h] Structure and Interpretation of Computer Programs (Estructura e Interpretación de Programas Computacionales) es un libro de texto publicado por MIT Press en 1984 sobre los conceptos generales de la programación de computadoras, escrito por los profesores del Massachusetts Institute of Technology (MIT) Harold Abelson y Gerald Jay Sussman, con la colaboración de Julie Sussman. Fue utilizado como libro de texto en las clases de introducción a la programación del MIT y de otras escuelas.

Utilizando un dialecto del lenguaje de programación Lisp llamado Scheme, el libro explica los conceptos fundamentales de la informática, incluida la abstracción, la recursividad, los intérpretes y la abstracción metalingüística, y enseña la programación modular. [Fuente: Wikipedia en Inglés. Ver.]