Hackers y pintores

Esta es una traducción del ensayo “Hackers and painters” escrito por Paul Graham. Traducción a cargo de  Ernesto Badillo y Alfonso Sánchez.

Libro de ensayos de Paul Graham cuyo nombre deriva del presente ensayo.

Libro de ensayos de Paul Graham cuyo nombre deriva del presente ensayo.

Mayo de 2003

(Este ensayo se deriva de una plática que ofrecí en Harvard, que incorporaba otra plática presentada en la Universidad Northeastern).

Cuando terminé mi posgrado en Ciencias de la Computación me inscribí a la escuela de artes para estudiar pintura. A mucha gente le sorprendió que alguien metido la computación se interesara también por la pintura. Al parecer creían que hackear y pintar eran dos tipos muy distintos de trabajo— creían que la programación era algo frío, preciso y metódico mientras que la pintura era la expresión frenética de un impulso primario.

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 se encuentran entre los más similares.

Lo que hackers y pintores tienen en común es que ambos son creadores. Igual que los compositores, arquitectos y escritores, lo que los hackers y pintores buscan es crear cosas buenas. No hacen investigación en sí, aunque está muy bien si descubren una técnica nueva en su intento de  crear cosas buenas.


Nunca me gustó el término “Ciencias de la Computación”. Sobre todo porque describe algo que no existe. Las Ciencias de la Computación son como Yugoslavia: un conjunto de cosas distintas entre sí que por un accidente histórico terminaron juntas. En un extremo tienes a computólogos que en realidad son matemáticos, pero llaman a su trabajo “Ciencias de la Computación” para obtener mejores becas. En medio tienes a personas que trabajan en algo así como “Historia Natural de las Computadoras”— estudian el comportamiento de los algoritmos que enrutan datos a través de redes, por ejemplo. En el extremo opuesto tienes a los hackers, que están tratando de escribir software interesante y para quieres las computadoras son meramente un medio de expresión, como es el concreto para los arquitectos o los pigmentos para los pintores. Es como si matemáticos, físicos y arquitectos tuvieran que convivir en el mismo departamento.

Al oficio de los hackers se le llama a veces “Ingeniería de software”, pero el término es igual de engañoso. Los buenos diseñadores de software no son más “ingenieriles” que los arquitectos. La frontera entre la arquitectura y la ingeniería no está claramente definida, pero existe. La encontramos en las diferencias que existen entre el qué y el cómo: los arquitectos deciden qué hacer y los ingenieros averiguan cómo hacerlo.

El qué y el cómo no deberían manejarse por separado. Tomar la decisión de hacer algo antes de entender cómo se hace es buscarle tres pies al gato. Pero hackear puede ir más allá de la decisión de cómo implementar una especificación— en el mejor de los casos hackear significa crear la especificación misma… y resulta que la mejor forma de crear la especificación es programándola.

Tal vez algún día las “Ciencias de la computación”, al igual que Yugoslavia, serán separadas en sus componentes fundamentales. Esto podría ser benéfico. Especialmente si significa la independencia de mi tierra natal, Hackerlandia.

Agrupar en el mismo departamento tantos trabajos distintos puede ser conveniente desde el punto de vista administrativo, pero es intelectualmente confuso. Ese es mi otro disgusto con el término “Ciencias de la computación”. Podría decirse que la gente que está en medio hace algo similar a la ciencia experimental, pero las personas de los extremos (los hackers y los matemáticos) no están haciendo ciencia realmente.

A los matemáticos no parece molestarles. Igual que sus colegas del departamento de matemáticas, se dedican a demostrar teoremas felizmente y podrían olvidar fácilmente de que la fachada de su edificio dice “Ciencias de la computación”. Pero para los hackers la etiqueta sí es un problema. El que su actividad se catalogue como ciencia les hace sentir que deben actuar científicamente. Así que en lugar de hacer lo que realmente desean, que es diseñar software bello, los hackers en universidades y centros de investigación sienten que deberían estar escribiendo artículos científicos.

En el mejor de los casos los artículos son una mera formalidad. Los hackers escriben buen software y después escriben un artículo al respecto, así el artículo sustituye el logro que el software representa. Pero ese desajuste a menudo causa problemas. Es fácil alejarse de la construcción de cosas bellas y pasar a construir cosas feas que son mejores temas de investigación.

Por desgracia, las cosas bellas no siempre dan para buenos artículos de investigación. Primero, la investigación debe ser original— y como cualquiera que haya escrito una tesis doctoral lo sabe bien, la mejor forma de asegurarse de explorar territorio virgen es conseguirse un trozo de terreno que no le interese a nadie. En segundo lugar, una investigación debe ser vasta— y los sistemas rebuscados producen artículos más vastos. Y nada produce problemas sustanciosos como trabajar sobre premisas incorrectas. La mayor parte del trabajo que se hace en Inteligencia Artificial es un ejemplo de esta regla; si asumes que el conocimiento puede ser representado como una lista de predicados lógicos cuyos argumentos representan conceptos abstractos, vas a tener que escribir un montón de artículos en los que explicas lo que hay que hacer para que la cosa funcione. Como solía decir Ricky Ricardo, “Lucy, me debes un montón de explicaciones”.

La forma de crear algo bello es, regularmente, haciendo ajustes sutiles a algo que ya existe, o combinando ideas existentes de una forma ligeramente distinta. Es difícil expresar esta clase de trabajo mediante un escrito científico.

Entonces ¿por qué las universidades y centros de investigación siguen juzgado a los hackers por sus publicaciones? Por la misma razón que la “aptitud académica” se juzga mediante exámenes simplistas o la productividad de los programadores se mide en líneas de código. Son pruebas de fácil aplicación y no hay nada más tentador que una evaluación sencilla que más o menos funciona.

Sería mucho más difícil evaluar a los hackers por aquello a lo que verdaderamente aspiran, que es el diseño de software bello. Necesitas un buen sentido del diseño para poder juzgar si un diseño es bueno y no existe ninguna correlación entre la estima que la gente tiene por su propio criterio y su habilidad real para reconocer buen diseño, o bien, se trata de una correlación negativa.

La única prueba objetiva es el tiempo. Con el paso del tiempo las cosas bellas tienden a prosperar y las cosas feas tienden a ser descartadas. Por desgracia esto conlleva una cantidad de tiempo que supera la duración de las vidas humanas. Samuel Johnson decía que la reputación de un escritor tarda cien años en aclararse. Tienes que esperar a que mueran todos los amigos influyentes del escritor y luego tienes esperar a que mueran los seguidores de esos amigos.

Creo que los hackers deben resignarse a que una buena parte de su reputación dependa del azar. En esto no son distintos a otros creadores. De hecho, son comparativamente afortunados. La moda ejerce una influencia menor en el software que en la pintura.

Hay cosas peores que encontrarte con personas que malinterpreten tu trabajo. Pero lo mas peligroso es que tú mismo no lo entiendas bien. Uno va en busca de ideas a los campos relacionados. Si te encuentras en el departamento de Ciencias de la Computación tienes la tentación natural de creer, por ejemplo, que hackear es aplicación directa de la teoría de la computación. Durante el tiempo que estuve en la universidad tuve una sensación incómoda en el fondo de mi mente, sentía que debía saber más teoría y que era muy negligente de mi parte olvidarla toda tres semanas después del examen final.

Ahora me doy cuenta de que estaba equivocado. Los hackers necesitan entender teoría de la computación tanto como los pintores necesitan entender la química de los pigmentos. Necesitas saber calcular complejidades en tiempo y espacio y saber qué significa que un sistema sea Turing completo. Es posible que también necesites recordar al menos el concepto de autómata finito en caso de que necesites escribir un analizador sintáctico o una biblioteca de expresiones regulares. Los pintores, de hecho, tienen que recordar mucho más sobre química de pigmentos.

Descubrí que las mejores fuentes de ideas no son las áreas que tienen “computación” en sus nombres, sino en las áreas en las que trabajan creadores. La pintura ha sido una fuente de ideas mucho más rica que la teoría de la computación.

Por ejemplo, en la universidad me enseñaron que un programa debe desarrollarse completamente en papel antes de siquiera acercarse a una computadora. Me di cuenta de que yo no programaba de esta manera. Descubrí que me gustaba programar sentado frente a una computadora, no frente a un pedazo de papel. Peor aún, en lugar de manuscribir pacientemente un programa completo y convencerme de que servía, simplemente escupía código con pocas esperanzas de que funcionara e iba moldeándolo poco a poco hasta que tomaba forma. Se me enseñó que la depuración es una especie de paso final en el que se corrigen errores y descuidos. Por la forma en que en que yo trabajaba parecía que la programación era pura depuración.

Durante mucho tiempo me sentí mal por esto, como alguna vez me sentí mal por no tomar el lápiz de la forma en que me enseñaron en la primaria. Si hubiese visto lo que hacían otros creadores, los pintores o los arquitectos, me hubiese dado cuenta de que eso que hacía tenía un nombre: bosquejar. Por lo que puedo decir, la forma en la que me enseñaron a programar en la universidad era totalmente incorrecta. Tienes que ir entendiendo los programas conforme los vas escribiendo, al igual que hacen los pintores y los arquitectos.

Darse cuenta de esto tiene implicaciones reales para el diseño de software. Significa que que un lenguaje debe ser, por encima de cualquier otra consideración, maleable. Un lenguaje de programación debe servir para pensar los programas y no para expresar programas que ya fueron pensados. Debe ser un lápiz, no un bolígrafo. El tipado estático sería una buena idea si la gente realmente escribiera programas tal como me enseñaron en la universidad. Pero no es la manera en que los hackers que conozco escriben sus programas. Necesitamos un lenguaje que nos permita borronear y garabatear y ensuciar, no un lenguaje en el que tienes que balancear en tu rodilla la taza de té del sistema de tipos mientras haces conversación cortés con esa tía vieja y estricta que es el compilador.

Ya que estamos con el tema del tipado estático, identificarnos con los creadores nos ahorraría otro problema que aflige a todas las ciencias: la envidia de las matemáticas. En las ciencias, todos creen secretamente que los matemáticos son más inteligentes que ellos. Pienso que los matemáticos también lo creen. En cualquier caso, el resultado es que los científicos pretenden que su trabajo se vea lo más matemático que se pueda. En la física eso probablemente no haga mucho daño, pero a medida que nos alejamos de las ciencias naturales, se vuelve más problemático.

Una página llena de formulas tiene un aspecto impresionante (Sugerencia: para hacerlo aún más impresionante, use variables con letras griegas). Y por eso existe la gran tentación de trabajar con aquellos problemas que pueden ser tratados formalmente, en lugar de aquellos que son, digamos, importantes.

Si los hackers se identificaran con otros creadores, como escritores y pintores, serían inmunes a esta tentación. Los escritores y pintores no sufren de envidia matemática. Sienten que están haciendo algo que no tiene ninguna relación. Creo que es el mismo caso con los hackers.

Si universidades y centros de investigación impiden que los hackers hagan el trabajo que quieren hacer, tal vez su lugar esté con las empresas. Desafortunadamente la mayoría de las empresas tampoco dejan a los hackers hacer lo que quieren. Universidades y laboratorios obligan a los hackers a ser científicos y las empresas los obligan a ser ingenieros.

Yo descubrí esto muy recientemente. Cuando Yahoo compró Viaweb me preguntaron qué quería hacer. A mí nunca me gustó la parte administrativa y dije que yo lo que quería hacer era hackear. Cuando llegué a Yahoo me di cuenta que para ellos hackear significaba implementar software, no diseñarlo. Los programadores eran vistos como los técnicos que tomaban las visiones (si es esa la palabra adecuada) de los gerentes de producto y las traducían a código.

Ese parece ser el plan predeterminado para las grandes empresas. Lo hacen así para disminuir la desviación estándar de los resultados. Solo un pequeño porcentaje de los hackers puede realmente diseñar software y es difícil para la gente que dirige una compañía distinguirlos. Así que en lugar de poner el futuro del software en las manos de un hacker brillante, la mayoría de las compañías organizan las cosas de forma que el diseño se hace por comité y los hackers solamente implementan el diseño.

Si en algún momento quieres hacer dinero, recuerda esto, porque es una de las razones por las que los startup son mejores. Las grandes empresas quieren reducir la desviación estándar de los resultados del diseño porque quieren evitar desastres. Pero cuando amortiguas las oscilaciones pierdes los puntos altos al igual que los bajos. Esto no es un problema para las grandes empresas, porque no ganan creando productos excelentes, las grandes empresas ganan siendo menos peores que otras grandes empresas.

Así que si encuentras la forma de entrar en una guerra de diseño con una compañía tan grande que su software es diseñado por gerentes de producto, ellos nunca serán capaces de alcanzarte. Sin embargo, estas oportunidades no son fáciles de encontrar. Obligar a una compañía grande a entrar a una guerra de diseño es tan difícil como obligar que un oponente atrincherado en un castillo se enfrente a ti en el campo de batalla. Sería bastante fácil crear un procesador de texto que sea mejor que Microsoft Word, por ejemplo, pero si lo hicieras lo más probable es que Microsoft, desde su castillo que es el monopolio de los sistemas operativos, ni siquiera se enterara que lo hiciste.

Las guerras de diseño se llevan a cabo en los nuevos mercados, donde nadie ha logrado establecer aún ninguna fortificación. Es ahí donde puedes obtener grandes victorias mediante diseños audaces, y donde puedes tener a la misma gente diseñando e implementando el producto. La gente de Microsoft hizo esto al principio, al igual que la de Apple y Hewlett-Packard. Sospecho que casi todos los startups le han hecho así.

Así que una forma de construir software excelente es creando tu propio startup. Aunque hay dos problemas con esto. Una es que en un startup tienes muchas más responsabilidades que la de escribir software. En Viaweb me consideraba afortunado si lograba hackear una cuarta parte del tiempo y las otras tres cuartas partes tenía que hacer cosas que iban de lo tedioso a lo terrorífico. Tengo un buen punto de referencia al respecto, porque un día tuve que salirme de una junta de accionistas para que me pusieran una amalgama. Recuerdo que me senté en la silla del dentista esperando el taladro y sintiéndome como si estuviera de vacaciones.

El otro problema con los strartups es que no hay mucha intersección entre el software que hace dinero y el que es interesante de escribir. Es interesante escribir lenguajes de programación y el primer producto de Microsoft era de hecho un lenguaje, pero ya nadie paga por lenguajes de programación en estos días. Si quieres hacer dinero tiendes a verte forzado a trabajar en problemas que son demasiado desagradables como para que alguien quiera resolverlos gratuitamente.

Todos los creadores se enfrentan a este problema. Los precios son determinados por la oferta y la demanda y sencillamente no hay tanta demanda para cosas que son divertidas como la que hay para resolver problemas mundanos para clientes individuales. Actuar en una producción teatral independiente sencillamente no paga tan bien como vestir un traje de gorila en el stand de una feria. Escribir novelas no paga tan bien como escribir anuncios para trituradores de basura. Y trabajar en lenguajes de programación no paga tan bien como encontrar la forma de conectar la arcaica base de datos de una compañía a su servidor Web.

Creo que la solución a este problema, en el caso del software, es un concepto conocido para casi todos los creadores: el “trabajo de día” o trabajo para pagar las cuentas. La frase surgió entre los músicos, que actúan de noche. De forma más general significa que hay una clase de trabajo que haces por dinero y otra que haces por amor.

Casi todos los creadores tienen estas clases de trabajo al principio de sus carreras. Los pintores y los escritores son conocidos por ello. Si tienes suerte puedes conseguir un trabajo estrechamente relacionado con tu trabajo real. Los músicos a menudo trabajan en tiendas de discos. Un hacker que trabaja en el desarrollo de un lenguaje o sistema operativo puede, de la misma forma, encontrar trabajo usándolos. [1]

Cuando digo que la solución es que los hackers tengan trabajos formales, mientras desarrollan paralelamente software bello, no estoy proponiendo una idea novedosa. De eso se trata precisamente el software libre. Lo que estoy diciendo es que el software libre es probablemente el modelo correcto, porque tenemos confirmación independiente de otros creadores de que la idea funciona.

Me sorprende que hayan empleadores que no quieran dejar que sus hackers participen en proyectos de software libre. En Viaweb, hubiésemos dudado en contratar a alguien que no lo hiciera. Cuando entrevistábamos programadores, nuestro principal interés era ver qué clase de software escribían en su tiempo libre. No puedes hacer algo verdaderamente bien a menos que lo ames, y si te gusta hackear inevitablemente trabajarás en proyectos propios. [2]

Ya que los hackers son más creadores que científicos, el lugar correcto para buscar metáforas no está en las ciencias sino entre los otros creadores. ¿Qué otras cosas nos puede enseñar la pintura a los Hackers?

Una cosa que podemos aprender, o al menos confirmar, a partir del ejemplo de la pintura, es aprender a hackear. Se aprende a pintar principalmente mediante la práctica. De la misma forma aprende un hacker. La mayoría no aprenden tomando cursos de programación en la universidad. Aprenden a hackear escribiendo programas por su cuenta desde los trece años. Incluso en los cursos universitarios es practicando como aprendes a hackear. [3]

Dado que los pintores dejan un rastro de obras tras de sí, puedes ver como aprenden mediante la práctica. Si miras la obra de un pintor en orden cronológico verás que cada pintura retoma el aprendizaje conseguido en obras anteriores. Cuando hay algo que funciona muy bien en una pintura, normalmente encontrarás una primera versión, menos desarrollada, en una pintura anterior.

Creo que para la mayoría de los creadores funciona así. Parece ser que también es cierto para escritores y arquitectos. Tal vez sería bueno para los hackers actuar más como pintores y regularmente recomenzar desde cero, en vez de continuar trabajando por años en un proyecto y tratar de incorporar las ideas posteriores como revisiones.

El hecho de que los hackers aprendan a programar programando, es otra señal de las diferencias entre hackear y hacer ciencia. Los científicos no aprenden a hacer ciencia haciendo ciencia, sino haciendo prácticas de laboratorios y conjuntos de ejercicios. Los científicos comienzan haciendo un trabajo que ya es perfecto, en el sentido de que solo tratan de reproducir un trabajo que alguien ya hizo por ellos antes. Eventualmente llegan al punto en el que pueden producir trabajos originales. Los hackers, en cambio, están haciendo trabajo original desde el principio, lo que pasa es que les sale bastante mal. Así que los hackers comienzan siendo originales y después se vuelven buenos mientras que los científicos comienzan siendo buenos y después se vuelven originales.

Otra forma de aprender propia de los creadores es el seguir ejemplos. Para un pintor un museo es un catálogo de técnicas. Durante cientos de años copiar las obras de los grandes maestros ha sido parte de la educación tradicional de los pintores, porque copiar te obliga a prestar atención a la forma de hacer pintura.

Los escritores también hacen esto. Benjamin Franklin aprendió a escribir resumiendo las ideas principales de los ensayos de Addison y Steele e intentando luego reproducirlos. Raymon Chandler hizo lo mismo con novelas de detectives.

Los hackers, de la misma forma, pueden aprender a programar revisando buenos programas– no sólo revisar su funcionamiento sino también su código fuente. Una de las ventajas menos conocidas del movimiento del software libre es que ha hecho más fácil aprender a programar. Cuando yo aprendí a programar teníamos que apoyarnos principalmente en los ejemplos que venían en los libros. El conjunto de código más grande que estaba disponible era Unix, pero ni siquiera era código abierto. La mayoría de los que leían el código lo hacían con fotocopias ilegales del libro de John Lions que, aunque fue escrito en 1977, se pudo publicar hasta 1996.

Otro ejemplo que podemos tomar de la pintura es la forma en que las pinturas son creadas, mediante un proceso de refinamiento gradual. Las pinturas por lo general comienzan con un boceto. Poco a poco se les van añadiendo detalles. Pero el proceso no consiste únicamente en ir añadiendo elementos. Hay muchas pinturas que, si las analizas con rayos X, resultan tener extremidades desplazadas o rasgos faciales que fueron reajustados.

He aquí un caso en el que podemos aprender de la pintura. Pienso que hackear debería funcionar de la misma forma. Esperar que las especificaciones de un programan sean perfectas es poco realista. Es mejor admitirlo desde un principio y escribir programas de una forma que nos permita hacer modificaciones sobre la marcha.

(La estructura de las grandes compañías les dificulta lograr esto, así que aquí también los startup llevan ventaja).

A estas alturas todo el mundo está consiente de los peligros de la optimización prematura. Creo que deberíamos estar igual de preocupados por el diseño prematuro– decidir demasiado pronto lo que un programa hará.

Las herramientas adecuadas nos pueden ayudar a evitar este peligro. Un buen lenguaje de programación, al igual que el óleo en la pintura, debe permitirnos cambiar de opinión fácilmente. El tipado dinámico representa una victoria en este caso, porque no te compromete con una representación específica de los datos desde el principio. Pero la verdadera clave de la flexibilidad, pienso yo, es crear lenguajes muy abstractos. Los programas más fáciles de modificar son aquellos que son más cortos.

Lo que sigue va a sonar paradójico, pero una gran pintura tiene que ser mucho mejor de lo que está obligada a ser. Por ejemplo, cuando Leonardo pintó el retrato de Ginevra de Benci (exhibido en la National Gallery), puso un arbusto de enebro detrás de su cabeza. En él pintó cuidadosamente cada hoja, una por una. Muchos pintores habrían pensado “Es un detalle secundario cuya única función es enmarcar la cabeza, nadie va a fijarse en él”.

Retrato de Ginevra de Benci. Leonardo da Vinci, h. 1474-1476

Retrato de Ginevra de Benci. Leonardo da Vinci, h. 1474-1476

Pero no Leonardo. El esfuerzo que le imprimía a cada detalle de una pintura no dependía de cuán fijamente esperaba que fuera visto. Era como Michael Jordan, implacable.

Ese “ser implacable” funciona  porque, en conjunto, los pequeños detalles se hacen notorios. Cuando la gente pasa junto al retrato de Ginevra de Benci, su atención a menudo queda atrapada, incluso antes de leer la cédula y darse cuenta que dice “Leonardo da Vinci”. Todos esos detalles insignificantes se combinan para producir algo que es simplemente impresionante, como si miles de voces, casi inaudibles, cantaran al unísono.

Las grandes aplicaciones también requieren una devoción fanática por la belleza. Si buscamos en el interior de un buen software encontraremos partes que nadie tendría que ver y, sin embargo, son bellas. No estoy diciendo que yo escriba software genial, pero me enfrento al código de un modo tal que se me obligaría a tomar medicamentos si enfrentara la vida cotidiana de la misma forma. Me vuelve loco ver código mal alineado o variables que tienen nombres feos.

Si el hacker fuera un mero ejecutor, convirtiendo especificaciones en código, podría rutinariamente hacer su trabajo de principio a fin, como quien cava una zanja. Pero el hacker es un creador y por lo tanto la inspiración tiene que tomarse en cuenta.

En la labor del hacker, como en la pintura, el trabajo viene en ciclos. A veces estás muy emocionado por un nuevo proyecto y quieres trabajar en él dieciséis horas al día. Otras veces nada te resulta interesante.

Para hacer un buen trabajo hay que tomar en cuenta estos ciclos, ya que la forma en que reaccionamos a ellos nos influye. Cuando cuando conduces cuesta arriba usando transmision estándar tienes, a veces, que meter el embrague para evitar que el coche se atasque. Retroceder un poco puede ser necesario para evitar que la ambición se atasque. En la pintura y en la programación hay tareas que son aterradoramente ambiciosas y otras que son cómodamente rutinarias. Es una buena idea guardar algunas tareas sencillas para aquellos momentos en los que normalmente te atorarías.

Para el hacker, esto puede significar literalmente tener una reserva de bugs. Me gusta buscar bugs: es una de las veces en las que hackear es tan lineal como la gente piensa. Se te da un problema perfectamente especificado y lo único que tienes que hacer es resolverlo. Tu programa tiene que hacer X. En lugar de eso hace Y. ¿En dónde está el error? Tú sabes que al final vas a salir victorioso. Es tan relajante como pintar un muro con brocha gorda

Bautismo de Cristo. Verrocchio, h. 1475-1478

Bautismo de Cristo. Verrocchio, h. 1475-1478

El ejemplo de la pintura nos enseña no sólo a administrar nuestro trabajo, también nos puede enseñar a trabajar en equipo. Muchas de las grandes obras de arte del pasado son el trabajo de varias manos, aunque puede que sólo encuentres un nombre en la cédula del museo. Leonardo fue aprendiz en el taller de Verrochio y pintó uno de los ángeles en su Bautismo de Cristo. Ésta clase de colaboración era la norma, no la excepción. A Miguel Ángel se le consideraba extremadamente dedicado por su insistencia en pintar él mismo todas las figuras del techo de la Capilla Sixtina.

Hasta dónde yo sé, cuando los pintores colaboraban en una pintura, nunca trabajaban en las mismas partes. Era común que el maestro pintara las figuras principales y que sus asistentes pintaran el fondo y las figuras restantes. Pero nunca ocurría que alguien pintara encima del trabajo de otra persona.

Creo que este también es el modelo adecuado para la colaboración en software. No hay que exagerar. Cuando un segmento del código está siendo hackeado por tres o cuatro personas, sin que le pertenezca a nadie, terminará como el “cuarto de usos múltiples”. Tenderá a verse triste y abandonado, y se amontonarán cosas  en él. La forma correcta de colaborar, a mi parecer, es dividir los proyectos en módulos bien definidos, cada uno con un propietario bien definido e interfaces entre ellos que estén bien definidas y que, de ser posible, estén tan bien articuladas como un lenguaje de programación.

Al igual que la pintura, casi todo el software está destinado a un público humano. Y los hackers, como los pintores, deben ser empáticos para que su trabajo sea realmente bueno. Debes ser capaz de ver las cosas desde el punto de vista del usuario.

Cuando era niño siempre se me dijo que tenía que mirar las cosas desde la perspectiva de otras personas. Lo que eso significaba en la práctica era que tenía que hacer lo que otros querían, en lugar de hacer lo que yo quería. Eso por su puesto le dio una mala reputación a la empatía y me esforcé por no cultivarla.

Pero ¡caramba! estaba equivocado. Resulta que mirar las cosas desde el punto de vista de otras personas es prácticamente el secreto del éxito. No necesariamente significa ser sacrificado, ni mucho menos. La comprensión de cómo ve las cosas otra persona no implica que actuarás en su interés, en algunos casos– como en la guerra, por ejemplo– quieres hacer exactamente lo contrario. [4]

La mayoría de los creadores están creando cosas para una audiencia humana. Y para cautivar a tu audiencia tienes que entender sus necesidades. Casi todas las grandes pinturas son pinturas de personas, por ejemplo, porque la gente está interesada en otra gente.

La empatía es, tal vez, la diferencia más importante entre un buen hacker y un hacker grandioso. Algunos hackers son muy inteligentes, pero en lo que respecta a la empatía son prácticamente solipsistas. Es díficil para una persona así diseñar un gran software [5], porque no pueden ver las cosas desde la perspectiva del usuario.

Una forma de evaluar la empatía de una persona es verlos explicar una cuestión técnica a una persona sin conocimiento técnico. Probablemente todos conozcamos a personas que, aunque por demás inteligentes, son cómicamente malos haciendo esto. Si alguien les pregunta en una cena qué es un lenguaje de programación, contestarán algo como “Oh, es un lenguaje de alto nivel que el compilador usa para generar código objeto”. ¿Lenguaje de alto nivel? ¿Compilador? ¿Código objeto? Es obvio que alguien que no sabe qué es un lenguaje de programación tampoco conoce esos conceptos.

Parte de la función del software es explicarse a sí mismo. Así que para escribir buen software tienes que entender lo poco que un usuario entiende. Van a enfrentarse al software sin preparación, y es mejor que haga lo que ellos creen que hará, porque no van a ponerse a leer el manual. En ese sentido el mejor sistema que he conocido fue la Macintosh original, en 1985. Hacía algo que el software casi nunca logra: funcionar. [6]

El código fuente, también, debe explicarse a sí mismo. Si yo pudiera hacer que la gente recordara al menos una cita sobre programación, sería aquella que está al inicio de Structure and Interpretation of Computer Programs.

Los programas deberían escribirse para que la gente los lea, y sólo fortuitamente para que las computadoras los ejecuten.

Debes empatizar no sólo con tus usuarios, sino también con tus lectores. Es en tu beneficio, porque tú eres uno de ellos. Más de un hacker a escrito un programa sólo para volver a él seis meses después y descubrir que no tiene idea de cómo funciona. Conozco varias personas que han renegado de Perl tras experiencias de ese tipo. [7]

La falta de empatía se asocia con la inteligencia, a tal grado que la falta de empatía es popular en algunos círculos. Pero no creo que exista ninguna correlación. Para ser bueno en matemáticas y ciencias no necesitas ser empático, y la gente en estas áreas tiende a ser inteligente, así que las dos cualidades han llegado a asociarse. Pero también hay un montón de gente tonta que carece de empatía. Basta con escuchar a las personas que llaman por teléfono a los programas de entrevistas. Hacen preguntas tan rebuscadas que a menudo los presentadores tienen que reformular la pregunta por ellos.
Así que, si el oficio del hacker se parece tanto al del pintor y el escritor ¿es igualmente cool?. A final de cuentas, sólo tienes una vida y bien podrías aprovecharla trabajando en algo grandioso.

Federico_da_Montefeltro

Retrato del duque de Urbino. Piero della Francesca, 1472

Por desgracia, es una pregunta difícil de contestar. El prestigio siempre llegará con un gran retraso. Como la luz de una estrella distante. La pintura es prestigiosa ahora gracias al trabajo que algunas personas llevaron a cabo hace quinientos años. En esa época nadie pensaba que las pinturas llegarían a ser tan importantes como son ahora. Le hubiese parecido muy extraño a la gente de la época que Federico da Montefeltro, Duque de Urbino, fuera un día a ser más conocido como el tipo de la nariz rara en el retrato de Piero della Francesca.

Asi que, aunque admito que en este momento hackear no sea tan cool como pintar, debemos recordar que la pintura misma no parecía tan cool en sus días de gloria como lo parece ahora.

Lo que podemos decir con algo de confianza es que estamos viviendo la época dorada de los hackers. En la mayoría de los campos las grandes obras son creadas en los inicios. Las pinturas creadas entre 1430 y 1500 siguen siendo insuperables. Shakespeare apareció justo cuando el teatro profesional nacía, y amplió los límites del género de tal forma que cada dramaturgo desde 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 nos encontramos con el mismo patrón. Aparece un nuevo género y la gente se entusiasma tanto que exploran la mayoría de sus posibilidades durante las primeras dos generaciones. Nuestro medio parece pasar ahora por esa fase.

La pintura no era, en la época de Leonardo, tan increíble como su trabajo la hizo ser. El que hackear llegue a ser increíble dependerá de lo que logremos con este nuevo medio.



Notas

[1] El mayor daño que la fotografía le inflingió a la pintura es, probablemente, el haberle matado su mejor empleo. La mayoría de los grandes pintores de la historia se ganaban la vida pintando retratos.

[2] Me han dicho que Microsoft se opone a que sus empleados participen en proyectos de código abierto, incluso si lo hacen en su tiempo libre. Pero entre los mejores hackers hay tantos que colaboran en dichos proyectos que están garantizando que no podrán contratar a gente de primer nivel.

[3] Lo que aprendes de programación en la universidad se parece a lo que aprendes sobre libros, ropa o romance: aprendes que en la preparatoria tenías muy mal gusto.

[4] He aquí un ejemplo de empatía aplicada. Si en Viaweb tenías problemas eligiendo entre entre dos alternativas, nos preguntábamos ¿Qué es lo que les disgustaría más a nuestros competidores? En algún momento un competidor le añadió a su software una función básicamente inútil pero, como era una de las pocas funciones que ellos tenían y nosostros no, hicieron grandes aspavientos ante la prensa especializada. Podríamos haber tratado de explicar que era una función inútil. pero decidimos que a nuestro competidor se molestaría más si simplemente lo implementáramos nosotros, así que hackeamos nuestra propia versión esa tarde.

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

[6] Bueno, casi. Requerían más RAM del que había disponible y eso provocaba cambios de discos frecuentes e inconvenientes, pero eso se podía arreglar comprando un disco duro adicional algunos meses después.

[7] La forma de escribir programas fáciles de leer no es atiborrarlos de comentarios. Quisiera llevar la cita de Abelson y Sussman un poco más lejos. Los lenguajes de programación deberían estar diseñados para expresar algoritmos y sólo fortuitamente para decirles a las computadoras cómo ejecutarlos. Un buen lenguaje de programación debería ser superior al lenguaje natural a la hora de explicar el software. La única función de los comentarios debería ser advertir a los usuarios sobre alguna solución improvisada y torpe, igual que en una carretera sólo encuentras letreros con flechas antes de curvas inesperadas y pronunciadas.

Qusiera agradecer a Trevor Blackwell, Robert Morris, Dan Giffin, y Lisa Randall por leer los borradores, y a Henry Leitner y Larry Finkelstein por invitarme a dar la charla.

Ensayo original (en inglés)

2 comentarios en “Hackers y pintores

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s