GRANDES HACKERS

Julio 2004

(Este ensayo se deriva de una charla en Oscon 2004.)

Hace unos meses terminé un nuevo libro, y en las reseñas sigo notando palabras como "provocativo" y "controvertido". Por no hablar de "idiota".

No pretendía hacer que el libro fuera controvertido. Estaba tratando de hacerlo eficiente. No quería perder el tiempo diciéndoles cosas que ya sabían. Es más eficiente simplemente darles las diferencias. Pero supongo que eso está destinado a producir un libro alarmante.

Edisons

No hay controversia sobre cuál es la idea más controvertida: la sugerencia de que la variación en la riqueza podría no ser tan grande problema como pensamos.

No dije en el libro que la variación en la riqueza fuera en sí misma una cosa buena. Dije que en algunas situaciones podría ser una señal de cosas buenas. Un dolor de cabeza palpitante no es algo bueno, pero puede ser una señal de algo bueno, por ejemplo, que te estás recuperando la conciencia después de que te golpearon en la cabeza.

La variación en la riqueza puede ser una señal de variación en la productividad. (En una sociedad de uno, son idénticos). Y eso es casi con toda seguridad algo bueno: si tu sociedad no tiene variación en la productividad, probablemente no es porque todos son Thomas Edison. Probablemente es porque no tienes Thomas Edisons.

En una sociedad de baja tecnología no se ve mucha variación en la productividad. Si tienes una tribu de nómadas recogiendo palos para una hoguera, ¿cuánto más productivo será el mejor recolector de palos que el peor? ¿Un factor de dos? Mientras que cuando le das a la gente una herramienta compleja como una computadora, la variación en lo que pueden hacer con ella es enorme.

Esa no es una idea nueva. Fred Brooks escribió sobre ello en 1974, y el estudio que citó se publicó en 1968. Pero creo que subestimó la variación entre los programadores. Escribió sobre la productividad en líneas de código: los mejores programadores pueden resolver un problema dado en una décima parte del tiempo. Pero ¿y si el problema no se da? En la programación, al igual que en muchos campos, la parte difícil no es resolver problemas, sino decidir qué problemas resolver. La imaginación es difícil de medir, pero en la práctica domina el tipo de productividad que se mide en líneas de código.

La productividad varía en cualquier campo, pero hay pocos en los que varía tanto. La variación entre los programadores es tan grande que se convierte en una diferencia de grado. No creo que esto sea algo intrínseco a la programación, sin embargo. En todos los campos, la tecnología amplifica las diferencias de productividad. Creo que lo que está sucediendo en la programación es simplemente que tenemos mucho apalancamiento tecnológico. Pero en todos los campos la palanca se está alargando, por lo que la variación que vemos es algo que más y más campos verán a medida que pase el tiempo. Y el éxito de las empresas y los países dependerá cada vez más de cómo lo manejen.

Si la variación en la productividad aumenta con la tecnología, entonces la contribución de los individuos más productivos no solo será desproporcionadamente grande, sino que de hecho crecerá con el tiempo. Cuando llegas al punto en que el 90% de la producción de un grupo la crea el 1% de sus miembros, pierdes mucho si algo (ya sean los saqueos vikingos o la planificación central) reduce su productividad al promedio.

Si queremos sacar el máximo provecho de ellos, necesitamos entender a estas personas especialmente productivas. ¿Qué los motiva? ¿Qué necesitan hacer su trabajo? ¿Cómo los reconoces? ¿Cómo los haces venir a trabajar para ti? Y luego, por supuesto, está la pregunta, ¿cómo te conviertes en uno?

Más que dinero

Conozco a un puñado de super-hackers, así que me senté y pensé en qué tienen en común. Su cualidad definitoria es probablemente que realmente les encanta programar. Los programadores comunes escriben código para pagar las facturas. Los grandes hackers lo consideran algo que hacen por diversión, y que se alegran de encontrar que la gente les paga por ello.

A veces se dice que los grandes programadores son indiferentes al dinero. Esto no es del todo cierto. Es cierto que lo único que realmente les importa es hacer un trabajo interesante. Pero si ganas lo suficiente, puedes trabajar en lo que quieras, y por esa razón los hackers sí se sienten atraídos por la idea de ganar cantidades realmente grandes de dinero. Pero mientras todavía tengan que presentarse a trabajar todos los días, les importa más lo que hacen allí que cuánto les pagan por ello.

Económicamente, este es un hecho de la mayor importancia, porque significa que no tienes que pagar a los grandes hackers ni siquiera cerca de lo que valen. Un gran programador puede ser diez o cien veces más productivo que uno normal, pero se considerará afortunado si le pagan tres veces más. Como explicaré más adelante, esto se debe en parte a que los grandes hackers no saben lo buenos que son. Pero también se debe a que el dinero no es lo principal que quieren.

¿Qué quieren los hackers? Como todos los artesanos, a los hackers les gustan las buenas herramientas. De hecho, eso es quedarse corto. A los buenos hackers les resulta insoportable usar malas herramientas. Simplemente se negarán a trabajar en proyectos con la infraestructura equivocada.

En una startup para la que trabajé una vez, uno de los elementos colgados en nuestro tablón de anuncios era un anuncio de IBM. Era una imagen de un AS400, y el titular decía, creo, "los hackers lo desprecian". [1]

Cuando decides qué infraestructura usar para un proyecto, no estás tomando solo una decisión técnica. También estás tomando una decisión social, y esta puede ser la más importante de las dos. Por ejemplo, si tu empresa quiere escribir un software, podría parecer una elección prudente escribirlo en Java. Pero cuando eliges un lenguaje, también estás eligiendo una comunidad. Los programadores que podrás contratar para trabajar en un proyecto de Java no serán tan inteligentes como los que podrías conseguir para trabajar en un proyecto escrito en Python. Y la calidad de tus hackers probablemente importe más que el lenguaje que elijas. Aunque, francamente, el hecho de que los buenos hackers prefieran Python a Java debería decirte algo sobre los méritos relativos de esos lenguajes.

Los tipos de negocios prefieren los idiomas más populares porque los ven como estándares. No quieren apostar la empresa en Betamax. Lo que pasa con los idiomas, sin embargo, es que no son solo estándares. Si tienes que mover bits a través de una red, por todos los medios usa TCP/IP. Pero un lenguaje de programación no es solo un formato. Un lenguaje de programación es un medio de expresión.

He leído que Java acaba de superar a Cobol como el lenguaje más popular. Como estándar, no podrías pedir más. Pero como medio de expresión, podrías hacerlo mucho mejor. De todos los grandes programadores que puedo pensar, solo conozco a uno que programaría voluntariamente en Java. Y de todos los grandes programadores que conozco que no trabajan para Sun, en Java, no conozco a ninguno.

Los grandes hackers también generalmente insisten en usar software de código abierto. No solo porque es mejor, sino porque les da más control. Los buenos hackers insisten en el control. Esto es parte de lo que los hace buenos hackers: cuando algo está roto, necesitan arreglarlo. Quieres que se sientan así acerca del software que están escribiendo para ti. No deberías sorprenderte cuando sientan lo mismo sobre el sistema operativo.

Hace un par de años, un amigo capitalista de riesgo me contó sobre una nueva startup en la que estaba involucrado. Sonaba prometedor. Pero la próxima vez que hablé con él, dijo que habían decidido construir su software en Windows NT y acaban de contratar a un desarrollador de NT muy experimentado para que fuera su director técnico principal. Cuando escuché esto, pensé que estos tipos están condenados. Uno, el director técnico no podría ser un hacker de primera categoría, porque para convertirse en un desarrollador de NT eminente tendría que haber usado NT voluntariamente, varias veces, y no podía imaginar a un gran hacker haciendo eso; y dos, incluso si era bueno, tendría dificultades para contratar a alguien bueno para que trabajara para él si el proyecto tenía que construirse en NT. [2]

La Frontera Final

Después del software, la herramienta más importante para un hacker probablemente sea su oficina. Las grandes empresas piensan que la función del espacio de oficina es expresar rango. Pero los hackers usan sus oficinas para más que eso: las usan como un lugar para pensar. Y si eres una empresa de tecnología, sus pensamientos son tu producto. Entonces hacer que los hackers trabajen en un ambiente ruidoso y distractivo es como tener una fábrica de pintura donde el aire está lleno de hollín.

La tira cómica Dilbert tiene mucho que decir sobre los cubículos, y con razón. Todos los hackers que conozco los desprecian. La mera perspectiva de ser interrumpido es suficiente para evitar que los hackers trabajen en problemas difíciles. Si quieres que se haga un trabajo real en una oficina con cubículos, tienes dos opciones: trabajar en casa o llegar temprano o tarde o en un fin de semana, cuando no hay nadie más allí. ¿No se dan cuenta las empresas de que esto es una señal de que algo está roto? Un ambiente de oficina se supone que es algo que te ayuda a trabajar, no algo con lo que trabajas a pesar de ello.

Empresas como Cisco se enorgullecen de que todos allí tengan un cubículo, incluso el CEO. Pero no son tan avanzados como creen; obviamente aún ven el espacio de oficina como una insignia de rango. Tenga en cuenta también que Cisco es famosa por desarrollar muy poco producto internamente. Obtienen nueva tecnología comprando las startups que la crearon, donde presumiblemente los hackers sí tenían un lugar tranquilo para trabajar.

Una gran empresa que entiende lo que necesitan los hackers es Microsoft. Una vez vi un anuncio de reclutamiento de Microsoft con una gran imagen de una puerta. Trabaja para nosotros, era la premisa, y te daremos un lugar para trabajar donde realmente puedas hacer el trabajo. Y sabes, Microsoft es notable entre las grandes empresas en que son capaces de desarrollar software internamente. No bien, quizás, pero lo suficientemente bien.

Si las empresas quieren que los hackers sean productivos, deberían mirar lo que hacen en casa. En casa, los hackers pueden arreglar las cosas ellos mismos para poder hacer lo más posible. Y cuando trabajan en casa, los hackers no trabajan en espacios ruidosos y abiertos; trabajan en habitaciones con puertas. Trabajan en lugares acogedores y vecinales con gente alrededor y en algún lugar para caminar cuando necesitan reflexionar sobre algo, en lugar de en cajas de cristal establecidas en acres de estacionamientos. Tienen un sofá en el que pueden echar una siesta cuando se sienten cansados, en lugar de sentarse en un coma en su escritorio, fingiendo trabajar. No hay un equipo de personas con aspiradoras que ruge a través de cada noche durante las horas pico de hackeo. No hay reuniones o, Dios no lo quiera, retiros corporativos o ejercicios de trabajo en equipo. Y cuando miras lo que están haciendo en esa computadora, encontrarás que refuerza lo que dije antes sobre las herramientas. Es posible que tengan que usar Java y Windows en el trabajo, pero en casa, donde pueden elegir por sí mismos, es más probable que los encuentres usando Perl y Linux.

De hecho, estas estadísticas sobre Cobol o Java siendo el idioma más popular pueden ser engañosas. Lo que deberíamos mirar, si queremos saber qué herramientas son las mejores, es qué eligen los hackers cuando pueden elegir libremente, es decir, en proyectos propios. Cuando haces esa pregunta, encuentras que los sistemas operativos de código abierto ya tienen una cuota de mercado dominante, y el lenguaje número uno probablemente sea Perl.

Interesante

Junto con buenas herramientas, los hackers quieren proyectos interesantes. ¿Qué hace que un proyecto sea interesante? Bueno, obviamente, las aplicaciones abiertamente sexys como los aviones furtivos o el software de efectos especiales serían interesantes de trabajar. Pero cualquier aplicación puede ser interesante si plantea nuevos desafíos técnicos. Entonces es difícil predecir qué problemas les gustarán a los hackers, porque algunos se vuelven interesantes solo cuando las personas que trabajan en ellos descubren un nuevo tipo de solución. Antes de ITA (quienes escribieron el software dentro de Orbitz), las personas que trabajaban en las búsquedas de tarifas aéreas probablemente pensaban que era una de las aplicaciones más aburridas que se puedan imaginar. Pero ITA lo hizo interesante al redefinir el problema de una manera más ambiciosa.

Creo que lo mismo sucedió en Google. Cuando se fundó Google, la sabiduría convencional entre los llamados portales era que la búsqueda era aburrida e insignificante. Pero los chicos de Google no pensaban que la búsqueda fuera aburrida, y por eso lo hacen tan bien.

Esta es un área donde los gerentes pueden marcar la diferencia. Como un padre diciéndole a un hijo, apuesto a que no puedes limpiar toda tu habitación en diez minutos, un buen gerente a veces puede redefinir un problema como uno más interesante. Steve Jobs parece ser particularmente bueno en esto, en parte simplemente por tener altos estándares. Hubo muchas computadoras pequeñas y baratas antes del Mac. Él redefinió el problema como: hacer una que sea hermosa. Y eso probablemente impulsó a los desarrolladores más de lo que cualquier zanahoria o palo podría.

Ciertamente lo lograron. Cuando el Mac apareció por primera vez, ni siquiera tenías que encenderlo para saber que sería bueno; podías decirlo por la carcasa. Hace unas semanas caminaba por la calle en Cambridge y en la basura de alguien vi lo que parecía ser un estuche para transportar un Mac. Miré adentro y había un Mac SE. Lo llevé a casa y lo enchufé, y se inició. La feliz cara de Macintosh y luego el Finder. Dios mío, era tan simple. Era como... Google.

A los hackers les gusta trabajar para personas con altos estándares. Pero no basta con ser exigente. Tienes que insistir en las cosas correctas. Lo que generalmente significa que tienes que ser un hacker tú mismo. He visto algunos artículos ocasionales sobre cómo gestionar a los programadores. En realidad debería haber dos artículos: uno sobre qué hacer si tú mismo eres un programador, y otro sobre qué hacer si no lo eres. Y el segundo probablemente se podría resumir en dos palabras: rendirse.

El problema no es tanto la gestión diaria. Los hackers realmente buenos son prácticamente autogestionados. El problema es que, si no eres un hacker, no puedes saber quiénes son los buenos hackers. Un problema similar explica por qué los automóviles estadounidenses son tan feos. Lo llamo la paradoja del diseño. Podrías pensar que podrías hacer que tus productos sean hermosos simplemente contratando a un gran diseñador para diseñarlos. Pero si tú mismo no tienes buen gusto, ¿cómo vas a reconocer a un buen diseñador? Por definición, no puedes saberlo por su portafolio. Y no puedes guiarte por los premios que ha ganado o los trabajos que ha tenido, porque en el diseño, como en la mayoría de los campos, tienden a estar impulsados por la moda y el enchufe, con la capacidad real en tercer lugar. No hay forma de evitarlo: no puedes gestionar un proceso destinado a producir cosas hermosas sin saber qué es lo hermoso. Los automóviles estadounidenses son feos porque las empresas automovilísticas estadounidenses están dirigidas por personas con mal gusto.

Mucha gente en este país considera que el gusto es algo elusivo o incluso frívolo. No lo es. Para impulsar el diseño, un gerente debe ser el usuario más exigente de los productos de una empresa. Y si tienes un gusto realmente bueno, puedes, como Steve Jobs, hacer que satisfacerte sea el tipo de problema en el que a la gente buena le gusta trabajar.

Pequeños Problemas Desagradables

Es bastante fácil decir qué tipos de problemas no son interesantes: aquellos en los que en lugar de resolver unos pocos problemas grandes y claros, tienes que resolver una gran cantidad de pequeños problemas desagradables. Uno de los peores tipos de proyectos es escribir una interfaz para un software lleno de errores. Otro es cuando tienes que personalizar algo para las necesidades complejas y mal definidas de un cliente individual. Para los hackers, este tipo de proyectos son la muerte de mil cortes.

La característica distintiva de los pequeños problemas desagradables es que no aprendes nada de ellos. Escribir un compilador es interesante porque te enseña qué es un compilador. Pero escribir una interfaz para un software con errores no te enseña nada, porque los errores son aleatorios. [3] Así que no se trata solo de ser exigente lo que hace que los buenos hackers eviten los pequeños problemas desagradables. Es más una cuestión de autoconservación. Trabajar en pequeños problemas desagradables te vuelve estúpido. Los buenos hackers lo evitan por la misma razón que los modelos evitan las hamburguesas con queso.

Por supuesto, algunos problemas tienen inherentemente este carácter. Y debido a la oferta y la demanda, pagan especialmente bien. Entonces, una empresa que encontrara una manera de hacer que los grandes hackers trabajaran en problemas tediosos sería muy exitosa. ¿Cómo lo harías?

Un lugar donde esto sucede es en las startups. En nuestra startup teníamos a Robert Morris trabajando como administrador de sistemas. Eso es como tener a los Rolling Stones tocando en un bar mitzvah. No puedes contratar ese tipo de talento. Pero la gente hará cualquier cantidad de trabajos tediosos por empresas de las que son fundadores. [4]

Las empresas más grandes resuelven el problema dividiendo la empresa. Consiguen que la gente inteligente trabaje para ellos estableciendo un departamento de I+D separado donde los empleados no tienen que trabajar directamente en los pequeños problemas desagradables de los clientes. [5] En este modelo, el departamento de investigación funciona como una mina. Producen nuevas ideas; tal vez el resto de la empresa pueda usarlas.

Puede que no tengas que llegar a este extremo. La programación ascendente sugiere otra forma de dividir la empresa: hacer que las personas inteligentes trabajen como fabricantes de herramientas. Si tu empresa fabrica software para hacer x, haz que un grupo construya herramientas para escribir software de ese tipo, y otro que use estas herramientas para escribir las aplicaciones. De esta manera, podrías lograr que la gente inteligente escriba el 99% de tu código, pero aún mantenerlos casi tan aislados de los usuarios como lo estarían en un departamento de investigación tradicional. Los fabricantes de herramientas tendrían usuarios, pero serían solo los propios desarrolladores de la empresa. [6]

Si Microsoft usara este enfoque, su software no tendría tantos agujeros de seguridad, porque las personas menos inteligentes que escriben las aplicaciones reales no estarían haciendo cosas de bajo nivel como asignar memoria. En su lugar, estarían ensamblando grandes bloques de Lego del lenguaje de Word. (Duplo, creo que es el término técnico).

Agrupamiento

Junto con los problemas interesantes, lo que les gusta a los buenos hackers son otros buenos hackers. Los grandes hackers tienden a agruparse, a veces de manera espectacular, como en Xerox Parc. Así que no atraerás a los buenos hackers en proporción lineal a lo bueno que sea el entorno que crees para ellos. La tendencia a agruparse significa que es más como el cuadrado del entorno. Así que es ganar o perder. En cualquier momento dado, solo hay alrededor de diez o veinte lugares donde los hackers más quieren trabajar, y si no eres uno de ellos, no solo tendrás menos grandes hackers, sino que tendrás cero.

Tener grandes hackers no es, por sí solo, suficiente para hacer que una empresa tenga éxito. Funciona bien para Google e ITA, que son dos de los puntos calientes en este momento, pero no ayudó a Thinking Machines o Xerox. Sun tuvo un buen recorrido por un tiempo, pero su modelo de negocio es un ascensor descendente. En esa situación, incluso los mejores hackers no pueden salvarte.

Creo, sin embargo, que todas las demás cosas siendo iguales, una empresa que pueda atraer a grandes hackers tendrá una enorme ventaja. Hay personas que discrepan de esto. Cuando estábamos haciendo las rondas de las firmas de capital de riesgo en la década de 1990, varios nos dijeron que las empresas de software no ganaban escribiendo un gran software, sino a través de la marca, dominando los canales y haciendo los acuerdos correctos.

Realmente parecían creer esto, y creo saber por qué. Creo que lo que muchos capitalistas de riesgo están buscando, al menos inconscientemente, es el próximo Microsoft. Y por supuesto, si Microsoft es tu modelo, no deberías estar buscando empresas que esperan ganar escribiendo un gran software. Pero los capitalistas de riesgo se equivocan al buscar el próximo Microsoft, porque ninguna startup puede ser el próximo Microsoft a menos que otra empresa esté dispuesta a inclinarse en el momento justo y ser el próximo IBM.

Es un error usar a Microsoft como modelo, porque toda su cultura se deriva de ese único golpe de suerte. Microsoft es un mal punto de datos. Si los eliminas, encuentras que los buenos productos tienden a ganar en el mercado. Lo que los capitalistas de riesgo deberían estar buscando es el próximo Apple o el próximo Google.

Creo que Bill Gates sabe esto. Lo que le preocupa de Google no es el poder de su marca, sino el hecho de que tienen mejores hackers. [7]

Reconocimiento

Entonces, ¿quiénes son los grandes hackers? ¿Cómo sabes cuándo conoces a uno? Resulta ser muy difícil. Incluso los hackers no pueden decirlo. Ahora estoy bastante seguro de que mi amigo Trevor Blackwell es un gran hacker. Es posible que hayas leído en Slashdot cómo hizo su propio Segway. Lo notable de este proyecto fue que escribió todo el software en un solo día (en Python, por cierto).

Para Trevor, eso es pan comido. Pero cuando lo conocí por primera vez, pensé que era un completo idiota. Estaba parado en la oficina de Robert Morris balbuceando sobre algo o algo, y recuerdo estar parado detrás de él haciendo gestos frenéticos a Robert para que sacara a este loco de su oficina para que pudiéramos ir a almorzar. Robert dice que también juzgó mal a Trevor al principio. Al parecer, cuando Robert lo conoció por primera vez, Trevor acababa de comenzar un nuevo esquema que consistía en anotar todo sobre cada aspecto de su vida en una pila de fichas, que llevaba consigo a todas partes. También acababa de llegar de Canadá y tenía un fuerte acento canadiense y un mullet.

El problema se ve agravado por el hecho de que los hackers, a pesar de su reputación de indiferencia social, a veces se esfuerzan mucho por parecer inteligentes. Cuando estaba en la escuela de posgrado, solía pasar el rato ocasionalmente en el MIT AI Lab. Al principio era un poco intimidante. Todos allí hablaban tan rápido. Pero después de un tiempo aprendí el truco de hablar rápido. No tienes que pensar más rápido; simplemente usa el doble de palabras para decir todo.

Con esta cantidad de ruido en la señal, es difícil reconocer a los buenos hackers cuando los conoces. No puedo decirlo, ni siquiera ahora. Tampoco puedes decirlo por sus currículums. Parece que la única forma de juzgar a un hacker es trabajar con él en algo.

Y esta es la razón de que las áreas de alta tecnología solo sucedan alrededor de las universidades. El ingrediente activo aquí no son tanto los profesores como los estudiantes. Las startups crecen alrededor de las universidades porque las universidades reúnen a jóvenes prometedores y los hacen trabajar en los mismos proyectos. Los más inteligentes aprenden quiénes son los otros más inteligentes, y juntos cocinan nuevos proyectos propios.

Debido a que no puedes saber si un gran hacker es tal excepto trabajando con él, los propios hackers no pueden saber qué tan buenos son. Esto es cierto en cierta medida en la mayoría de los campos. He descubierto que las personas que son geniales en algo no están tanto convencidas de su propia grandeza como perplejas por qué todos los demás parecen tan incompetentes.

Pero es particularmente difícil para los hackers saber qué tan buenos son, porque es difícil comparar su trabajo. Esto es más fácil en la mayoría de los otros campos. En los cien metros, sabes en 10 segundos quién es el más rápido. Incluso en matemáticas parece haber un consenso general sobre qué problemas son difíciles de resolver y qué constituye una buena solución. Pero el hackeo es como escribir. ¿Quién puede decir cuál de las dos novelas es mejor? Ciertamente no los autores.

Con los hackers, al menos, otros hackers pueden decirlo. Eso se debe a que, a diferencia de los novelistas, los hackers colaboran en proyectos. Cuando llegas a golpear algunos problemas difíciles a través de la red a alguien, aprendes bastante rápido qué tan duro te golpean de vuelta. Pero los hackers no pueden observarse a sí mismos mientras trabajan. Entonces, si le preguntas a un gran hacker qué tan bueno es, casi seguro que responderá: No lo sé. No es solo que sea modesto. Realmente no lo sabe.

Y ninguno de nosotros lo sabe, excepto sobre las personas con las que realmente hemos trabajado. Lo que nos pone en una situación extraña: no sabemos quiénes deberían ser nuestros héroes. Los hackers que se vuelven famosos tienden a volverse famosos por accidentes aleatorios de relaciones públicas. Ocasionalmente necesito dar un ejemplo de un gran hacker, y nunca sé a quién usar. Los primeros nombres que se me vienen a la mente siempre tienden a ser personas que conozco personalmente, pero parece aburrido usarlas. Entonces, pienso, tal vez debería decir Richard Stallman, o Linus Torvalds, o Alan Kay, o alguien famoso como esos. Pero no tengo idea de si estos tipos son grandes hackers. Nunca he trabajado con ellos en nada.

Si hay un Michael Jordan del hackeo, nadie lo sabe, ni siquiera él.

Cultivo

Finalmente, la pregunta que todos los hackers se han estado preguntando: ¿cómo se convierte uno en un gran hacker? No sé si es posible convertirse en uno. Pero ciertamente es posible hacer cosas que te vuelvan estúpido, y si puedes volverte estúpido, probablemente también puedas volverte inteligente.

La clave para ser un buen hacker puede ser trabajar en lo que te gusta. Cuando pienso en los grandes hackers que conozco, una cosa que tienen en común es la extrema dificultad de hacerlos trabajar en cualquier cosa que no quieran. No sé si esto es causa o efecto; puede ser ambos.

Para hacer algo bien tienes que amarlo. Así que en la medida en que puedas preservar el hackeo como algo que amas, es probable que lo hagas bien. Trata de mantener el sentido de asombro que tenías sobre la programación a los 14 años. Si te preocupa que tu trabajo actual esté pudriendo tu cerebro, probablemente lo esté.

Los mejores hackers tienden a ser inteligentes, por supuesto, pero eso es cierto en muchos campos. ¿Hay alguna cualidad que sea única de los hackers? Pregunté a algunos amigos, y la principal cosa que mencionaron fue la curiosidad. Siempre había supuesto que todas las personas inteligentes eran curiosas-- que la curiosidad era simplemente la primera derivada del conocimiento. Pero aparentemente los hackers son particularmente curiosos, especialmente sobre cómo funcionan las cosas. Tiene sentido, porque los programas son en efecto grandes descripciones de cómo funcionan las cosas.

Varios amigos mencionaron la capacidad de los hackers para concentrarse-- su capacidad, como lo expresó uno, de "sintonizar todo lo que está fuera de sus propias cabezas". Ciertamente he notado esto. Y he escuchado a varios hackers decir que después de beber incluso media cerveza no pueden programar en absoluto. Así que tal vez el hackeo requiere una habilidad especial para enfocar. Quizás los grandes hackers pueden cargar una gran cantidad de contexto en su cabeza, de modo que cuando miran una línea de código, ven no solo esa línea sino todo el programa que la rodea. John McPhee escribió que el éxito de Bill Bradley como jugador de baloncesto se debía en parte a su extraordinaria visión periférica. La visión "perfecta" significa aproximadamente 47 grados de visión periférica vertical. Bill Bradley tenía 70; podía ver la canasta cuando miraba al piso. Tal vez los grandes hackers tengan una habilidad innata similar. (Yo hago trampa usando un lenguaje muy denso, que reduce la cancha).

Esto podría explicar la desconexión sobre los cubículos. Tal vez las personas a cargo de las instalaciones, al no tener ninguna concentración que romper, no tienen idea de que trabajar en un cubículo se siente para un hacker como tener su cerebro en una licuadora. (Mientras que Bill, si los rumores de autismo son ciertos, lo sabe muy bien).

Una diferencia que he notado entre los grandes hackers y las personas inteligentes en general es que los hackers son más políticamente incorrectos. En la medida en que existe un apretón de manos secreto entre los buenos hackers, es cuando se conocen lo suficientemente bien como para expresar opiniones que los harían apedrear hasta la muerte por el público en general. Y puedo ver por qué la incorrección política sería una cualidad útil en la programación. Los programas son muy complejos y, al menos en manos de buenos programadores, muy fluidos. En tales situaciones, es útil tener un hábito de cuestionar los supuestos.

¿Puedes cultivar estas cualidades? No lo sé. Pero al menos no las reprimas. Así que aquí está mi mejor intento de una receta. Si es posible convertirte en un gran hacker, la forma de hacerlo puede ser hacer el siguiente trato contigo mismo: nunca tendrás que trabajar en proyectos aburridos (a menos que tu familia se muera de hambre de lo contrario), y a cambio, nunca te permitirás hacer un trabajo a medias. Todos los grandes hackers que conozco parecen haber hecho ese trato, aunque tal vez ninguno de ellos tuvo opción en el asunto.

Notas

[1] En justicia, tengo que decir que IBM fabrica hardware decente. Escribí esto en una computadora portátil de IBM.

[2] Resultaron estar condenados. Cerraron unos meses después.

[3] Creo que esto es lo que la gente quiere decir cuando habla sobre el "significado de la vida". A primera vista, esto parece un idea extraña. La vida no es una expresión; ¿cómo podría tener significado? Pero puede tener una calidad que se siente mucho como significado. En un proyecto como un compilador, tienes que resolver muchos problemas, pero los problemas todos caen en un patrón, como en una señal. Mientras que cuando los problemas que tienes que resolver son aleatorios, parecen ruido.

[4] Einstein en algún momento trabajó diseñando refrigeradores. (Tenía acciones).

[5] Es difícil decir exactamente qué constituye la investigación en el mundo de las computadoras, pero como primera aproximación, es software que no tiene usuarios.

No creo que sea la publicación lo que hace que los mejores hackers quieran trabajar en departamentos de investigación. Creo que es principalmente no tener que tener una reunión de tres horas con un gerente de producto sobre problemas de integración de la versión coreana de Word 13.27 con el clip de papel parlante.

[6] Algo similar ha estado sucediendo durante mucho tiempo en la industria de la construcción. Cuando hace un par de cientos de años te construían una casa, los constructores locales construían todo en ella. Pero cada vez más lo que hacen los constructores es ensamblar componentes diseñados y fabricados por otra persona. Esto, al igual que la llegada de la autoedición, ha dado a las personas la libertad de experimentar de formas desastrosas, pero ciertamente es más eficiente.

[7] Google es mucho más peligroso para Microsoft que Netscape. Probablemente más peligroso de lo que cualquier otra empresa haya sido. No menos porque están decididos a luchar. En su página de listado de empleos, dicen que uno de sus "valores fundamentales" es "No ser malvado". De una empresa que vende aceite de soja o equipos de minería, tal declaración sería meramente excéntrica. Pero creo que todos nosotros en el mundo de las computadoras reconocemos a quién es una declaración de guerra.

Gracias a Jessica Livingston, Robert Morris y Sarah Harlin por leer versiones anteriores de esta charla.