Grandes Hackers

¿Quieres empezar una startup? Obtén financiación de Y Combinator.

---

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 "provocador" y "controvertido". Por no hablar de "idiota".

No pretendía que el libro fuera controvertido. Intentaba que fuera eficiente. No quería hacer perder el tiempo a la gente contándoles cosas que ya sabían. Es más eficiente simplemente darles las diferencias. Pero supongo que eso inevitablemente produce un libro alarmante.

Edisons

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

No dije en el libro que la variación en la riqueza fuera en sí misma algo bueno. Dije que en algunas situaciones podría ser un signo de cosas buenas. Un dolor de cabeza punzante no es algo bueno, pero puede ser un signo de algo bueno; por ejemplo, que estás recuperando la conciencia después de haberte dado un golpe en la cabeza.

La variación en la riqueza puede ser un signo de variación en la productividad. (En una sociedad de uno, son idénticas). Y eso es casi con toda seguridad algo bueno: si tu sociedad no tiene variación en la productividad, probablemente no sea porque todos sean Thomas Edison. Probablemente sea porque no tienes ningún Thomas Edison.

En una sociedad de baja tecnología no se ve mucha variación en la productividad. Si tienes una tribu de nómadas recogiendo leña para una hoguera, ¿cuánto más productivo será el mejor recolector 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 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 qué pasa si el problema no está dado? En la programación, como 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íe tanto. La variación entre programadores es tan grande que se convierte en una diferencia de tipo. Sin embargo, no creo que esto sea algo intrínseco a la programación. En todos los campos, la tecnología magnifica las diferencias de productividad. Creo que lo que está sucediendo en la programación es simplemente que tenemos mucha palanca tecnológica. Pero en todos los campos la palanca se está alargando, por lo que la variación que vemos es algo que cada vez más campos experimentarán a medida que pase el tiempo. Y el éxito de las empresas, y de 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 es creada por el 1% de sus miembros, pierdes mucho si algo (ya sean incursiones vikingas o planificación central) arrastra su productividad al promedio.

Si queremos sacarles el máximo provecho, necesitamos entender a estas personas especialmente productivas. ¿Qué las motiva? ¿Qué necesitan para hacer su trabajo? ¿Cómo las reconoces? ¿Cómo consigues que vengan 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 superhackers, así que me senté y pensé en lo que tenían en común. Su cualidad definitoria es probablemente que realmente aman programar. Los programadores ordinarios escriben código para ganarse la vida. Los grandes hackers lo consideran algo que hacen por diversión, y están encantados de que la gente les pague por ello.

Se dice a veces 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 suficiente dinero, puedes trabajar en lo que quieras, y por esa razón los hackers se sienten atraídos por la idea de ganar mucho 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 pagarles a los grandes hackers ni remotamente lo que valen. Un gran programador podría ser diez o cien veces más productivo que uno ordinario, 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 un eufemismo. 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 de las cosas que estaban colgadas en nuestro tablón de anuncios era un anuncio de IBM. Era una foto de un AS400, y el titular decía, creo, "los hackers lo desprecian". [1]

Cuando decides qué infraestructura usar para un proyecto, no solo estás tomando 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 algún software, podría parecer una elección prudente escribirlo en Java. Pero cuando eliges un lenguaje, también eliges una comunidad. Los programadores que podrás contratar para trabajar en un proyecto 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 importa 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 lenguajes más populares porque ven los lenguajes como estándares. No quieren apostar la empresa por Betamax. La cosa con los lenguajes, sin embargo, es que no son solo estándares. Si tienes que mover bits a través de una red, usa TCP/IP sin dudarlo. 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 desear más. Pero como medio de expresión, podrías hacerlo mucho mejor. De todos los grandes programadores que se me ocurren, solo conozco a uno que programaría voluntariamente en Java. Y de todos los grandes programadores que se me ocurren que no trabajan para Sun, en Java, conozco a cero.

Los grandes hackers también suelen insistir 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 sientan eso sobre el software que están escribiendo para ti. No deberías sorprenderte cuando sienten lo mismo sobre el sistema operativo.

Hace un par de años, un amigo capitalista de riesgo me habló de una nueva startup en la que estaba involucrado. Parecía prometedora. Pero la próxima vez que hablé con él, dijo que habían decidido construir su software sobre Windows NT, y acababan de contratar a un desarrollador de NT muy experimentado para que fuera su director de tecnología. Cuando oí esto, pensé, estos tipos están condenados. Uno, el CTO no podía ser un hacker de primer nivel, porque para convertirse en un desarrollador de NT eminente habría tenido que usar NT voluntariamente, varias veces, y no podía imaginar a un gran hacker haciendo eso; y dos, incluso si fuera bueno, tendría dificultades para contratar a alguien bueno para que trabajara para él si el proyecto tenía que construirse sobre NT. [2]

La última frontera

Después del software, la herramienta más importante para un hacker es probablemente 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: usan su oficina como un lugar para pensar. Y si eres una empresa de tecnología, sus pensamientos son tu producto. Por lo tanto, hacer que los hackers trabajen en un entorno ruidoso y que distraiga 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 buena razón. Todos los hackers que conozco los desprecian. La mera perspectiva de ser interrumpido es suficiente para impedir que los hackers trabajen en problemas difíciles. Si quieres hacer un trabajo real en una oficina con cubículos, tienes dos opciones: trabajar en casa, o venir temprano o tarde o un fin de semana, cuando nadie más está allí. ¿No se dan cuenta las empresas de que esto es una señal de que algo está roto? Se supone que un entorno de oficina es algo que te ayuda a trabajar, no algo contra lo que trabajas.

Empresas como Cisco están orgullosas de que todos allí tengan un cubículo, incluso el CEO. Pero no son tan avanzadas como creen; obviamente todavía ven el espacio de oficina como una insignia de rango. Nótese también que Cisco es famosa por hacer muy poco desarrollo de productos 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 los hackers necesitan es Microsoft. Una vez vi un anuncio de reclutamiento para 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 tu 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 fijarse en lo que hacen en casa. En casa, los hackers pueden organizar las cosas ellos mismos para hacer lo máximo 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 de barrio con gente alrededor y un lugar para caminar cuando necesitan reflexionar sobre algo, en lugar de en cajas de cristal en medio de acres de estacionamientos. Tienen un sofá en el que pueden echar una siesta cuando se sienten cansados, en lugar de estar en coma en su escritorio, fingiendo trabajar. No hay un equipo de personas con aspiradoras que ruge todas las noches durante las horas pico de hacking. No hay reuniones o, Dios no lo quiera, retiros corporativos o ejercicios de team-building. Y cuando miras lo que están haciendo en esa computadora, encontrarás que refuerza lo que dije antes sobre las herramientas. Puede 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 lenguaje más popular pueden ser engañosas. Lo que deberíamos mirar, si queremos saber qué herramientas son las mejores, es lo que los hackers eligen cuando pueden elegir libremente, es decir, en sus propios proyectos. 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 es probablemente 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 aviones furtivos o software de efectos especiales serían interesantes de trabajar. Pero cualquier aplicación puede ser interesante si presenta desafíos técnicos novedosos. Por lo tanto, es difícil predecir qué problemas les gustarán a los hackers, porque algunos solo se vuelven interesantes cuando las personas que trabajan en ellos descubren un nuevo tipo de solución. Antes de ITA (que escribió el software dentro de Orbitz), las personas que trabajaban en búsquedas de tarifas aéreas probablemente pensaban que era una de las aplicaciones más aburridas imaginables. Pero ITA la 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 y sin importancia. 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 que le dice a un niño, 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. Había muchas computadoras pequeñas y económicas antes del Mac. Él redefinió el problema como: haz una que sea hermosa. Y eso probablemente impulsó a los desarrolladores más que cualquier zanahoria o palo.

Ciertamente cumplieron. Cuando apareció el Mac por primera vez, ni siquiera tenías que encenderlo para saber que sería bueno; podías decirlo por la carcasa. Hace unas semanas estaba caminando por la calle en Cambridge, y en la basura de alguien vi lo que parecía ser un estuche de transporte para Mac. Miré dentro, y había un Mac SE. Lo llevé a casa y lo enchufé, y arrancó. La cara feliz 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 artículos ocasionales sobre cómo gestionar programadores. En realidad, debería haber dos artículos: uno sobre qué hacer si eres un programador, y otro sobre qué hacer si no lo eres. Y el segundo probablemente podría condensarse en dos palabras: ríndete.

El problema no es tanto la gestión del día a día. 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 coches americanos son tan feos. Lo llamo la paradoja del diseño. Podrías pensar que podrías hacer que tus productos fueran hermosos simplemente contratando a un gran diseñador para que los diseñara. 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 basarte en los premios que ha ganado o los trabajos que ha tenido, porque en diseño, como en la mayoría de los campos, estos tienden a ser impulsados por la moda y el contacto social, con la habilidad real en un distante tercer lugar. No hay escapatoria: no puedes gestionar un proceso destinado a producir cosas hermosas sin saber qué es lo hermoso. Los coches americanos son feos porque las empresas de automóviles americanas están dirigidas por personas con mal gusto.

Mucha gente en este país considera el gusto como algo esquivo, o incluso frívolo. No es ninguna de las dos cosas. Para dirigir el diseño, un gerente debe ser el usuario más exigente de los productos de una empresa. Y si tienes muy buen gusto, 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 muchos pequeños y desagradables. Uno de los peores tipos de proyectos es escribir una interfaz para una pieza de software que está llena de errores. Otro es cuando tienes que personalizar algo para las necesidades complejas y mal definidas de un cliente individual. Para los hackers, estos tipos 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 defectuoso no te enseña nada, porque los errores son aleatorios. [3] Así que no es solo fastidio lo que hace que los buenos hackers eviten los pequeños problemas desagradables. Es más una cuestión de autopreservación. Trabajar en pequeños problemas desagradables te vuelve estúpido. Los buenos hackers lo evitan por la misma razón que las modelos evitan las hamburguesas.

Por supuesto, algunos problemas tienen inherentemente este carácter. Y debido a la oferta y la demanda, pagan especialmente bien. Por lo tanto, una empresa que encontrara una manera de hacer que los grandes hackers trabajaran en problemas tediosos tendría mucho éxito. ¿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 trabajo tedioso para las empresas de las que son fundadores. [4]

Las empresas más grandes resuelven el problema particionando la empresa. Consiguen que gente inteligente trabaje para ellas estableciendo un departamento de I+D separado donde los empleados no tienen que trabajar directamente en los pequeños y desagradables problemas 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.

Quizás no tengas que llegar a este extremo. La programación de abajo hacia arriba sugiere otra forma de particionar la empresa: hacer que la gente inteligente trabaje como creadores de herramientas. Si tu empresa crea software para hacer x, ten un grupo que construya herramientas para escribir software de ese tipo, y otro que use estas herramientas para escribir las aplicaciones. De esta manera, podrías conseguir que gente inteligente escriba el 99% de tu código, pero aún así mantenerlos casi tan aislados de los usuarios como estarían en un departamento de investigación tradicional. Los creadores de herramientas tendrían usuarios, pero solo serían los propios desarrolladores de la empresa. [6]

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

Agrupación

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. Por lo tanto, no atraerás 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. Por lo tanto, es el ganador se lo lleva todo. 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 que una empresa tenga éxito. Funciona bien para Google e ITA, que son dos de los puntos calientes del momento, pero no ayudó a Thinking Machines ni a Xerox. Sun tuvo una buena racha durante un tiempo, pero su modelo de negocio es un ascensor descendente. En esa situación, ni siquiera los mejores hackers pueden salvarte.

Creo, sin embargo, que, a igualdad de condiciones, una empresa que pueda atraer grandes hackers tendrá una gran ventaja. Hay gente que no estaría de acuerdo con esto. Cuando estábamos recorriendo las firmas de capital de riesgo en la década de 1990, varias nos dijeron que las empresas de software no ganaban escribiendo gran software, sino a través de la marca, y dominando los canales, y haciendo los acuerdos correctos.

Realmente parecían creer esto, y creo que sé por qué. Creo que lo que muchos VCs buscan, al menos inconscientemente, es el próximo Microsoft. Y por supuesto, si Microsoft es tu modelo, no deberías buscar empresas que esperen ganar escribiendo gran software. Pero los VCs se equivocan al buscar el próximo Microsoft, porque ninguna startup puede ser el próximo Microsoft a menos que alguna otra empresa esté preparada para agacharse en el momento justo y ser el próximo IBM.

Es un error usar Microsoft como modelo, porque toda su cultura deriva de esa única oportunidad afortunada. Microsoft es un mal punto de datos. Si los descartas, encuentras que los buenos productos tienden a ganar en el mercado. Lo que los VCs deberían buscar es el próximo Apple, o el próximo Google.

Creo que Bill Gates lo sabe. 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? Eso resulta ser muy difícil. Ni siquiera los hackers pueden decirlo. Estoy bastante segura ahora de que mi amigo Trevor Blackwell es un gran hacker. Quizás hayas leído en Slashdot cómo hizo su propio Segway. Lo notable de este proyecto fue que escribió todo el software en un día (en Python, por cierto).

Para Trevor, eso es lo normal. Pero cuando lo conocí, pensé que era un completo idiota. Estaba en la oficina de Robert Morris hablándole de algo, y recuerdo que me paré detrás de él haciendo gestos frenéticos a Robert para que echara a este loco de su oficina para que pudiéramos ir a almorzar. Robert dice que él también juzgó mal a Trevor al principio. Aparentemente, cuando Robert lo conoció, Trevor acababa de empezar un nuevo plan que implicaba escribir 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 desinterés social, a veces ponen mucho esfuerzo en parecer inteligentes. Cuando estaba en la escuela de posgrado, solía pasarme por el MIT AI Lab ocasionalmente. Era un poco intimidante al principio. Todos 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; solo usa el doble de palabras para decir todo.

Con esta cantidad de ruido en la señal, es difícil distinguir a los buenos hackers cuando los conoces. Yo tampoco puedo decirlo, incluso ahora. Tampoco puedes saberlo 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 por la que las áreas de alta tecnología solo ocurren 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 inteligentes aprenden quiénes son los otros inteligentes, y juntos conciben nuevos proyectos propios.

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

Pero es particularmente difícil para los hackers saber lo buenos que 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 la piratería es como la escritura. ¿Quién puede decir cuál de dos novelas es mejor? Ciertamente no los autores.

Con los hackers, al menos, otros hackers pueden decirlo. Eso es porque, a diferencia de los novelistas, los hackers colaboran en proyectos. Cuando puedes resolver algunos problemas difíciles a través de la red a alguien, aprendes bastante rápido lo duro que te golpean. Pero los hackers no pueden verse a sí mismos trabajando. Así que si le preguntas a un gran hacker qué tan bueno es, casi con certeza 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 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 me vienen a la mente siempre tienden a ser personas que conozco personalmente, pero parece lamentable usarlos. Así que, pienso, tal vez debería decir Richard Stallman, o Linus Torvalds, o Alan Kay, o alguien famoso así. Pero no tengo idea de si estos tipos son grandes hackers. Nunca he trabajado con ellos en nada.

Si existe un Michael Jordan del hacking, nadie lo sabe, incluyéndolo a él.

Cultivo

Finalmente, la pregunta que todos los hackers se han estado haciendo: ¿cómo te conviertes en un gran hacker? No sé si es posible convertirte en uno. Pero ciertamente es posible hacer cosas que te vuelven 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 para hacer que trabajen en algo que no quieren. 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 mantener la piratería como algo que amas, es probable que lo hagas bien. Intenta mantener el sentido de asombro que tenías sobre la programación a los 14 años. Si te preocupa que tu trabajo actual te esté pudriendo el 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 en los hackers? Le pregunté a algunos amigos, y lo principal 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. Eso tiene sentido, porque los programas son en efecto descripciones gigantes de cómo funcionan las cosas.

Varios amigos mencionaron la capacidad de concentración de los hackers, su capacidad, como dijo uno, para "desconectar todo lo que está fuera de sus propias cabezas". Ciertamente lo he notado. Y he oído a varios hackers decir que después de beber incluso media cerveza no pueden programar en absoluto. Así que tal vez la piratería requiera alguna habilidad especial para concentrarse. Quizás los grandes hackers puedan cargar una gran cantidad de contexto en su cabeza, de modo que cuando miren una línea de código, vean no solo esa línea sino todo el programa a su alrededor. 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 vista "perfecta" significa unos 47 grados de visión periférica vertical. Bill Bradley tenía 70; podía ver la canasta cuando miraba al suelo. Quizás los grandes hackers tengan una habilidad innata similar. (Yo hago trampa usando un lenguaje muy denso, que acorta la cancha).

Esto podría explicar la desconexión sobre los cubículos. Quizás 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 el 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 el hábito de cuestionar las suposiciones.

¿Puedes cultivar estas cualidades? No lo sé. Pero al menos puedes no reprimirlas. 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 tienes que trabajar en proyectos aburridos (a menos que tu familia muera de hambre de lo contrario), y a cambio, nunca te permitirás hacer un trabajo mediocre. Todos los grandes hackers que conozco parecen haber hecho ese trato, aunque quizás ninguno de ellos tuvo otra opción.

Notas

[1] Para ser justos, tengo que decir que IBM fabrica hardware decente. Escribí esto en un portátil IBM.

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

[3] Creo que esto es lo que la gente quiere decir cuando habla del "significado de la vida". A primera vista, parece una idea extraña. La vida no es una expresión; ¿cómo podría tener significado? Pero puede tener una cualidad que se parece mucho al significado. En un proyecto como un compilador, tienes que resolver muchos problemas, pero los problemas 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 un momento dado trabajó diseñando refrigeradores. (Tenía participación accionaria).

[5] Es difícil decir exactamente qué constituye investigación en el mundo de la informática, 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 se construía una casa hace un par de cientos de años, 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 la gente la libertad de experimentar de maneras desastrosas, pero ciertamente es más eficiente.

[7] Google es mucho más peligroso para Microsoft que Netscape. Probablemente más peligroso que cualquier otra empresa que haya existido. Y no solo porque están decididos a luchar. En su página de ofertas de empleo, dicen que uno de sus "valores fundamentales" es "No seas malvado". De una empresa que vende aceite de soja o equipos de minería, tal declaración sería simplemente excéntrica. Pero creo que todos en el mundo de la informática reconocemos a quién va dirigida esa declaración de guerra.

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